Google formally dissolved the Privacy Sandbox initiative on October 17, 2025, six years after announcing it. The Attribution Reporting API and Protected Audience API are scheduled for phaseout in Chrome and Android. Third-party cookies are staying. The “cookieless future” your tracking plugin was sold on in 2023 is officially canceled.
That does not mean your tracking is fine. Safari ITP still caps cookies at 7 days. Ad blockers still drop 31.5% of users (Statista, 2024). iOS ATT still erodes Facebook attribution. EU consent rejection still lands at 40-70%. Privacy Sandbox would not have fixed any of it for non-Chrome browsers anyway.
What Actually Died on October 17
The Privacy Sandbox was Google’s six-year attempt (2019-2025) to replace third-party cookies with browser-native APIs that preserved ad targeting and attribution without per-user identifiers. The dissolution covers the entire framework. The pieces that go away:
- Attribution Reporting API — the cookie-free conversion attribution layer. Was supposed to give advertisers aggregated reports without identifying individual users. Scheduled for phaseout in Chrome.
- Protected Audience API (formerly FLEDGE) — the on-device auction layer for remarketing. Mediavine measured it adding an average 1500ms of latency and dropping ad visibility to 39% in March 2024 (Mediavine via Don Marti, 2024). Now phasing out.
- Topics API — the contextual interest categorisation layer. Was meant to replace cookie-based behavioural targeting with a small list of topics derived locally on the user’s browser.
- IP Protection — the proxy-routing component intended to mask IP addresses from advertisers. Effectively shelved with the broader initiative.
Google’s own status page confirmed on April 22, 2025 it would not introduce a separate prompt to phase out third-party cookies in Chrome. By October 17, the entire initiative was wound down. The proximate causes given were low advertiser adoption and regulatory pressure from the UK Competition and Markets Authority, which had been treating Sandbox as a competition issue since 2020.
Translation: Google promised a future. They cancelled it. Your tracking still has to work tomorrow morning.
The Tracking Plugins That Were Built For This
Between 2023 and 2024, WordPress merchants were sold a wave of “Sandbox-ready” and “cookieless-future” tracking plugins. The pitch was always some version of: third-party cookies are going away in Chrome, you need a tracking layer that uses the new browser APIs, this plugin handles it. Many merchants paid for this. Some paid annual licences on it.
Those features now exist for a future that never arrived. Attribution Reporting API integrations have nothing to attribute through. Protected Audience hooks point at endpoints Chrome is winding down. Topics API targeting reads classifications that will be phased out of the browser. The plugins keep updating, but the Sandbox-specific code paths are dead weight in their config screens — feature flags for an API that no longer ships.
The audit is straightforward. Open your tracking plugin’s settings page. If you see references to Topics API, Protected Audience, FLEDGE, or Attribution Reporting in active configuration, those features are dead code. Disabling them does not break anything that is currently working.
What Sandbox Was Never Going To Fix Anyway
The harder truth: even if Privacy Sandbox had shipped exactly as designed, it would not have solved the actual data-loss problems WordPress stores face. The Sandbox was a Chrome-only project. The data evaporates everywhere else.
Safari’s Intelligent Tracking Prevention caps first-party cookies at 7 days and blocks third-party cookies entirely. Sandbox APIs do not run in Safari, and Apple has shown zero interest in implementing them. We documented how even server-side GTM no longer survives Safari’s 7-day cap unless the IP-matching rule lines up — see Server-Side GTM No Longer Beats Safari’s 7-Day Cookie Cap.
Ad blockers strip 31.5% of global web users. Sandbox APIs run inside the browser; ad blockers block the network requests that talk to them.
iOS ATT erodes Facebook Pixel attribution at the device level — also outside Chrome’s reach.
EU consent rejection runs 40-70% on most stores. When a user clicks Reject on the consent banner, no Sandbox API gets called either. The Mike Teasdale 90% drop is what happens when a compliant-looking cookie banner blocks consent at the moment Google’s tag library expects it.
79% of Americans express concerns about online tracking; 91% prefer personalised recommendations from brands (Kevel, 2026). The contradiction Sandbox tried to resolve was real. The Sandbox failed to resolve it. The contradiction remains.
The Architecture That Survived
The tracking architecture that did not depend on the Sandbox shipping is the one that does not run in the browser at all.
WooCommerce fires PHP action hooks on the server every time something happens — woocommerce_add_to_cart, woocommerce_checkout_order_processed, woocommerce_thankyou. Those hooks fire regardless of which browser the customer used, regardless of whether their consent was granted or rejected, regardless of which tracking-blocking extension is installed. Capture at that layer and the Sandbox shipping or not shipping is irrelevant.
This is also where the modeled-data conversation lives. When client-side pixels fail and platforms compensate with conversion modelling, the modeled numbers come from a sample. We covered this in Cookieless Pings vs No Tracking — the cookieless ping is a different thing from the model, and neither replaces the actual server-side event.
The question isn’t which browser API will replace the cookie. The question is whether your tracking should depend on the browser at all.
How Seresa Tracks Through the Sandbox Funeral
Transmute Engine™ is a first-party Node.js server that runs on your own subdomain (for example, data.yourstore.com). The inPIPE WordPress plugin captures events at the WooCommerce PHP hook layer and sends them via API to the Transmute Engine server, which routes them simultaneously to GA4, Meta CAPI, Google Ads Enhanced Conversions, and BigQuery. No browser API. No Chrome dependency. The Sandbox shutting down is not a Seresa problem — it is validation that the architecture choice was the right one.
Key Takeaways
- October 17, 2025 — Privacy Sandbox formally dissolved after six years. Attribution Reporting API and Protected Audience API are scheduled for Chrome phaseout.
- Third-party cookies are staying. Google announced April 22, 2025 it would not phase them out in Chrome. The “cookieless future” pitch is officially canceled.
- “Sandbox-ready” plugin features are dead code. Audit your tracking plugin: Topics API, Protected Audience, FLEDGE, and Attribution Reporting integrations have nothing to integrate with.
- Sandbox would not have fixed Safari, ad blockers, iOS ATT, or EU consent rejection — none of which run on Chrome’s privacy APIs. Those data-loss vectors are unchanged by the dissolution.
- Server-side capture at WooCommerce PHP hooks is the architecture that did not depend on a Google promise. It works in Safari, Firefox, ad-blocked sessions, and consent-denied sessions identically.
FAQ
Google cited low advertiser adoption and regulatory pressure as the reasons for dissolving the initiative on October 17, 2025. The UK Competition and Markets Authority had been treating Privacy Sandbox as a competition issue since 2020, and advertisers found the privacy-preserving APIs added significant latency and lower ad visibility (Mediavine measured 1500ms additional latency and 39% ad visibility on Protected Audience). Google formally announced on April 22, 2025 it would not phase out third-party cookies in Chrome — that was the first signal the program was winding down.
Not in Chrome. Third-party cookies are staying in Chrome indefinitely after Google’s April 22, 2025 announcement. But the cookieless reality already exists in Safari (Intelligent Tracking Prevention), Firefox (Total Cookie Protection), iOS apps (App Tracking Transparency), and any session where a user runs an ad blocker or rejects consent. Roughly 31.5% of global web users run ad blockers regardless of which browser they choose. The cookieless future arrived everywhere except Chrome.
No formal replacement was announced. The platforms continue to rely on a mix of third-party cookies (in Chrome), conversion modelling (where cookies fail), and server-side conversion APIs — Meta Conversions API, Google Ads Enhanced Conversions, Microsoft UET CAPI. Server-side conversion APIs are the only attribution path that does not depend on the browser at all, which is why server-side first-party tracking on your own subdomain is the durable answer regardless of which browser API ships next.
Probably not — but you should audit which features it is actually running. Open the plugin settings and look for references to Topics API, Protected Audience, FLEDGE, or Attribution Reporting API integrations. Those features are dead code now. Disabling them does not break anything that is currently working. The plugin’s other tracking features (page view, add-to-cart, purchase events) may still function. The plugin is only dead weight if all of its functionality was Sandbox-dependent.
Sandbox is dead. Cookies are staying. Safari, ad blockers and consent banners didn’t get the memo. See how Transmute Engine captures every WooCommerce order on your own subdomain — no browser API required.
