Life After Third-Party Cookies: What Changed for Analytics
Chrome kept third-party cookies. Safari never did, and Firefox partitions them. The measurement problem was never one browser announcement — it was the slow end of cross-site identity.
For four years the industry planned around a date: the day Chrome would remove third-party cookies. That date kept moving, and in 2024 Google abandoned the removal entirely in favour of letting users choose, then confirmed in 2025 that no separate choice prompt would ship either. Third-party cookies are still there in the browser with the largest share.
The measurement problem did not go away with the deadline, because the deadline was never the cause. Cross-site identity has been eroding for years in ways that no announcement reversed.
Where each browser stands
| Browser | Third-party cookies | First-party storage |
|---|---|---|
| Safari | Blocked by default, and has been for years | Cookies written by JavaScript capped at seven days, one day in some cross-site cases |
| Firefox | Not blocked — partitioned per site by Total Cookie Protection, so a third party gets a separate jar on each site | Standard lifetimes, with additional limits for known trackers |
| Chrome | Still allowed; removal cancelled | Standard lifetimes |
The distinction between blocking and partitioning matters more than it sounds. A partitioned cookie still works for the site the user is on — it simply cannot be read from another site. Anything that depended on recognising the same browser across domains is broken; anything first-party continues.
What broke, in order of impact
Cross-site attribution. The click on an ad and the purchase two weeks later can no longer be linked by a shared identifier on Safari and, in effect, on Firefox. Ad platforms fill the gap with modelling, which is a reasonable estimate and not a record of events.
Retargeting reach. Audiences built on third-party identifiers shrink to the share of users on browsers that still allow them. The audience did not change; your ability to see it did.
Frequency capping across sites. Without a shared identifier there is no way to know a person saw the same ad on three different publishers.
Long lookback windows. On Safari a script-set cookie expires in a week, so a 30-day window is honest only for a fraction of visitors. Reported “new” visitors rise, returning share falls, and neither reflects behaviour.
What did not break: on-site analytics. Sessions, entry pages, engagement, funnels within one domain — all of that runs on first-party storage and continues to work.
The first-party cookie problem nobody planned for
Teams that migrated everything to first-party storage often assumed the issue was solved. It is not, because the limit applies to how the cookie is set, not to who owns the domain. A cookie written by JavaScript on your own site still expires in seven days on Safari. A cookie set by your server in an HTTP response header does not.
That single difference — document.cookie versus Set-Cookie from your own origin — is the practical case for server-side tagging. It is not about hiding from ad blockers; it is about identifiers that survive the week.
Two caveats keep it honest. Using a subdomain that resolves to a third-party service to disguise its origin is a pattern browsers already act against. And a longer-lived identifier is still personal data, with the consent obligations that follow.
What to rebuild
Move to first-party server-set identifiers where you need continuity. Set the cookie from your own infrastructure, keep it to what you need, and document the retention.
Shorten your reported attribution windows to match reality. A 30-day model produces numbers you cannot reproduce. A seven-day window that agrees with the data is more useful than a long one that quietly relies on modelling.
Lean on datasets that never needed identity. Search Console reports queries and impressions without touching a visitor. Server logs record every request. Order data in your own database is the ground truth for revenue. None of these degrade when a browser changes policy.
Use the identity you legitimately have. A logged-in account, an order email, a newsletter subscriber — with proper consent, these join sessions across devices in a way no third-party cookie ever did accurately.
Adopt incrementality over last-click. Holdout tests and geo splits answer “did this spend cause sales” without any identifier at all. They are more work than reading an attribution report, and they survive every future browser change.
What not to do
Fingerprinting — assembling a stable identifier from screen size, fonts, canvas rendering and headers — is the obvious workaround and a bad idea. Browsers actively counter it, regulators treat it as processing of personal data without the transparency consent implies, and it fails silently rather than visibly, which makes the resulting data worse than none.
Equally, do not treat modelled conversions as observations. They are useful for direction and misleading in a spreadsheet next to real numbers. Label them.
The reporting habit that helps most
Publish two numbers rather than one: what you observed, and what the platform modelled. When the gap widens, that is information — usually a consent change, a browser update, or a tag that stopped firing on a subset of traffic. A single blended number hides exactly the signal you need.
The end state is not a replacement for the third-party cookie. It is a smaller set of measurements you can actually defend, and a habit of saying which is which.
Ethan Lewis
Ethan Lewis has spent a decade wiring analytics into sites that were never built for it — e-commerce carts, membership portals, marketing sites with three tag managers. He writes Statlyzer to keep the answers in one place.
Keep reading
-
Web Analytics
Google Analytics 4: The Complete Guide
6 min read
-
Web Analytics
GDPR for Web Analytics and Marketing: A Compliance Guide
6 min read
-
Web Analytics
Understanding Dwell Time: Why It Matters Even to Small Blogs
5 min read