Click identifiers: the URL parameters that let a server-sent conversion find the ad that caused it

A click identifier is a parameter the ad platform adds to your landing-page URL as it forwards a click — gclid on Google, fbclid on Meta, and a different name on every other network. The value is opaque: meaningless to you, meaningful to the platform, which can resolve it to the impression, creative, campaign and account behind that click. It is the only mechanism by which a conversion your server reports days later attaches to a specific ad rather than to a channel.

The distinction worth holding is class, not vendor. Names change and new ones appear whenever a platform adds a surface. What does not change is the behaviour: issued at click time, opaque, single-purpose, expiring. Anything with those 4 properties is a join key and belongs on your order record. Everything else on the URL is description.

Join keys and descriptive tags are not the same class of parameter

Rows 1 and 2 get conflated constantly, usually by a team that has spent a year perfecting a UTM convention and believes it is doing attribution. It is doing labelling, which is useful — but a URL arriving with a full tag set and no click identifier has already lost the ability to close the loop, and that loss shows up later as one of the causes ranked in the ad platform counting more conversions than you do.

The four properties that define the class

• Issued at click, not before. The value does not exist until someone clicks, so it cannot be embedded in a creative or printed on a poster.
• Opaque. No readable structure, no stable length. Nothing inferred from the string is safe, and any field that reformats it destroys it.
• Single-purpose. It answers one question — which click was this — and is not a user id, a session id or a consent record.
• Expiring. Your storage and the platform's matching window are both time-bounded, and the shorter of the 2 sets your real ceiling.

Where the value has to live for a delayed conversion to match

A same-session purchase needs almost nothing — the platform's browser tag handles it. The design problem is everything else: a form filled today and qualified next week, a quote signed by phone, a booking that converts on arrival. The identifier has to survive the gap between the click and the moment money exists, which means moving it out of the browser and onto a record.

1. Capture on the landing page, before anything else runs. Read the query string on first paint, and check the parameter survives every 302 — to a locale path, a marketing domain, a consent gate. A redirect that rebuilds the URL is where it usually vanishes.
2. Write it to first-party storage with an explicit overwrite rule. Decide once whether a later click replaces an earlier one, and store the capture timestamp so the rule can be revisited.
3. Copy it onto the order, lead or booking row at creation. This is the step that matters: a value living only in a cookie is gone when the conversion happens in another system.
4. Carry it into the CRM as a first-class field, not a note. If human qualification is what makes the conversion reportable, the identifier travels with the record through every stage in HubSpot or Salesforce.
5. Include it in the server-sent conversion. It is the strongest matching signal available; the rest of the payload is ordered by matching power in assembling a server-sent conversion a platform will match.

Step 4 is where most of the engineering sits, and it is rarely a tagging job: it touches the form handler, the CRM object model and whatever queue sits between them, the sort of plumbing we treat as product work in internal tools and operations software. Step 1 fails more often than teams expect, and that diagnosis is the click id is gone by the time the form submits.

Storage lifetime needs its own caution. A cookie expiry is a request, not a guarantee: browser tracking-prevention policies cap cookies written by client-side script far below the 2 years teams usually set, and treat a cookie set in an HTTP response from your own domain differently again. Read the current caps from Apple's and Google's own documentation rather than a blog post, and see what the browser does to your identifiers for which mechanism shortens what. The same decision governs whether returning visitors keep arriving as new ones.

A campaign tag tells you what you called the traffic. A click identifier tells the platform which click it was. Only one of those survives a week and a change of system.

Four things a click identifier is not

• Not a user identifier. It identifies one click: the same person clicking twice produces 2 values, and a shared device produces values belonging to different people.
• Not a deduplication key. A browser copy and a server copy need a separate shared event id, and when that goes wrong you get conversions counting twice after the server goes live.
• Not consent. Persisting the value is itself storage, so a denied ad-storage state leaves nothing to persist — which is why consent travels as a typed field on every event.
• Not indefinitely matchable. Platforms match inside a published click-to-conversion window, commonly configurable between 7 and 90 days. A conversion sent after it closes is accepted and attributed to nothing.

Every join in advertising runs on a clock. On the buy side it is how long the identifier is stored and how long the platform will still match it; on the sell side it is the auction timeout that decides whether bids arrive after the auction has closed. Both are designed against rather than hoped about. The surrounding decisions sit under tracking, consent and event pipelines, in our marketing and advertising practice.

• click identifiers
• attribution
• conversion tracking
• url parameters