Third-party cookies, ITP and the data you're losing

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London, working with agency and in-house teams on the tracking behind their reporting.

We set up and repair GA4, Google Ads and Meta tracking for agency and in-house teams most weeks, and one question comes up every time conversions start sliding: what changed? Often nothing on your site changed at all. The browsers did. This is the explanation we give clients when third-party cookies and Safari’s ITP start quietly eating their numbers.

What are third-party cookies?

A third-party cookie is a cookie set by a domain other than the one in your address bar, usually an ad network, analytics vendor or embedded widget. First-party cookies belong to the site you are visiting; third-party cookies belong to someone else riding along on the page. That cross-site reach is what let advertisers recognise the same person across different websites, and it is exactly what browsers have spent years shutting down.

An example makes the split concrete. Visit an online shop, and the shop’s own cookie (remembering your basket) is first-party. An ad pixel on the same page, set by a network that also sits on hundreds of other sites, is third-party: the network, not the shop, controls it. The web platform documentation from MDN lays out the mechanics and notes that browsers are actively phasing this cross-site tracking out.

Why are browsers blocking third-party cookies?

Browsers block third-party cookies to stop cross-site tracking, and they are not all moving at the same speed. Safari and Firefox already block them by default; Chrome still allows them but lets users clear and block them, and Google has stepped back from forcing a switch. So the share of visitors whose third-party cookies simply do not exist has been climbing for years, well before any single deadline.

Safari has been the strictest for the longest. Its Intelligent Tracking Prevention (ITP) blocks all third-party cookies by default and also caps some script-set first-party cookies to seven days, per WebKit’s tracking prevention policy. Firefox followed with Enhanced Tracking Protection, which blocks third-party tracking cookies by default and isolates the rest so they cannot follow you between sites.

Chrome is the one that keeps moving, so treat any timeline as provisional. Google spent years planning to remove third-party cookies through its Privacy Sandbox project, reversed to a user-choice model in 2024, then in 2025 confirmed it would keep third-party cookies in Chrome and not ship the one-time prompt it had trailed. Google’s own Privacy Sandbox pages carry the current position. The practical read for a marketer: Chrome buys you time, Safari and Firefox already took theirs.

If you arrived here because a site told you to enable third-party cookies, that is a per-browser setting (in Chrome: Settings, then Privacy and security, then Third-party cookies). Turning them on fixes an embedded login or checkout that needs them on your own machine. It does nothing for the analytics gaps below, which happen on your visitors’ browsers, not yours.

What data are you actually losing?

When third-party cookies disappear, you lose the signals platforms use to connect a visit to a conversion and a person to an audience. In practice that shows up as under-counted conversions in GA4 and Google Ads, remarketing audiences that shrink in Meta and Google, and cross-domain journeys that break in the middle. The platforms fill those gaps with modelling, which is where over-reporting creeps in.

The loss is rarely a clean switch-off; it is a slow bleed. A returning Safari visitor whose cookie was cleared looks like a brand-new user, so your returning and new counts drift. A journey that hops from an ad domain to a landing page to a checkout on a different subdomain loses its thread when the connecting cookie is gone. Audiences built on third-party cookies lose members every week as those cookies expire and are not replaced.

Then there is the reporting you trust least once you know this. Platforms compensate for missing cookie signal with view-through and modelled conversions, and that is precisely how ad dashboards end up over-reporting against what the business actually banked. When we audit ad accounts, the biggest number on the dashboard is usually the least trustworthy: it leans hardest on modelling, because modelling is exactly the crutch cookie blocking forced the platform to lean on.

How do you check whether cookie blocking is skewing your data?

You check by comparing what your analytics claims against a source it cannot inflate, then splitting the gap by browser. Two comparisons find most of it: GA4 against the system that takes the money, and conversion rate in Safari against Chrome. A large Safari shortfall points straight at cookie and ITP loss rather than a seasonal dip.

1. Split GA4 by browser. In GA4, open Reports, then Tech, then Tech details, and add Browser as the dimension. Compare conversion rate or purchases for Safari against Chrome. A Safari figure sitting well below Chrome for the same audience is a cookie-loss signal, not a coincidence.
2. Reconcile against the back office. Compare GA4 conversions against the system that records the actual sale (Shopify admin, Stripe, or your CRM) for the same dates. GA4 sitting a little under the back office is normal; a gap that widens month on month is worth investigating.
3. See what actually loads. Run our free scanner, Sonar, on a key page to see which pixels, tags and cookies fire in a real visitor’s browser, and which are being set as third-party. It is one click, no account needed, and it reports what an outside visit can prove.

How do you recover the data lost to cookie blocking?

You recover it by moving measurement off third-party cookies, not by trying to bring them back. Three changes do most of the work: server-side tagging on your own domain, Consent Mode so blocked visits are modelled properly, and server-side conversion APIs so a blocked browser pixel is not the only path. None of it depends on the browsers reversing course.

1. Move tagging server-side. Run a server container (server-side GTM) on a first-party subdomain, for example sst.yourdomain.com, so the GA4 cookie is set first-party and survives Safari’s cross-site limits. The full walkthrough is in our server-side tracking guide, and it sits at the centre of how we approach tracking.
2. Set up Consent Mode v2. Pass the two consent signals (analytics_storage and ad_storage) so Google models the conversions that consent blocks instead of dropping them. We cover the ways this quietly leaks data in Consent Mode and the conversions it loses.
3. Send conversions through server APIs. Route conversions through Meta’s Conversions API and Google Ads enhanced conversions, so a browser that blocks the pixel is not the end of the signal. See why Meta CAPI setups under-report for the common mistakes.

One label to treat carefully: cookieless tracking. Useful cookieless measurement still uses first-party storage and server-side collection; it just stops relying on the third-party cookie. It is not a single product you buy, and it is not the same as switching tracking off.

How we fix this for clients

This is core tracking work, and we do it for agency and in-house teams most weeks. We move tagging server-side, get Consent Mode passing the right signals, and reconcile every platform against numbers the business can actually bank. On one subscription box brand, Meta’s dashboard claimed 6.9x more UK revenue than Shopify could confirm on the same ad spend, most of it modelled view-through that cookie loss had made unreliable. Stripping that back showed a channel that was still genuinely profitable, just not by the multiple the dashboard shouted.

If your conversions or audiences are shrinking and you are not sure whether it is the browsers, the consent setup or the tracking underneath, tell us what’s broken, or book a call. We will tell you where the data is going.