Tracking after third-party cookies: what actually still works
Third-party cookies didn't die the way everyone braced for. The exposure that's actually truncating your attribution is first-party cookie lifetime, and it hits every stack, consent banner or not. A per-browser status check, the lifetime table to bookmark, and the three tracking mechanisms that still work.
Everyone spent five years prepping for the death of the third-party cookie, and in Chrome it never came. Safari blocked them in 2020 and Firefox partitioned them in 2022, but Chrome reversed course and retired the replacement project, so third-party cookies still work for most of your traffic. The exposure that's quietly truncating your attribution is a different one: first-party cookie lifetime, which keeps shrinking on every stack, consent banner or not, and takes your attribution windows down with it. The practitioner takeaway is more useful than the obituary, so this page is built around it.
#The 60-second status check
Which browser killed what, and when. The current state in four lines:
- Safari: all third-party cookies blocked outright since March 2020 (WebKit: full third-party cookie blocking). Intelligent Tracking Prevention (ITP) also caps first-party cookie lifetimes, the part that matters below.
- Firefox: Enhanced Tracking Protection blocks known tracking cookies; since June 2022, Total Cookie Protection partitions all third-party cookies per site (Mozilla's ETP doc): a cookie set under site A is invisible under site B, which kills cross-site identity even though the cookie technically exists.
- Chrome: never shipped the deprecation. Google reversed course in July 2024, dropped the planned user-choice prompt in April 2025, and in October 2025 retired the Privacy Sandbox measurement APIs (Topics, Protected Audience, Attribution Reporting) built to replace cookies (Privacy Sandbox: third-party cookies status). Third-party cookies work in Chrome by default today; users can turn them off, and Incognito blocks them.
- Edge and the rest: Chromium-based browsers broadly follow Chrome's defaults, with their own tracking-prevention layers on top.
So the years of "cookiepocalypse" countdowns resolved to: two browsers already did it quietly, and the one with the market share decided not to. That's the news. The operational story was never the news cycle.
#The cookie-lifetime table
This is the asset to bookmark: browser × cookie type × how it was set × what you actually get. "First-party" stopped being one category the day ITP started distinguishing how a cookie is written: a JavaScript-set cookie and an HTTP-response-set cookie now live entirely different lengths in Safari.
| Browser | Cookie | Set by | Effective lifetime | What breaks |
|---|---|---|---|---|
| Safari | Third-party | any | Blocked (since 2020) | All cross-site pixels and identity |
| Safari | First-party | JavaScript (document.cookie) | 7 days (ITP 2.1+); 24 hours when the visit carries ad-click link decoration from a known tracker (ITP 2.2+). WebKit | Client-set analytics/ad cookies: GA4 client ID, script-written click-ID cookies; returning visitors become "new" after a week |
| Safari | First-party | HTTP Set-Cookie (your server) | As declared, no ITP age cap; 7 days if set via a CNAME-cloaked third-party subdomain (Safari 14+) | Little. This is the durable path, and why server-set identifiers matter |
| Safari | localStorage & script-writable storage | JavaScript | Deleted after 7 days of Safari use without visiting the site (ITP 2.3+). WebKit | "We'll just use localStorage instead" workarounds |
| Firefox | Third-party | any | Partitioned per site (Total Cookie Protection, 2022); known trackers blocked | Cross-site identity; embedded widgets keep working |
| Firefox | First-party | either | As declared; storage from known tracker domains is periodically purged absent interaction | Mostly nothing for your own domain |
| Chrome | Third-party | any | Still works by default; user-off switch; blocked in Incognito | Nothing yet, by default |
| Chrome | First-party | either | As declared, capped at 400 days (Chrome 104+). MDN Set-Cookie | Multi-year "remember me" and long attribution cookies quietly renew or die at 400 days |
Read the Safari rows twice: they're the whole argument. The third-party row gets the headlines; the 7-day JavaScript row is what actually bites most stacks, because nearly every analytics and advertising cookie on a default setup is script-set.
#What that does to your attribution
A 7-day cookie against a 30-day consideration cycle silently truncates your attribution. Concretely: a Safari user clicks your ad on the 1st, browses, returns through organic search on the 12th, and buys. With a script-set identifier, the cookie died on the 8th, so the purchase books as a fresh organic visitor, the ad gets nothing, and no error appears anywhere because nothing "broke." Multiply by Safari's traffic share and you get a permanent, invisible skew: channels with short click-to-convert cycles look better than they are, and considered-purchase channels look worse. Ad platforms' own click-ID cookies are on the same clock, which is one standing reason platform and analytics numbers disagree (Why your GA4 and Google Ads conversions don't match triages the rest).
#What still works #1: first-party data and server-set identifiers
The durable identity path is first-party data: relationships you hold
directly (emails, logins, CRM records) keyed by identifiers your server
sets. Per the table, an HTTP Set-Cookie from your own domain keeps its
declared lifetime in Safari; script-set cookies don't. That one distinction
is the technical core of most "cookieless-resilient" architecture, and it's
measurable: Buron's own first-party pixel runs exactly this pattern, and
identifier survival (which identifiers still resolve at day 8, day 30,
Safari vs Chrome) is a monitored number, not an assumption. The pattern
(illustrative; run it on your own traffic): script-set identifiers
re-identifying almost no returning Safari visitors past day 7, server-set
identifiers still re-identifying them weeks later, and Chrome showing
barely any difference between the two. The operating model (what to
collect, where it lives, how it feeds activation) is
First-party data: the definition and the operating model's territory.
#What still works #2: server-side event paths
Server-side tracking (Conversions APIs and server-side tagging) moves event delivery from the browser to a server channel, which restores the events ad blockers and ITP's script rules eat, and enables server-set cookies from your own subdomain. The concept and its limits are Server-side tracking: what it fixes, what it costs, and whether you need it; the sGTM implementation is Server-side tagging with sGTM: setup, costs, and when it's not worth it. The honest limit belongs in this paragraph, not a footnote: server-side does not mint immortal cookies. It changes who sets the identifier and how reliably events arrive; it does not recreate cross-site identity, and a user who clears state or switches devices is still gone. Server-side is signal plumbing, not identity resurrection.
#What still works #3: modeled and aggregated measurement
The third mechanism concedes the user-level match and estimates the aggregate instead. Consent mode's conversion modeling is the canonical example (denied users' conversions estimated from consented patterns, and Consent Mode v2 without losing your signal covers keeping that machinery alive), and the same logic extends up the stack to attribution modeling on your own data and, at the top, media mix modeling. Estimates are real signal: they keep totals honest and bidding fed. They are also estimates, error bars rather than receipts, and mixing them into reports without knowing which rows are modeled is how teams end up arguing with their own dashboards.
#What doesn't work: fingerprinting and the parity pitch
Two things deserve a plain no. Device fingerprinting (identifying users by browser/device characteristics) is what browser makers are actively hunting (ITP exists because of it), sits on the wrong side of GDPR consent requirements, and degrades unpredictably as browsers randomize the signals; building your measurement on it means building on ground the browser makers are actively removing. And the broader "cookieless parity" pitch, that some tool restores everything third-party cookies did, fails on arithmetic: the three durable mechanisms above each recover part of the signal. The honest position is triangulation between partial signals, not a new perfect one. Perfect user-level tracking is over; trustworthy measurement isn't.
The trap in all of this is treating it as a one-time migration. There is no finish line: Safari's caps moved several times, Chrome added a 400-day ceiling, and the next browser release will move them again, each change silently re-truncating attribution nobody re-checked. So the durable posture isn't a cookieless architecture you build once, it's knowing, on your own traffic, which identifiers still survive and where coverage just thinned. Buron's first-party pixel and signal-coverage checks measure exactly that: which identifiers resolve at day 8 versus day 30, where coverage drops, and when a browser update moves the numbers, so a lifetime change shows up as a dated finding instead of a quarter of quietly decaying attribution. This page's table carries its last-reviewed date for the same reason: it will need reviewing again.
Frequently asked questions
Are third-party cookies gone?
In Safari and Firefox, effectively yes: Safari has blocked them outright since March 2020 and Firefox has partitioned them per site since June 2022. In Chrome, no: Google reversed its deprecation plan in 2024, dropped the planned choice prompt in April 2025, and retired its Privacy Sandbox replacement APIs in October 2025. Third-party cookies still work in Chrome by default.
When do cookies expire?
Whenever their Expires/Max-Age says, unless the browser overrules it. Safari caps script-set first-party cookies at 7 days (24 hours after ad-click link decoration). Chrome caps all cookies at 400 days. Server-set first-party cookies keep their stated lifetime in Safari and Firefox within those rules. The practical answer is per-browser; see the lifetime table.
Is cookieless tracking possible?
Partly, through three mechanisms: first-party data with server-set identifiers, server-side event paths (Conversions APIs and server-side tagging), and modeled or aggregated measurement like consent mode's conversion modeling. Each recovers some signal; none recreates the user-level cross-site graph third-party cookies provided. Anyone claiming full cookieless parity is overselling.