A few quarters into a customer data platform build for a quick-service restaurant brand, I pulled a report that should have been routine. The app was live, the loyalty programme was enrolling real customers, and the mobile measurement partner, the attribution tool tracking which ad campaigns were driving app installs, was reporting healthy numbers. Cost per install looked reasonable. Attributed installs were climbing. On paper, the marketing was working.

Then I tried to join that attribution data to the customer records actually sitting in the CDP, the people who had logged in, enrolled in the loyalty programme, placed an order. The overlap was nowhere near what it should have been. A large share of the app's most valuable, most identifiable customers, the ones with verified emails, order history, loyalty points on the books, showed up in the attribution platform as installs with no onward record at all. The marketing spend had apparently worked. The system built to prove it had worked could not actually show its receipts.

The two systems were never actually introduced to each other. The mobile measurement partner identifies a device. The app's own backend identifies a customer, but only from the moment someone logs in or creates an account, which for a lot of real users happens well after the first install, if it happens at all during a guest checkout flow. Nothing in the stack was passing a shared, verified identifier between the two. The install was real. The attribution was real. The customer was real. There was simply no deterministic thread connecting any of the three.

The Foundation This Series Already Argued For

This blog's fourth post made a case I still think is correct: unify identity before chasing the AI and analytics layers sitting on top of it. Segmentation, attribution, personalisation, all of it depends on knowing that the person who browsed yesterday and the person who bought today are the same person. That argument has not changed. What has changed, and what that post did not fully reckon with, is that the mechanism for achieving it has been quietly turned adversarial. The browsers, the operating systems, and increasingly the regulations are now built, on purpose, to make that unification harder, not easier. Getting the foundational layer right used to be a matter of effort. It is now a matter of working against infrastructure specifically designed to resist you.

The Myth Worth Retiring First

A lot of what gets repeated about this problem is out of date, and it is worth being precise about what actually happened rather than what is still being assumed. Google abandoned its plan to deprecate third-party cookies in Chrome in July 2024, and confirmed in April 2025 that it would not even introduce a new consent prompt in their place. Chrome still has third-party cookies switched on by default today. If the mental model still running in your head is “Chrome is about to kill cookies,” that model is wrong, and it has been wrong for over a year.

That reversal changed less than it seems to. Safari has blocked third-party cookies by default since 2020 under Intelligent Tracking Prevention. Firefox has been blocking known trackers' third-party cookies by default since 2019 under Enhanced Tracking Protection, three years before Total Cookie Protection extended that into full cookie partitioning in 2022. Neither browser was waiting on Chrome for permission, and neither moved when Chrome reversed course.

As of mid-2026, roughly 18.6 percent of global browser traffic blocks third-party cookies by default, almost entirely Safari and Firefox, and that share climbs to close to a quarter of traffic on mobile specifically, where Safari's share is largest. Chrome standing still did not make the problem go away. It just made it easy to mistake standing still for safety.

What Is Actually Driving The Signal Loss

Three forces are doing the real work here, and none of them are Chrome.

Start with Apple. Its App Tracking Transparency prompt requires explicit opt-in before an app can access a device's advertising identifier, and the industry-wide opt-in rate has settled at roughly 38 percent as of early 2026, up only slightly from 35 percent a year earlier. Turn that around and it means something close to two-thirds of iOS users are structurally invisible to identifier-based tracking, not because they cannot be reached, but because the operating system now asks their permission first and most people say no. Apple has kept adding to this rather than easing off. iOS 26 shipped Advanced Fingerprinting Protection, enabled by default, which actively degrades the device signals that fingerprinting-based matching depends on, alongside Link Tracking Protection, which strips tracking parameters like gclid and fbclid out of URLs before they ever reach your analytics.

Safari's Intelligent Tracking Prevention goes further than simply blocking third-party cookies. It caps the lifespan of first-party cookies set through JavaScript at seven days, regardless of how long your own session or login actually lasts. A pixel-based, client-side tracking setup that assumes a first-party cookie will persist for weeks is wrong on Safari, every single time, after one week.

And layered on top of all of this, the regulatory picture this blog has already covered in detail, the UAE's PDPL, Saudi's PDPL under NDMO, the DIFC and ADGM frameworks, adds consent requirements on top of the technical restrictions. The technology makes passive tracking harder. The law makes doing it without consent actively unlawful. Those are two different pressures pointing in the same direction, and treating either one as the whole problem means missing the other.

What To Actually Build Instead

None of this means identity resolution is no longer possible. It means the easy version, a third-party cookie or a device identifier doing the matching for you, quietly, in the background, without anyone's explicit involvement, is the version that is going away. What replaces it requires more deliberate engineering, not less, and it is worth walking through properly rather than naming four buzzwords and moving on.

Deterministic Matching On First-Party Identifiers

The distinction that matters here is deterministic versus probabilistic. Probabilistic matching infers that two records likely belong to the same person from overlapping signals, similar device type, similar location, similar timing, and it is exactly this kind of inference that falls apart as device-level signals degrade. Deterministic matching instead relies on an exact, verified key that both systems actually share: a hashed email address, a hashed phone number, an authenticated account ID.

For the QSR example above, the fix was not a new tool. It was a sequencing change: passing the app's own internal user ID, hashed, to the mobile measurement partner the moment a user authenticates, via a server-to-server callback rather than waiting for the measurement partner's own device-level attribution to somehow resolve itself. Hashing matters specifically because it lets two systems confirm a match without either one ever exposing the raw personal data behind it, which is also what makes this approach defensible under PDPL and GDPR alike. The practical first step for most organisations is an audit of exactly where a deterministic key could be captured and currently is not, usually at login, at checkout, or at loyalty enrolment, and is simply being left on the table.

Server-Side Tagging

Client-side tracking, a pixel firing from inside a user's browser or app, is exactly what Safari's ITP, ad blockers, and now iOS 26's Link Tracking Protection are built to interfere with. Server-side tagging moves the actual data transmission off the client entirely. Instead of a browser pixel sending an event directly to an ad platform, the event is sent first to a server-side container that you control, commonly a server-side Google Tag Manager instance, routed through a subdomain of your own site. From there, your server genuinely processes the event and forwards it to each ad platform's own server-to-server conversion API, Meta's Conversions API, Google's Enhanced Conversions, and equivalents elsewhere. One precision worth having before you brief an engineering team: the subdomain routing alone is not what earns the exemption. Safari specifically watches for exactly that shortcut, a domain merely aliased to look first-party with no genuine server-side processing behind it, and caps those cookies at seven days regardless. What actually survives is real first-party event processing on a server you control, not the appearance of it.

The underlying mechanism is worth knowing rather than taking on faith: a cookie set through a genuine HTTP Set-Cookie header, issued by your own server, follows different rules than one set via JavaScript, and a server-to-server data transfer simply is not visible to a browser-level content blocker the way a client-side pixel is. This is genuine engineering work, not a marketing settings toggle, and it needs to be budgeted and resourced as such, including the ongoing maintenance to keep up as Apple continues tightening what counts as genuinely first-party.

Clean Rooms

A clean room is a secure, neutral computing environment, run by a platform like Google's Ads Data Hub, Amazon Marketing Cloud, or an independent provider like a Snowflake data clean room, where two separate organisations can each upload their own hashed first-party records and run aggregate queries against the combined set without either side ever seeing the other's underlying data. You might learn how much overlap exists between your loyalty list and a media platform's user base, or activate a lookalike audience built from your own customers, without a single raw email address or phone number ever changing hands, and typically with a minimum audience size threshold built in specifically to prevent any individual from being re-identified from the output. For a business already building a hashed first-party identifier strategy, a clean room is the mechanism that lets that same asset be activated on someone else's platform without compromising it.

Zero-Party Data

This is the one layer that depends on the customer's active cooperation rather than engineering around its absence. Zero-party data is information a customer deliberately and knowingly hands over, a stated preference, a stated intention, a profile detail, usually through a preference centre, an onboarding quiz, or a loyalty sign-up, and usually in exchange for something concrete: better recommendations, an earlier offer, a genuinely improved experience. The identity resolution value of this is often underrated. Every zero-party data collection moment is also a natural opportunity to capture or reconfirm the deterministic identifier the rest of this stack depends on, since asking for an email address at loyalty sign-up is both a preference-capture moment and an identity-resolution moment at the same time, if the systems behind it are built to treat it that way.

A Framework For Where You Actually Stand

Reading the four sections above and concluding “we should do all of this” is the wrong response. Most organisations do not have an even gap across all four, they have a specific, identifiable weak point, usually the one nobody has looked at directly because it sits between two teams' ownership rather than inside either one. I built a scorecard for this, the same way the governance and risk-tiering work earlier in this series produced a working framework rather than a description of one: a self-assessment across first-party identifier capture, deterministic versus probabilistic match reliance, server-side tagging coverage, clean room usage, zero-party data collection, and consent architecture maturity, producing an overall resilience tier rather than a vague sense of where things stand. It is on the frameworks and tools page alongside the others.

None of this restores the world where a third-party cookie quietly did the identity work for you. That world is not coming back, and the businesses still planning around its return are the ones who will be most exposed when the next layer of restriction ships, because another one will. The foundation this series argued for from the beginning still holds. It just has to be built on purpose now, because nothing is going to assemble it by accident anymore.

Sources

• “Third-Party Cookie Blocking 2026: 18.6% of Browsers,” StatCounter-sourced data on current browser-level cookie blocking by default. https://termsandconditionstemplate.com/what-percentage-of-browsers-block-third-party-cookies
• “4 Apple Privacy Layers Breaking Safari Attribution (2026),” on ATT opt-in rates, ITP cookie caps, and iOS 26's Advanced Fingerprinting Protection and Link Tracking Protection. https://seresa.io/blog/server-side-tracking/four-apple-privacy-layers-fire-at-once-why-safari-attribution-is-breaking
• “Third-Party Cookies in 2026: What Actually Happened After Google's Reversal,” on Chrome's abandoned deprecation plan and the continued default blocking behaviour of Safari and Firefox. https://www.consenteo.com/knowledge-hub/cookies/third_party_cookies_2026_after_google_reversal