Privacy Sandbox Explained: What It Was and What Comes Next

"We've made the decision to maintain our current approach to offering users third-party cookie choice in Chrome." That was Google's statement on April 22, 2025. Six months later, on October 17, 2025, Google retired most of the Privacy Sandbox APIs it had spent six years building.

The initiative launched in 2019 with a clear goal: replace cross-site tracking with privacy-preserving alternatives that kept ad tech and digital advertising functional. It ended with a quiet blog post, a long retirement list of APIs, and an industry largely back where it started.

According to a March 2025 Deloitte report, only 15% of global marketers felt fully prepared for a cookieless environment, despite years of warnings. The Privacy Sandbox was supposed to solve that. It did not.

This article covers what the Google Privacy Sandbox was, how it actually worked, what killed it, and what the end of this initiative means for DSPs, publishers, and programmatic advertisers.

What Is Privacy Sandbox?

Privacy Sandbox is a project launched by Google to address issues in Internet advertising, such as ad irrelevance, lack of user privacy, and cross-platform covert tracking.

Google Privacy Sandbox explained simply: It was Google's attempt to give advertisers a way to run targeted advertising without tracking individual users across websites, by processing data locally in the Chrome browser rather than sending it to external servers. 

In more complex terms, Privacy Sandbox is a project designed to develop new, privacy-focused methods for delivering targeted ads and measuring ad campaign performance. 

How exactly?

We’ll discuss all the protocols in detail a bit later. For now, you need to know that Google uses a set of privacy-preserving standards. These include differential privacy (adding noise to data to protect individual identities) and on-device processing (analyzing data directly on the user's device rather than sending it to external servers). 

If you have been searching for what is Privacy Sandbox and whether it still matters, the answer in 2026 is: it was a set of browser APIs Google built to replace third-party cookies, and it is now retired. 

The Story Behind the Privacy Sandbox

The tale of the Privacy Sandbox begins in 2018. Let’s have a short look at history.The Privacy Sandbox timeline stretched from 2019 to 2025, a six-year period of proposals, delays, regulatory interventions, and ultimately full retirement, making it one of the most drawn-out pivots in ad tech history.

Why Google Created the Privacy Sandbox

There are two major reasons for the birth of the Privacy Sandbox, and they are deeply connected.

The first is, of course, third-party cookies. You probably know what those are, but here’s a short course for the uninitiated.

Third-party cookies are basically HTTP trackers generated by your device and tracked by websites you’re not currently using. Unlike first-party cookies, which work only with websites you’re on and store your language preferences, shopping cart, or movie timecode, their primary purpose is advertising. 

Obviously, having files that store your data for later sale is quite creepy. But believe it or not, the lack of consumer privacy enhancing technologies isn’t the only pitfall of third-party cookies.

Namely, cookies are limited to a single device and are often irrelevant to the user's actual searches. So, instead of getting relevant ads, the user gets only irritation.

But let’s be honest: Google would never consider phasing out cookies without “external intermission.” The GDPR, introduced in 2018, strongly highlighted the major concerns above and urged search providers to address them (or else!).

The Privacy Sandbox Google proposed in 2019 was developed in collaboration with the World Wide Web Consortium (W3C) and involved extensive industry testing, which makes its quiet retirement in 2025 more surprising to observers who had followed its development closely. 

Safari and Firefox took action immediately, while Chrome, being responsible for 60% of the world’s digital ad spend, promised to change, but not right now. And so began the cycle of false promises.

The Timeline of Privacy Sandbox Development

We’re not an Internet archive, so let’s be quick with the events.

2019: Google announces the Privacy Sandbox, outlining plans to create a set of open standards to enhance privacy on the web. Google also promises to kill cookies sometime in the future.

2020: Introduction of Federated Learning of Cohorts (FLoC), a proposal to group users based on similar browsing behaviors instead of creating creepy profiles on each.

2021: Due to how badly it performed on tests, FLoC is replaced by the Topics API, focusing on user interests without detailed tracking.

2022: Google delays the phase-out of third-party cookies to 2024, citing the need for more time to develop and test alternatives. Privacy Sandbox is very far from release.

2023: Another delay is announced, pushing the deprecation of third-party cookies to 2025.

July 2024: Cliffhanger! Google reverses its decision, opting to retain third-party cookies and allow users to enable or disable them. According to IAB, “88% of industry professionals feel Google’s decision to reverse the phase-out of third-party cookies has caused major confusion in digital advertising.”

April 22, 2025: Google officially abandons the plan for a standalone cookie prompt. The company confirms it will keep third-party cookies in Chrome with existing user controls, effectively ending the cookie deprecation timeline. The Privacy Sandbox initiative, in its original form, is over.

Mid-2025: The UK's Competition and Markets Authority releases Google from its legally binding commitments related to third-party cookie deprecation. Regulators across the US, UK, and EU had scrutinized the Privacy Sandbox initiative over concerns it would strengthen Google's position in the ad tech market and reduce transparency for ad tech companies outside Google's ecosystem.

October 17, 2025: Google formally retires most Privacy Sandbox APIs. The retirement list includes the Attribution Reporting API, IP Protection, On-Device Personalization, Private Aggregation (including Shared Storage), Protected Audience, Protected App Signals, Related Website Sets, SelectURL, SDK Runtime, and Topics, across both Chrome and Android. Anthony Chavez, VP of Privacy Sandbox at Google, cites "low levels of adoption" and "ecosystem feedback about expected value" as the primary reasons.

So, there we have it, one huge pile of mess. The cookies are here and aren’t going to leave anytime soon. The Sandbox is under development, even though it directly contradicts its stated purposes. And surprisingly enough, Google has not even sued for gaslighting the industry since 2019, but they already have enough monopoly lawsuits on their hands.

What survives: Three Privacy Sandbox technologies remain active. CHIPS (Cookies Having Independent Partitioned State) prevents third-party cookies from tracking users across different websites while allowing embedded features to function. FedCM (Federated Credential Management) handles login via third-party accounts without exposing personal data to identity providers. Private State Tokens continue to handle fraud prevention and bot detection.

The net result: The Google Privacy Sandbox initiative is effectively dead. Third-party cookies remain in Chrome. Other web browsers, including Safari and Firefox, had already blocked third-party cookies by default, meaning cross site privacy boundaries and tracking now behaves differently across other browsers, a fragmentation problem the Privacy Sandbox was partly designed to solve.

Looking at the Privacy Sandbox timeline in full, the clearest pattern is not technical failure but ecosystem failure: the APIs worked in isolation, but the industry never reached the adoption threshold needed to replace the infrastructure they were designed to replace. 

What Does the Privacy Sandbox Consist of?

The Privacy Sandbox Google built was not a single product but a collection of at least seven distinct APIs, each designed to handle a different part of what third-party cookies currently do: targeting, measurement, fraud prevention, and audience segmentation. 

Our beast is all about APIs. Privacy Sandbox has seven faithful samurai APIs that determine the way it works. Trust us, almost each of these deserves its own article, but today, let’s make it quick.

1. Topics API

Topics is a literal replacement for third-party cookies. In theory, it’s like switching from cola to water. Instead of tracking the user’s journey across different sites and creating individual profiles, Topics gathers your interests in broader categories.

In practice, instead of “Steven visited toaster-lovers.com on Monday at 12 pm and spent 15 minutes there”, the advertiser gets “Steven is interested in Toasters.” The data about Steven is only stored for 3 weeks.

2. Protected Audience / FLEDGE (First Locally-Executed Decision over Groups Experiment)

In theory, the goal of Protected Audience is “to change how remarketing works.” In practice, it redefines how programmatic auctions happen.

We’ll dwell on the details in the next section, but for now, ad auctions run on the user’s device. Third-party tracking is prevented.

Here’s how it happens:

• The website uses the Protected Audience API to add the user to a remarketing audience stored on their device.
• When the user visits another website, the browser matches them with an ad from the brand (e.g., "20% off the toasters you viewed").
• The entire auction and decision-making process happens locally in the browser, preventing third-party tracking.

3. Attribution Reporting

Attribution Reporting is yet another antidote against third-party cookies. Its main mission is to allow ad businesses to track conversions without being data creeps.

To be more precise, this API lets you measure conversions in the following ways:

• Ad clicks and views;
• Ads in a third-party iframe (ads on a publisher site that uses a third-party ad tech provider);
• Ads in a first-party context (ads on a social network partition key or a search engine results page, or a publisher serving their own ads).

What does it look like? Very similar to Topics. Instead of “Steven bought three toasters at 12 pm on toaster-lovers.com,” the advertiser and publisher get “user, 10 clicks, 3 purchases.”

4. Shared Storage

As we’ve mentioned, the auction in Privacy Sandbox happens between the browser and the advertiser. Basically, it stores the data of this communication to later serve relevant ads.

It does the same thing as third-party cookies, but in a different way. The data is saved in a sandboxed storage area, which is much stricter. Advertisers cannot access or extract data directly; it’s only used for rendering decisions. 

For example, a user interacts with a product configurator on Porsche’s website. The browser stores the custom configuration (e.g., leather seats, twin-turbo engine) in shared storage. This information is later used to display an ad showing their configured car on another site.

5. Private Aggregation

You won’t believe it, but the main point of Private Aggregation is to aggregate data privately. 

How is it different from Attribution Reporting? 

Firstly, Private Aggregation isn’t limited to conversions; its scope is broad, including advertising metrics like reach and impressions. Secondly, it doesn’t focus on specific user actions; Private Aggregation’s main goal is wide campaign analysis.

In short:

• Attribution Reporting – measuring specific ad effectiveness;
• Private Aggregation – overall campaign analysis.

6. Privacy Budget

To be honest, its name doesn’t make much sense. The purpose of the Privacy Budget is to limit the identifiable information that can be collected about the user. Yes, just like most of the other Privacy Sandbox APIs.

But that’s actually the main goal. Privacy Budget limits the queries to ensure non-unique data like screen size and language settings can be accessed, preventing fingerprinting.

7. Private State Tokens

Last but not least are Private State Tokens. It’s the paladin of the Privacy Sandbox ecosystem.

Private State Tokens prevent fraud and bot activity. How does it work? A user logs into a trusted website, which issues a crypto token to their browser. Later, when the user visits an ad-supported site, the token verifies that they are a real person, not a bot.

How Does the Privacy Sandbox Work with a Third-Party DSP?

What is Privacy Sandbox in practical terms for a DSP operator? 

It was a proposal to move parts of the programmatic auction and audience targeting onto the user's device rather than processing them through external servers. For a Google Privacy Sandbox explained from the DSP side: The proposed system would have changed where and how bid decisions were made, shifting parts of the auction from SSP and DSP infrastructure to the user's own browser. 

Let’s keep it clear: There is no working (at least public) version of the Privacy Sandbox. Even Google’s own DV360 works just as it used to in the past. Still, the combination of the APIs above gives us a somewhat clear picture of how it’s going to work.

Step # 1. User Visits a Website

The user clicks on a publisher's website. With Topics API, the browser determines the user’s interests (e.g., "Tech" or "Toasters") based on the user's browsing history. Privacy Budget prevents any other info from being collected.

Step # 2. Ad Request to the SSP

The publisher’s website sends an ad request to its SSP (Supply-Side Platform). Contextual page info and aggregated user interests (via Topics API) are included in the request. No user-identifiable data (like cookies) is shared! (at least, in theory)

Step # 3. SSP Forwards Request to DSPs

The SSP forwards the request to multiple demand-side platforms, including the third-party DSPs bidding for the inventory. Protected Audience API enables remarketing or audience targeting using on-device data (e.g., a shopping cart item stored locally).

Step # 4. DSPs Analyze the Data

DSPs evaluate the bid request using:

• Interest signals (from Topics API);
• Retargeting audiences (from Protected Audience API);
• Contextual page data.

The DSP calculates a bid amount based on relevance and campaign parameters.

Step # 5. Browser Runs the Auction

The browser (via the Protected Audience API) conducts the final auction, combining bids from multiple DSPs locally.

Step # 6. Winning Ad is Served

The highest bidder’s ad creative is displayed to the user on the publisher’s site. Shared Storage API temporarily stores creative elements and some user data. Attribution Reporting API tracks clicks and conversions. Privacy State Tokens ensure that the deal goes securely.

Step # 7. Post-Auction Reporting

Advertisers receive campaign performance reports. Attribution Reporting API measures ad conversions (e.g., purchases). Private Aggregation API provides insights (e.g., "10,000 impressions, 1,000 clicks"). 

How Will DSPs Change?

As you can see, the basics of open programmatic auction are similar to what we have now, but the devil is in the details. The ways of data storage, targeting, and even analytics are completely different and will most likely require our beloved DSPs to change.

Once again, nobody tells us what exactly these changes should be or when they should happen. All we can do is deduce stuff on our own with that little info we have. So, in theory, each DSP provider should:

Integrate all APIs

Obviously, every DSP should integrate all of the APIs above to ensure everything works. This may sound simple, but in reality, it’s very far from it. While Private Aggregation and Shared Storage aren’t that intimidating, Protected Audience fundamentally changes programmatic advertising, and we can only guess how it will fit in.

Collaborate with Publishers

While Google couldn’t pull the plug off third-party cookies, many other providers already did. The value of first-party data is as high as ever, so advertisers will need to work closely with publishers.

Participate in the Privacy Sandbox Testing

We recommend testing the Privacy Sandbox as soon as early alpha builds are made public to gain an edge over competitors.

Comply with Regulations

The Privacy Sandbox is a part of a larger trend toward a more private web. Once it’s rolled out, the eyes of all regulatory organizations will be glued to it. So, follow the regulations.

What’s Wrong with Privacy Sandbox?

As you might have noticed, there is no full version of Privacy Sandbox at the moment. But even with what little info we have, Privacy Sandbox is roasted from multiple sides. 

Just to name a few quotes:

Based on Epom observations from working with DSP clients during the testing period, the Protected Audience API's on-device auction model introduced latency that affected campaign delivery, and the reporting outputs from Attribution Reporting fell short of what advertisers needed to optimize bids effectively.

The Future of the Privacy Sandbox

There is no longer a future to discuss. The Privacy Sandbox is gone.

Google officially discontinued the Privacy Sandbox initiative in April 2025 and completed the API retirement process in October 2025. The project that began with a promise to protect user privacy while preserving digital advertising has ended after six years of delays, regulatory scrutiny, limited adoption across the industry feedback, and mounting evidence that the proposed changes would reduce transparency rather than improve it.

Based on Epom observations, most serious DSP operators never fully pivoted to Privacy Sandbox-dependent workflows. The repeated delays made deep integration difficult to justify, and the APIs that did get tested showed meaningful gaps in advertising performance compared to existing cookie-based targeting methods.

What this means for advertisers and publishers:

Third-party cookies remain in Chrome. Advertisers and publishers can continue using cookie-based targeting and tracking as before. However, this does not solve the underlying problem. Safari and Firefox have already blocked third-party cookies by default. Privacy compliance obligations under GDPR and CCPA remain unchanged, regardless of what Chrome does. Cross-app tracking on iOS remains restricted.

The advertising industry is shifting toward first-party data strategies and contextual advertising as the practical alternatives. Advertisers and publishers need to focus on building their own first-party data infrastructure rather than relying on third-party data brokers or waiting for a platform-level solution.

What this means for DSPs:

The programmatic auction mechanics remain intact. Open RTB, SSP integrations, bid requests, and real-time auctions all continue to function exactly as they did before. The Privacy Sandbox had proposed moving part of the auction process onto the user's device through the Protected Audience API, but that proposal is now retired.

As Epom's programmatic team notes: "The death of the Privacy Sandbox is not a free pass to ignore privacy. GDPR still applies. Users in Safari and Firefox still block cookies by default. The work of building compliant, durable data strategies does not stop because Google changed course."

What comes next:

The broader direction of the web is still toward fewer cross-site data collection methods and stronger individual user data protections, even without the Privacy Sandbox. Contextual targeting, interest-based advertising based on first-party signals, and privacy-preserving measurement tools will continue to develop through web standards bodies and individual browser initiatives.

Google has indicated it will participate in those standards processes rather than driving them unilaterally. The CHIPS, FedCM, and Private State Tokens APIs that survived the retirement continue to develop. Whether a coordinated industry replacement for the broader Privacy Sandbox proposals emerges through the W3C or another collaboration will determine how blocking third-party cookies is eventually handled across all browsers.

For now, the industry is operating in a familiar environment with a clearer picture of what the next few years actually look like.

In any case, we hope the technology will see the light of day. Ad tech needs to change in a better way. 

For example, we are already doing it with our Epom white-label DSP. Custom development and fraud protection ensure you get the solution that fits tomorrow's advertising.

FAQs

• What is the Privacy Sandbox? 

  Privacy Sandbox solutions were a Google initiative launched in 2019 to replace third-party cookies with browser-based APIs that would allow targeted advertising without cross-site user tracking. It included seven main technologies: Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation, Privacy Budget, and Private State Tokens. Google officially retired most of these APIs in October 2025.

• Is the Privacy Sandbox dead?

  Yes. Google officially discontinued the Privacy Sandbox initiative in April 2025 by abandoning the cookie deprecation plan, and completed the process by retiring most of its core APIs on October 17, 2025. Topics, Protected Audience, Attribution Reporting, Private Aggregation, and Shared Storage have all been retired. CHIPS, FedCM, and Private State Tokens continue to operate.

• What does the end of the Privacy Sandbox mean for advertisers?

  Third-party cookies remain in Chrome indefinitely, so existing cookie-based targeting and measurement continue to work. However, Safari and Firefox already block third-party cookies by default, and GDPR compliance obligations are unchanged. Advertisers should continue building first-party data strategies rather than relying entirely on the availability of third-party cookies in Chrome.

• What happened to the Privacy Sandbox timeline?

  The Privacy Sandbox timeline ran from 2019 to 2025. Google delayed cookie deprecation multiple times: initially targeting 2022, then 2024, then 2025. In July 2024, Google announced that cookies would not be deprecated but that users would receive a choice prompt. In April 2025, even that prompt was abandoned. By October 2025, most of the APIs were formally retired. The UK's Competition and Markets Authority responded by releasing Google from its regulatory commitments.

• How does the Privacy Sandbox affect DSPs? 

  The practical effect on DSPs is limited. The programmatic auction mechanics, RTB protocols, SSP integrations, and bid request infrastructure all remain unchanged. The Privacy Sandbox had proposed moving parts of the audience-targeting and auction process onto users' devices via Protected Audience, but that proposal is now retired. DSPs should focus on first-party data integrations and contextual targeting capabilities as the durable path forward.