Third-Party Cookies Didn't Die. The Deprecation Did.

Last updated: September 8, 2026

Server-side tracking is the practice of collecting visitor events on infrastructure you control rather than in the visitor's browser, so the data reaches your analytics and identification tools from your own server instead of from a script running on the page.

For about five years it was sold mainly as preparation for one event, the removal of third-party cookies from Chrome. That removal was called off in April 2025, and it is not coming back on a new date, because no new date was ever set. The reasons to collect first-party data on your own infrastructure survived the cancellation. They are not the reasons most of the pages ranking for this topic still give.

KEY STATS

• On 22 April 2025 Google decided to keep offering third-party cookie choice in Chrome and not to roll out a standalone prompt, ending the planned deprecation (Google, Privacy Sandbox)
• On 17 October 2025 Google retired ten Privacy Sandbox technologies, among them Topics, Protected Audience and the Attribution Reporting API (Google, Privacy Sandbox)
• IP Protection was scheduled in April 2025 for a Q3 2025 launch and appears on the October retirement list (Google, Privacy Sandbox)
• Safari has blocked cookies for cross-site resources by default since 24 March 2020 (WebKit)
• Safari caps cookies set in third-party CNAME-cloaked HTTP responses at 7 days, closing the most common server-side workaround (WebKit, 12 November 2020)
• US search volume for "cookieless tracking" fell from 1,300 a month in August 2025 to 70 in July 2026, while "server side tracking" carries a $160.64 average CPC (Google Ads via DataForSEO, September 2026)
• Data sourced from two Google announcements, two WebKit engineering posts and Google Ads keyword data, compiled September 2026

What's in this guide:

• What Google actually announced
• What was retired, and what survived
• Why B2B identification never used third-party cookies
• What server-side collection does not fix
• How long each signal actually lasts
• What actually broke, and who it broke for
• The vocabulary is decaying too
• What to build instead
• Frequently asked questions

What Google actually announced

Two announcements matter, and they point in opposite directions. Most of the advice still circulating collapses them into one, which is how a reader ends up believing both that Chrome went cookieless and that Privacy Sandbox replaced the cookies. Neither of those things happened.

The first landed on 22 April 2025. Google had spent five years promising to remove third-party cookies from Chrome outright, softened that in mid-2024 into a standalone prompt that would put the decision to each user rather than making it for them, and then, eight months after that, dropped the prompt as well.

"we've made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." — Anthony Chavez, VP, Privacy Sandbox, Google (Privacy Sandbox)

Chrome's behaviour did not change. Third-party cookies are still available, users can still switch them off in settings, and no new deadline replaced the one that was withdrawn. If the plan was to survive a shutdown, there is nothing left to survive.

Google notes the pressures rather than hiding them. The post cites divergent perspectives across publishers, developers, regulators and the ads industry, and points back to the formal engagement it entered with the UK's CMA and ICO in 2022. That is a fairly direct way of saying the plan had become harder to land than the problem it solved.

The second announcement came on 17 October 2025, and it went the other way entirely. Having decided to keep cookies, Google no longer needed most of the replacement machinery it had spent six years building.

What was retired, and what survived

Google lists the retirements individually rather than describing them in general terms, which makes the whole set checkable.

Privacy Sandbox technology	Status as of 17 Oct 2025	What it was for
Topics	Retired	Interest-based ad targeting from browsing history
Protected Audience	Retired	Remarketing and custom audiences without cross-site identifiers
Attribution Reporting API	Retired	Conversion measurement across sites
IP Protection	Retired	Masking IP addresses from cross-site trackers
Private Aggregation, Shared Storage, SelectURL	Retired	Aggregate measurement primitives
Related Website Sets	Retired	Treating a company's several domains as one party
On-Device Personalization, Protected App Signals, SDK Runtime	Retired	The Android half of the initiative
CHIPS	Kept	Cookies partitioned per top-level site
FedCM	Kept	Federated sign-in without third-party cookies
Private State Tokens	Kept	Fraud and abuse signals without identifying the user

The takeaway: The three that survived are plumbing for sign-in, fraud and partitioned storage, not advertising. Everything built to replace cross-site ad targeting and measurement was cancelled. Google's stated reason was low adoption and ecosystem feedback about expected value. So the industry now has third-party cookies, no scheduled end date for them, and no replacement stack either.

IP Protection shows how fast the roadmap moved. In the April post, Google said it planned to launch it in the third quarter of 2025; by the October post, the same capability appears on the list of things being retired, which means it was announced and withdrawn inside six months without ever reaching the users it was described for. Read the roadmaps accordingly.

Why B2B identification never used third-party cookies

This question lands differently in B2B, and it's for a reason the cookieless-future genre leaves out.

A third-party cookie is one set by a domain other than the site you're on. Its purpose is to recognise the same browser across different websites. That is an advertising mechanism, and it answers exactly one question: have I seen this browser somewhere else. Useful for retargeting. Useful for frequency capping. Almost entirely useless for working out which company a business visitor works for.

B2B visitor identification answers a different question, and it does so with different inputs. As we covered in the pillar for this series, anonymous website visitor identification, the working methods are reverse-IP lookup mapped to firmographic records, a first-party tag on your own domain, an identity graph queried at the moment of the visit, and anything the visitor hands you directly by clicking a tracked link or logging in. The five methods are broken down in how to identify anonymous website visitors.

Not one of those depends on a cookie set by someone else's domain. Reverse-IP resolution uses no cookie at all; it reads the network the request arrived from and looks that up. A first-party tag sets a cookie on your own domain, which was never in scope for the deprecation, because the deprecation only ever covered cookies set by a domain other than the one in the address bar. Graph lookups happen server to server, where a browser policy has no reach.

There's a second reason the cookie question was always the wrong one to worry about here. The thing that degrades a B2B contact record is not cookie policy, it's time. Contact data decays by roughly 22.5% to 30% a year as people change jobs and companies restructure, and no browser setting affects that rate in either direction. A team that spent 2024 planning a cookie migration and left its enrichment stale had the priorities backwards.

So the sequence for most B2B teams is short. The deprecation would not have broken your identification. The cancellation repairs nothing. Neither event moved the number that matters. If a vendor told you their product needed rebuilding for a cookieless world, that was always a statement about their own architecture rather than about the web.

Every few months a prospect asks how Signal will survive the death of third-party cookies. It never used them. Identification runs on our own tag against our own resolution, so the question doesn't reach us, and I'd rather say that than sell a migration nobody needs. — Bob Thordarson, Geysera CEO

What server-side collection does not fix

None of this makes server-side collection pointless. It moves collection out of reach of ad blockers and browser extensions, keeps API keys off the client where anyone can read them, cuts the volume of third-party JavaScript the page has to load and execute, and gives you one place to filter, enrich and validate events before any of them reach a warehouse. Those benefits are real. None of them was ever about Chrome.

What server-side collection does not do is extend the life of a tracking cookie in Safari, and this is where a lot of vendor material overpromises. The usual pitch runs like this: route collection through a subdomain of your own site, set the cookie from your own infrastructure, and the browser will treat it as first-party and leave it alone. Safari closed that route in 2020.

"ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days." — John Wilander, WebKit (CNAME Cloaking and Bounce Tracking Defense, 12 November 2020)

The mechanism explains why the workaround looked so convincing, and why it's still being sold. Browsers generally treat everything under one registrable domain as the same party, so analytics.yoursite.com counts as first-party to yoursite.com. A CNAME record lets you point that subdomain at a vendor's infrastructure underneath the web layer, in DNS. The browser sees your domain; the traffic goes to the vendor. WebKit describes this arrangement as cloaking, and the same post reports that cross-site trackers had persuaded site owners to set it up in order to get around ITP's existing seven-day cap on cookies set in JavaScript.

So there are now two caps rather than one, and a CNAME setup moves you between them rather than out of both. Any vendor still selling a subdomain proxy as a way to restore long-lived identity in Safari is describing the web as it was in 2019.

None of this makes server-side collection worthless in Safari. It does mean the durable part of what you collect there must be something other than a long-lived cookie, because a long-lived cookie is precisely what Safari will not give you.

How long each signal actually lasts

Signals fail in different browsers, for different reasons, on very different timescales. Sorting them by what actually ends them is more useful than sorting them into cookie and cookieless.

Signal	How it's set	What limits it
Third-party cookie	A response from a different registrable domain	Blocked by default in Safari since March 2020; available by default in Chrome, and the user can switch it off
First-party cookie set in JavaScript	document.cookie on your own domain	Capped at 7 days by Safari's ITP
First-party cookie set through a CNAME alias to a vendor	A DNS alias pointing your subdomain at a third party	Capped at 7 days by Safari since November 2020
First-party cookie set by your own server	Set-Cookie from your own origin, not an alias	Outside the CNAME cap, because the response comes from your own infrastructure; still gone when the user clears cookies
Reverse-IP to company	No cookie involved	Accuracy of the IP-to-firmographic mapping; shared offices and mobile networks
Identifier the visitor hands you	A tracked link, a form, a login	Nothing browser-side; coverage is the constraint, not lifetime

The takeaway: The two rows at the bottom are the ones a cookie policy cannot touch, and they are the two that carry most B2B identification. That is the practical reason this category was insulated from the deprecation drama. It is also why the durability conversation should start with which signals you actually depend on, rather than with which browser changed what.

What actually broke, and who it broke for

Something real did break in October 2025, and it's worth being precise about who felt it, because it wasn't the people who spent two years worrying.

The Attribution Reporting API was the sanctioned way to measure conversions across sites without cross-site identifiers. Teams that had migrated their measurement onto it, mostly ad platforms and the agencies building against them, now have to rehome that work. Topics was the replacement for interest-based targeting from browsing history, and it went the same way. Google reports low adoption alongside ecosystem feedback about their expected value as the reason for both.

That is a real cost, and it landed almost entirely on the advertising side. If your use of the web is running campaigns and measuring them across other people's sites, the last eighteen months removed both the old plan and its replacement. If your use of the web is understanding who visits your own site and routing them to sales, very little in either announcement touches your stack. The two audiences read the same headlines and drew the same conclusion, which is how a category with almost no exposure ended up planning a migration it never needed.

The vocabulary is decaying too

There's a measurable footprint of all this in search demand, and it's re-pullable rather than asserted.

Monthly US search volume for "cookieless tracking" ran at 1,300 in August 2025. By July 2026 it was 70. "Server side tracking" fell from 880 to 210 across the same window, and "cookieless future" from 260 to 50. Google Ads reports these in rounded buckets, so treat the shape as directional rather than precise. The shape is unambiguous.

The commercial terms held up better than the panic terms. "First party data" still runs 880 a month, and "server side tracking" carries a $160.64 average CPC, which is the highest head-term CPC anywhere in this series. People are still buying the tooling. They stopped searching for the emergency.

What to build instead

If you were holding a cookie-migration project open, here's what's actually worth doing with that budget.

1. Find out which of your signals depend on a third-party cookie. For most B2B stacks the answer is your ad pixels and nothing else. Identification, analytics and CRM enrichment usually sit outside it. This audit takes an afternoon and it ends the question permanently.
2. Move collection server-side for the reasons that are true. Ad-blocker loss, page weight, and keeping credentials off the client are all worth the work. Do not budget it as cookie insurance.
3. Stop depending on cookie lifetime for identity. Anything you need to persist beyond a week in Safari has to live in your own systems, keyed to a resolved company or person, not to a browser.
4. Treat the retired APIs as retired. If any measurement you rely on was built on Attribution Reporting or Topics, that work needs rehoming, and this is the one item on the list with a real deadline attached.
5. Re-read your vendors' claims against these two announcements. A page still promising to prepare you for the end of third-party cookies has not been updated since April 2025, which tells you something about the rest of it.

Frequently asked questions

Are third-party cookies going away?

Not in Chrome. On 22 April 2025 Google decided to maintain its existing approach of offering users third-party cookie choice and not to roll out a standalone prompt, which ended the planned deprecation. Safari has blocked cookies for cross-site resources by default since March 2020, so the answer depends on the browser.

What happened to Privacy Sandbox?

Google retired most of it on 17 October 2025, citing low adoption and ecosystem feedback. Topics, Protected Audience, the Attribution Reporting API and IP Protection are among the technologies withdrawn. CHIPS, FedCM and Private State Tokens were kept, and work continues on an interoperable attribution standard through the W3C.

Does server-side tracking bypass Safari's restrictions?

No. Safari's ITP caps cookies set in JavaScript at seven days, and since November 2020 it applies the same seven-day cap to cookies set through third-party CNAME-cloaked HTTP responses. Server-side collection has real benefits around ad blockers and page weight, but it does not extend cookie lifetime in Safari.

Did the cookie deprecation affect B2B visitor identification?

Very little. B2B identification runs on reverse-IP company resolution, a first-party tag on your own domain, identity-graph lookups made server to server, and identifiers visitors supply directly. None of those requires a cookie set by another domain, so the deprecation and its cancellation both largely passed the category by.

What is the difference between first-party and third-party data collection?

First-party collection records behaviour on your own domain, under your own control and your own consent notice. Third-party collection observes the same browser across sites owned by other people. The first was never in scope for the deprecation; the second is what the whole argument was about.

Should I still move to server-side tracking?

Often yes, for reasons unrelated to cookies. It recovers events lost to ad blockers, keeps API keys off the client, cuts third-party JavaScript in the page, and gives you one place to filter and enrich events. Budget it as a data-quality and performance project rather than as compliance work.

Continue the Series

This is Post 8 in Geysera's 13-part series on B2B anonymous visitor identification.

• Post 1 — Anonymous website visitor identification: the complete 2026 guide (pillar)
• Post 2 — How to identify anonymous website visitors: 5 methods and what each delivers
• Post 3 — What is an identity graph? How anonymous visitors get matched to real people
• Post 4 — Match rates decoded: why 40%+ person-level claims are usually fiction
• Post 5 — B2B intent data explained, and why most of it is flawed
• Post 6 — Person-level vs company-level identification

Sources

• Next steps for Privacy Sandbox and tracking protections in Chrome — Anthony Chavez, VP Privacy Sandbox, Google, 22 April 2025
• Update on Plans for Privacy Sandbox Technologies — Anthony Chavez, Google, 17 October 2025; the named retirement list
• Full Third-Party Cookie Blocking and More — John Wilander, WebKit, 24 March 2020
• CNAME Cloaking and Bounce Tracking Defense — John Wilander, WebKit, 12 November 2020; the seven-day CNAME cap
• Search volume and CPC: Google Ads via DataForSEO, United States, pulled 2026-09-03