Cookieless attribution in the UK: how does it work?

What to take away

Cookieless attribution replaces the third-party cookie with identifiers your business already controls: hashed email addresses, account IDs, order references and consented analytics IDs.
PECR governs storing or reading information on a device, while UK GDPR governs the lawful basis and the minimisation of the personal data that results.
Server-side tracking moves collection off the browser, but it does not remove the consent question.
Consent rates affect how much of a journey is directly observed; modelling can estimate some gaps but does not turn them into observed data.

Why the third-party cookie lost its grip

A third-party cookie is set by a domain other than your own. It let an ad platform follow one browser across many sites, so a click from a search ad and a purchase later on your site could be joined to the same string.

Browsers have tightened that route steadily. Safari and Firefox block third-party cookies by default, and Apple requires an app to ask permission before tracking a user across other companies' apps and websites. Apple's App Tracking Transparency (ATT) is the framework for that permission. Chrome's Privacy Sandbox programme has included the Topics API, a browser-based advertising mechanism rather than a customer-level journey identifier.

What the UK rules require at the same time

Two regimes run in parallel, and they ask different questions. PECR covers storing information on a device or reading it back; regulation 6 is the relevant rule for cookies and similar technologies. The ICO's Cookies and similar technologies guidance explains the requirements, while its guidance on direct marketing and privacy and electronic communications sets out when consent is needed for storage and access. The ICO's cookie enforcement work has challenged websites over non-essential cookies placed before consent; moving tags server-side does not by itself avoid PECR.

UK GDPR then governs what happens to the data afterwards: why you hold it, how long you keep it and what a person can ask you to do with it. Consent for storage is not the same as a lawful basis for processing. The ICO's UK GDPR guidance hub deals with lawful basis, purpose limitation and data minimisation together.

A worked map for an attribution operation is: first ask whether a tag or identifier stores information on a device or reads it back, then apply PECR regulation 6 and check whether consent is required or the strictly necessary exemption applies. Next, where personal data is processed, identify the UK GDPR lawful basis and set the purpose, access and retention rules. Repeat those checks for each vendor that receives events: consent for device storage and a lawful basis for processing are separate tests.

Three routes that replace the third-party cookie

Most cookieless stacks combine three routes. They differ in the identifier used, the consent position and the confidence of the output.

Three cookieless attribution routes

First-party cookie

Identifier: Own-domain cookie
Consent: PECR consent
Output: Same-site journeys
Confidence: Observed

Hashed identifiers

Identifier: Email, account ID
Consent: Consent + basis
Output: Known users
Confidence: Observed

Server-side & modelled

Identifier: Server hits
Consent: Consent at collection
Output: Counts + estimate
Confidence: Partly modelled

Identifier

First-party cookie and site events: A cookie on your own domain, plus your own event log
Hashed first-party identifiers: Email addresses, account IDs and telephone numbers you already hold
Server-side and modelled reporting: Hits sent from your server, with platform modelling for the gaps

Consent position

First-party cookie and site events: PECR consent applies unless the storage is strictly necessary
Hashed first-party identifiers: Consent plus a lawful basis; matching depends on the platform
Server-side and modelled reporting: Consent at collection; modelled outputs are estimates

What it can show

First-party cookie and site events: Same-site journeys, sessions and last-click
Hashed first-party identifiers: Known, logged-in users across devices
Server-side and modelled reporting: Near-complete counts plus an estimated remainder

A server-side container runs on infrastructure you control and forwards hits to vendors, which is what Google's server-side tagging documentation describes.

Each route answers a different question, and the consent position decides which one you can run for a given visitor.

For platform research, named marketing analytics and attribution options include HockeyStack, Dreamdata, Ruler Analytics and Triple Whale. They are not interchangeable: assess each product's identity resolution, modelling, data flows and consent controls against your use case. Consent management platforms such as OneTrust, Cookiebot and Usercentrics can record and apply choices, but a CMP does not establish whether a particular collection route is lawful.

How to assemble a cookieless setup

Name the decision the data must support, and the smallest field list that supports it.
Inventory the identifiers you already hold, including account IDs and order references.
Move collection server-side where browser state is unreliable.
Record a lawful basis and a retention period for every field you keep.
Report observed and modelled counts on separate rows.

The five-step sequence above is the starting point; for UK teams, the linked server-side tracking attribution implementation steps cover tag changes and endpoint testing.

Assembling a cookieless setup

Name the decision and smallest field list
Inventory identifiers you already hold
Move collection server-side
Record lawful basis and retention
Report observed and modelled separately

Where the numbers go soft

Identifiers cover known users. Everyone else arrives without a handle, so platforms fill the gap with modelling. Google Analytics 4's data-driven attribution, for instance, distributes credit across paths using signals you cannot audit line by line.

That is not a reason to ignore modelled rows. It is a reason to label them. A modelled conversion count and an observed conversion count answer different questions, and a report that merges them hides the difference that matters most to a budget holder.

Google Consent Mode v2 communicates consent choices to Google tags; in supported configurations, Google can use modelling to estimate conversions where observable data is limited. Those estimates shift as consent rates shift, so month-on-month comparisons need a note about the rate in each period. There is no universal consent-rate benchmark: compare like-for-like rates for your own properties and periods.

Common questions

Does cookieless attribution remove the need for a cookie banner?

No. PECR consent applies to storing information on a device or reading it back, so browser-side storage that is not strictly necessary still needs it.

Is server-side tracking the same as cookieless tracking?

No. Server-side tracking changes where events are collected and can make them more durable. The identifier and the consent rules stay the same.

Can cookieless attribution show a whole customer journey?

Rarely. Journeys that pass through a login or an email click can usually be joined, because you hold the identifier. Anonymous journeys across other people's sites usually cannot, so totals carry an estimated remainder.

What is the difference between privacy-first attribution and modelled attribution?

Privacy-first attribution counts people and events you hold consent and a lawful basis for. Modelled attribution estimates the rest. Keep the two on separate rows and name the model behind the estimate.