Cookieless Tracking

Tracking relied on two kinds of cookie. Third-party cookies, set by the ad platform's domain, let it recognise the same person across every site that carried its pixel. First-party cookies, set on your domain, let your analytics recognise a returning visitor and hold the click ID between the landing page and the form. Both have been cut back, in different ways.

• Third-party cookies are blockedSafari since 2020, Firefox since 2019, and Chrome kept them only after dropping its removal plan in 2024. The cross-site view the platforms built on is gone for a large share of visitors.
• First-party cookies set from JavaScript are cappedSafari expires cookies set with document.cookie after seven days, and after 24 hours when the visitor arrived from a classified tracker domain such as facebook.com or google.com with a decorated URL. A click ID stored that way is gone before most B2B leads return.
• Consent removes the restUnder GDPR and ePrivacy, a tracking cookie needs consent regardless of who sets it. Every visitor who declines is invisible to a cookie-based setup, and in much of Europe that is a meaningful share of traffic.
• Browsers partition what remainsFirefox's Total Cookie Protection and Safari's storage partitioning give each top-level site its own cookie jar, so even an allowed third-party cookie no longer links two sites.

The result is that a cookie-based setup measures a shrinking, non-random subset of visitors, and the ad platforms' pixels lose the conversions that matter most: the ones from privacy-conscious, iOS-heavy, B2B audiences.

• Click IDs matched on the server

  gclid, fbclid and msclkid are read on the landing page and stored server-side, not in a browser cookie. The ad platform's own key survives however long it takes the lead to close.

• Hashed first-party identifiers

  Email, phone and name from the form, hashed with SHA-256 and sent to Google's enhanced conversions and Meta's Conversions API. The platform matches them to logged-in users on its side, no cookie needed.

• Server-set first-party storage

  An identifier set by your server on your domain, HttpOnly, is not subject to Safari's seven-day cap on script-set cookies. The visitor is recognised on return without a third party involved.

• The CRM as the source of truth

  The lead and the deal live in the CRM with their journey attached. Attribution runs on that record, and stage changes are sent to the platforms as offline conversions.

• Modelling for what is declined

  Google's Consent Mode sends cookieless pings for visitors who declined and models the conversions it cannot observe. Since March 2024, version 2 is required to use Google's audience features for EEA traffic. The consent mode entry covers it.

None of these is fingerprinting. Deriving an identifier from device characteristics without consent is not compliant under GDPR, and a vendor whose 'cookieless' setup depends on it has moved the problem, not solved it. The server-side tracking page covers the plumbing that carries most of the list above.

0:45

Cookieless is not consent-free. The ePrivacy rules cover any storage or reading of information on a device, so a server-set identifier or a local storage key needs the same basis a cookie did. Server-side processing of a click ID and an email is processing of personal data under GDPR and needs a lawful basis, a processor agreement with the tool and an entry in the privacy policy. What changes is not whether consent is needed but how much survives when it is given: a consented visitor is measured fully and durably, rather than for seven days on one device.

Where the setup differs from a cookie-based one is in what happens without consent. Aggregated, non-identifying counts and modelled conversions can run; individual journeys cannot. A good implementation makes that boundary explicit, and the GDPR-compliant tracking use case shows what it looks like on a lead record.

1. A first-party script on your domain reads the click ID, UTMs and referrer on the landing page and sends them to a server you control. Nothing is stored in a script-set cookie that Safari will expire.
2. The visitor is identified server-side across pages and return visits, so the journey reaches back further than a week.
3. The form or booking writes the lead to the CRM with the journey attached: source, campaign, click ID, first and latest touch. The CRM integration does this on creation, not by hidden fields alone.
4. Calls and meetings join the same record through tracking numbers and the scheduling tool, so a phone lead is attributed the same way as a form lead.
5. The deal closes weeks later and the stage change is sent to Google, Meta and Microsoft server-to-server with the click ID and hashed contact details. The Meta Conversions API and Google's offline conversion import are the receiving ends.

Every step runs on first-party data and none depends on the browser remembering anything. That is the sense in which the label is worth anything: the accuracy no longer changes when a browser does. The product side of this setup is on the first-party tracking page.

• View-throughAn ad that was seen and not clicked leaves no click ID and no visit. Only the platform knows it happened, and it reports it on its own terms.
• Cross-device before identificationResearch on a phone, conversion on a laptop: until the person identifies themselves through a form or a login, the two are separate visitors on any setup. Cross-device tracking covers what can be joined afterwards.
• Touches before your storage beganA visit from before the tag was installed, or on a device that never converted, is not in the journey. Every model credits the first touch it can see.
• Channels with no clickPodcasts, communities, word of mouth. Self-reported attribution is the only instrument for those, cookieless or not.

The honest claim for a cookieless setup is that it measures every consented conversion that involved a click or a form, durably, and sends it back to the platforms in a form they can learn from. That is a large improvement over a pixel that loses events to every browser rule; it is not omniscience.

Cookieless tracking is what measurement looks like once the browser stops being a reliable place to store anything: click IDs and first-party identifiers captured on your own domain, joined to the lead and the deal on a server, and returned to the platforms as hashed, consented conversions. It is not fingerprinting and it is not consent-free. It is first-party data, handled well enough that a Safari update or a Decline button no longer rewrites your channel report.