A tracking identifier is the value that tells your system that a visit and a later lead belong to the same click. Three families do this job, and they are not interchangeable: they differ in who creates them, what they can prove, and when they disappear.
| UTM parameters | Click ID | First-party cookie | |
|---|---|---|---|
| Who creates it | whoever builds the ad link | your system, when the click arrives | your server, in the response that renders the page |
| Unique per click | no, a shared label | yes, one value per click | yes, it carries the click ID |
| Where it lives | the URL | the URL, then a server-side record | the browser, on your own domain |
| What it can prove | the source someone declared | which ad, which page, which second | the same, and it survives the click |
| When it breaks | a typo, a redirect, a reused label | a redirect chain, an expired window | nothing, as long as it is set server-side |
UTM parameters: a label, not a key
UTM parameters are query-string values added to a destination URL to describe where a visit came from.
?utm_source=facebook&utm_medium=paid&utm_campaign=spring&utm_content=video_aThey are good for reporting by source and campaign in any analytics tool, with no integration, and for human-readable context when you debug a single visit.
They break in four predictable ways:
| Failure | Consequence |
|---|---|
| Typo in a parameter | the visit is attributed to a source that does not exist |
| Parameter dropped by a redirect | the visit becomes direct traffic |
Same utm_content reused for two ads | the two creatives merge, invisibly |
| Renaming a campaign mid-flight | history splits into two campaigns |
None of these are detectable after the fact, because a UTM has no uniqueness: two visits with identical parameters are indistinguishable. It is a label shared by thousands of visits, with no server-side record behind it.
Click ID: one value per click
A click ID is a unique value generated when a user clicks an ad, stored so that a conversion occurring later can be tied back to that specific click.
Ad click → track.example.com/lp?cid=8f3a... → Set-Cookie: cid=8f3a... (first-party, HttpOnly)
Form submit → server reads the cookie → lead attributed to click 8f3a...A click ID is only useful if it is still available when the conversion happens. That requires three things:
- It must be written server-side in the same response that renders the page. A cookie written by JavaScript is the one browsers now restrict.
- It must have a defined lifetime, the attribution window, so that a lead arriving after the window is recorded as unattributed instead of guessed.
- It must not depend on a redirect chain. A hop from a tracking domain to a landing page on another domain loses a share of identifiers, concentrated among users with the strictest browser settings.
A useful click ID resolves to more than “some click”: the ad it came from (ad_id), the campaign, the landing page variant, and a timestamp.
First-party: where the identifier lives
First-party tracking sets the identifier from the same domain the user is visiting, in a response from your own server.
First-party: landing page on track.example.com → Set-Cookie from track.example.com
Third-party: landing page on example.com → cookie set by analytics.other.comThe privacy changes of 2017–2021 targeted specific mechanisms, and this one was not among them:
| Change | Targets | First-party server cookie |
|---|---|---|
| Intelligent Tracking Prevention | cookies written by JavaScript; third-party cookies | unaffected |
| App Tracking Transparency | cross-app identity | unaffected |
| Third-party cookie blocking | cookies from a different domain | unaffected |
What these changes removed is the ability to identify the same person across sites you do not own. Measuring a visit to your own page is not that.
How the three fit together
- The click ID is the primary key. It is what a lead is joined to.
- UTMs stay as readable context: they are what a human looks at when the numbers surprise someone, and what a CRM sees without integration.
- The first-party cookie is the transport. It is how the click ID survives the page load without depending on JavaScript.
A stack that records only UTMs cannot answer “which creative produced this lead”. A stack that records a click ID server-side can, and the UTM becomes a convenience rather than a dependency.
Related terms
- Attribution window — how long the identifier is honoured
- fbclid — the platform’s own identifier, and its limits
- ad_id — the platform key a click ID resolves to
- ITP — what broke the JavaScript cookie
- Server-side tracking — where the event is processed