Cookieless tracking: four techniques, four failure modes
The label covers four unrelated techniques. Sort them by what breaks each one — consent, Safari, a blocker, or a regulator — and the shopping list gets shorter.
On this page
- The label covers four techniques with nothing in common
- PECR doesn't care that it isn't a cookie
- Safari's caps are aimed at the storage, not at the vendor
- A blocker matches on the hostname, and one of them resolves the CNAME first
- Privacy Sandbox stopped being one of the answers in October 2025
- Where a first-party identifier helps, and where it just moves the problem
- The claims in this category that stop at a vendor
- What to actually do with this
Short answer: sort them by what breaks them, not by what they're called. "Cookieless tracking" is a label applied to four techniques that share nothing: moving data collection to your own server, matching people by a hashed identifier, estimating the missing part statistically, and identifying devices by their configuration. Consent breaks all four, because UK law regulates storage on a device rather than cookies specifically. Safari's caps break the first one where it depends on a CNAME. Thresholds break the third. Regulators, not browsers, are what stand in front of the fourth. Nothing on the list recovers a visitor who said no, and any pitch that implies otherwise is selling you a way around a decision rather than a way to measure.
The useful question isn't which technique is cookieless. It's which failure mode you actually have.
The label covers four techniques with nothing in common
Group them by mechanism and the shopping list gets much shorter.
| Technique | What it changes | What breaks it | What it can't do |
|---|---|---|---|
| First-party transport (server-side tagging, Tag Gateway) | Where the request goes and who sets the cookie | A denied consent state; a CNAME to a third party, under Safari; a filter list entry | Collect from someone who declined |
| First-party identifier matching (enhanced conversions, Customer Match, Data Manager) | Rejoins a known person to an outcome | A denied consent state; the platform not recognising the person | Reach anonymous traffic |
| Modelling (Consent Mode behavioural and conversion modelling) | Estimates the unobserved part | Volume thresholds; a basic implementation; a TCF-based banner | Give you a row per person |
| Device fingerprinting | Identifies the device from its configuration | UK regulators, explicitly | Be consented to in any meaningful way |
Read down the third column and the pattern is obvious. Only one of the four has browser behaviour as its main obstacle. Two of them are stopped by the consent state, which is a permission problem that no amount of engineering converts into a data problem. And the fourth is stopped by the regulator.
PECR doesn't care that it isn't a cookie
This is the part that collapses most of the category, and it comes from the ICO's final storage and access technologies guidance, whose relevant page is dated 29 April 2026.
Regulation 6 of PECR "applies to any technology that stores information, or accesses information stored, on a subscriber's or user's 'terminal equipment'." The guidance then lists what that includes: cookies, tracking pixels, link decoration and navigational tracking, web storage, fingerprinting techniques, and scripts and tags. The mechanism is not the test. Storage on the device is the test.
Three consequences follow, and all three are stated outright in the guidance rather than inferred.
First-party versus third-party is not a legal category. The ICO writes that the terms "have no inherent meaning in PECR or UK GDPR", and that the rules apply "whether in a first-party context or a third-party context". Moving a tracker onto your own subdomain changes the browser's view of it. It does not change the regulator's.
Server-side doesn't exempt you either. Regulation 6 applies "in both a 'client-side' and 'server-side' context where information is stored or accessed on a device", and the guidance adds a duty on top: an operator using a server-side tag manager "must inform the user about third parties it shares the information with". Server-side tagging makes the data flow less visible to the visitor, and the guidance treats that as a reason for more disclosure, not less.
Hashing doesn't change the status of the data. In the ICO's own example, a retailer's tag hashes an email address on the page and stores the value in a first-party cookie for later matching. Their conclusion: "Even though the full email address is 'masked', an identifier is created for the purpose of processing information relating to the user", so regulation 6 applies and UK GDPR applies too.
Safari's caps are aimed at the storage, not at the vendor
Safari's Intelligent Tracking Prevention has two limits that decide whether a first-party setup keeps working, and both turn on how the value got there.
The first is the seven-day cap. WebKit announced in March 2020 that ITP deletes a site's script-writeable storage after seven days of Safari use without user interaction on the site, covering IndexedDB, LocalStorage, SessionStorage, media keys, and Service Worker registrations and cache. Cookies written by JavaScript had already been capped at seven days in February 2019. A first-party identifier that page JavaScript writes is subject to that cap whatever the vendor calls it.
The second is narrower and much less quoted. In November 2020 WebKit added a seven-day cap on cookies set in third-party CNAME-cloaked HTTP responses, defining that as "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists". Check your own setup against their published table: a subdomain CNAMEd to a tracker's domain gets capped, a subdomain whose CNAME matches the edge host the whole site already resolves through does not.
That's the practical difference between two tagging-server setups that look identical on a diagram. Which visitors it actually affects is a smaller population than the pitch implies, and the arithmetic is in what server-side tagging actually recovers.
A blocker matches on the hostname, and one of them resolves the CNAME first
Filter lists work on hostnames and URL patterns, so a first-party measurement subdomain is a hostname a list can add. That much is widely understood.
Less widely understood: on Firefox, uBlock Origin can look up the DNS record for a request and block on the uncloaked target. Its own documentation describes "the ability to uncloak 3rd-party servers disguised as 1st-party through CNAME record", and cites an August 2020 APNIC study for the measured effect. So the CNAME arrangement that Safari caps is also the arrangement that at least one major blocker can see through. Whether your own traffic contains enough of those users to matter is a question about your audience, and the honest answer is that you have to measure it rather than assume it.
Every technique above depends on what your site is doing before anyone clicks Accept, which is the one thing nobody checks. Our cookie and tracker scanner loads your site in a real browser and reports which cookies and trackers fire pre-consent, which consent platform is enforcing, and which cookies are written by page JavaScript rather than by a server — that last number is the part Safari's seven-day cap applies to.
Privacy Sandbox stopped being one of the answers in October 2025
If your cookieless plan came out of a 2024 deck, check whether it still refers to APIs that Chrome has since dropped.
On 17 October 2025 Google announced it would retire the Attribution Reporting API, Protected Audience, Topics, Private Aggregation, Shared Storage, Related Website Sets, SelectURL, IP Protection and On-Device Personalization, citing "ecosystem feedback about their expected value and in light of their low levels of adoption". The Privacy Sandbox feature status table, last updated 14 August 2026, lists all of those as "Deprecate and remove" or "Discontinue".
What Google says it continues to support is a much less exciting list: CHIPS, FedCM, Private State Tokens, Storage Access, storage and network state partitioning, bounce tracking mitigations and User-Agent reduction. Read the roles — those are cookie-partitioning, login and anti-fraud features, not advertising measurement replacements. The one measurement thread that survived is a proposed interoperable Attribution standard going through the W3C, which is a standards process rather than something you can configure this quarter.
So cross-site interest targeting via browser APIs isn't the destination the 2021 roadmap described, and third-party cookie choice in Chrome stayed as it was. The pressure on measurement in the UK comes from consent and from Safari, not from a Chrome deprecation date.
Where a first-party identifier helps, and where it just moves the problem
A first-party identifier genuinely closes one gap: rejoining a person you can name to an outcome you care about. That's worth building. It also relocates two problems rather than solving them, and both relocations are on Google's own pages.
It moves identification to the platform's user graph. Google's Customer Match documentation describes targeting "customers from your uploaded data file who are Google users", who see your ads "when those users are signed in to their Google account". Your ability to identify a customer and Google's ability to identify the same customer are separate facts, and only the first is under your control.
It moves the inventory question somewhere you can't see. The same page records that since early March 2024, Customer Match lists activated on Google Partner Inventory or third-party exchange sites in the EEA, including the UK and Switzerland, are no longer available for web and app — first-party data keeps working across Google's own properties. One housekeeping limit to know before you build a pipeline: membership maxes out at 540 days, and a list needs at least 100 members added or updated within that window to stay eligible.
The population matching can never reach is the same one every time. Someone who browsed, didn't convert and left has given you nothing to match on; someone who declined has given you an answer. Modelling aims at the first group, and Google's published volume thresholds put it out of reach of most sites — the numbers, and who never qualifies, are in what modelling actually recovers.
The claims in this category that stop at a vendor
Sort the category by evidence quality and it thins out fast. Two claims are worth naming specifically because they circulate as fact.
The first is any percentage attached to server-side tagging.
The second is fingerprinting sold as the pragmatic replacement for third-party cookies, and here the regulator has already answered.
Google told advertisers in December 2024 that from 16 February 2025 it would stop prohibiting fingerprinting in its advertising products. The ICO's published response calls the change "irresponsible", states that its view is that "fingerprinting is not a fair means of tracking users online", quotes Google's own 2019 position that it "subverts user choice and is wrong", and says that businesses "must give users fair choices over whether to be tracked before using fingerprinting technology, including obtaining consent from their users where necessary". Its assessment of the compliance bar is direct: "Based on our understanding of how fingerprinting techniques are currently used for advertising this is a high bar to meet. Businesses should not consider fingerprinting a simple solution to the loss of third-party cookies and other cross-site tracking signals."
A vendor policy that no longer forbids something is not a regulator that permits it. That's the gap a buyer is standing in.
What to actually do with this
Work down the failure modes rather than the product names. Establish your real consent rate before costing anything, because the techniques that need permission aren't the ones to buy first on a site where most people decline. Check how your measurement hostname resolves: a CNAME to a third party puts you in Safari's capped case, matching your site's own edge doesn't. Check the modelling thresholds against your actual volumes, since below them the expected recovery is zero whatever you implement. Treat identity as a join that feeds outcomes back to a platform, not as a workaround for anonymous traffic. And leave fingerprinting alone.
None of that needs a new vendor. Most of it needs someone to read what the current setup is doing, which is the work we do — a cheaper conversation before the invoice than after it.
Sources
- 1.ICO — Guidance on the use of storage and access technologies: 'What are storage and access technologies?' (final guidance, page dated 29 April 2026) · Checked 2026-09-10
- 2.ICO — Our response to Google's policy change on fingerprinting, 19 December 2024 · Checked 2026-09-10
- 3.WebKit — Full Third-Party Cookie Blocking and More (the seven-day cap on script-writeable storage), 24 March 2020 · Checked 2026-09-10
- 4.WebKit — CNAME Cloaking and Bounce Tracking Defense (the seven-day cap on cookies set in CNAME-cloaked responses), 12 November 2020 · Checked 2026-09-10
- 5.uBlock Origin wiki — CNAME-uncloaking on Firefox · Checked 2026-09-10
- 6.Privacy Sandbox — Update on Plans for Privacy Sandbox Technologies, 17 October 2025 · Checked 2026-09-10
- 7.Privacy Sandbox — feature status table, last updated 14 August 2026 · Checked 2026-09-10
- 8.Google Ads Help — About Customer Match (signed-in matching, EEA/UK inventory restriction, 540-day membership) · Checked 2026-09-10
- 9.Analytics Help — [GA4] Behavioral modeling for consent mode (eligibility thresholds) · Checked 2026-09-10