Privacy Sandbox for publishers, now that Google has retired it

Privacy Sandbox was Google's plan to replace third-party cookies with new Chrome and Android APIs for ad targeting and measurement. That makes Privacy Sandbox for publishers mostly a clean-up job now. In October 2025 Google retired the ad APIs, including Topics, Protected Audience and Attribution Reporting, and Chrome kept third-party cookies under user control.

That leaves a lot of publishers with a strange problem. You spent years being told to prepare for Privacy Sandbox. Some of you switched on Protected Audience in Prebid, added Topics modules or signed up for SSP tests. Now that code is either dead weight or gone, and most guides you'll find still describe the old plan.

This guide covers what Privacy Sandbox for publishers looks like today: what it was, what Google retired, what Chrome still supports, and what to remove or keep in your ad stack. If you run header bidding, our header bidding service can do the clean-up for you.

What is Privacy Sandbox?

Privacy Sandbox is a set of browser technologies Google built to support ads without tracking people across sites. The idea was simple. Chrome would stop third-party cookies, and new APIs inside the browser would do the jobs cookies did for advertising.

Three APIs mattered most to publishers:

• Topics API. Chrome guessed a handful of interest topics from a person's recent browsing and shared them with ad tech on your page, instead of a cookie ID.
• Protected Audience API (first called FLEDGE). Remarketing auctions ran inside the browser, so a buyer could target past visitors without seeing who they were.
• Attribution Reporting API. Advertisers measured conversions from ads with noisy, delayed reports instead of cross-site cookies.

Around them sat supporting pieces such as Shared Storage, Fenced Frames and Private Aggregation, plus privacy features that had nothing to do with ads, like partitioned cookies and a sign-in API. Google also ran a matching Privacy Sandbox on Android for apps.

Here's the key point for you as a seller. Privacy Sandbox was never a product you bought. It was a set of browser features your ad tech partners had to support, so its effect on your revenue always depended on whether your SSPs and buyers used it.

Is Privacy Sandbox dead?

Yes, the advertising side of Privacy Sandbox is dead. On 17 October 2025, Google's VP for Privacy Sandbox posted an update on plans for Privacy Sandbox technologies saying, in Google's words, "we've decided to retire the following Privacy Sandbox technologies."

The list covers every ad API a publisher would have touched: Topics, Protected Audience and Attribution Reporting on Chrome and Android, plus Private Aggregation, Shared Storage, Related Website Sets, IP Protection and the Android SDK Runtime. Google didn't give removal dates. It said it would follow Chrome's and Android's normal processes for phasing them out.

Two things led there:

1. Chrome kept third-party cookies. In April 2025, Google's next steps for Privacy Sandbox post said Chrome would keep its current approach to cookie choice and "will not be rolling out a new standalone prompt for third-party cookies." Without a cookie phase-out, the replacement APIs lost their reason to exist.
2. Only some parts caught on. Google's October post says CHIPS and FedCM "have seen broad adoption", which is why they stay. It says nothing like that about the ad APIs.

The UK's Competition and Markets Authority had overseen the project for years. The same day, AdExchanger reported that the CMA released Google from its Sandbox commitments, because its competition concerns no longer arose.

Privacy Sandbox status: what's retired and what stays

Google keeps a Privacy Sandbox feature status page, last updated in August 2026, that labels every technology. The Privacy Sandbox APIs for ads are marked "Deprecate and remove". A smaller group of privacy features is marked "Continue to support". This table maps each one to what it means for a publisher.

On Android, the status page marks Topics, Protected Audience, Attribution Reporting, On-Device Personalization, Protected App Signals and the SDK Runtime as deprecate and remove. So if you monetize an app, there's no Android Privacy Sandbox to plan for either. Our app monetization team works from the identifiers and consent tools that still exist.

Privacy Sandbox for publishers and ad revenue today

For most publishers, the end of Privacy Sandbox changes very little about revenue. Third-party cookies in Chrome never went away, so your Chrome demand never had to move to the new APIs. If you never enabled Topics or Protected Audience, nothing changes. If you did, compare revenue before and after your partners turned them off. That tells you what they were worth on your traffic.

What you earn still comes from the same things: consent rates, how many buyers compete, and how well buyers can value each impression.

The bigger story is the one that never changed. Safari and Firefox already block or partition third-party cookies by default, so part of your traffic has run without them for years. Chrome visitors can still turn cookies off in settings. Our plan for cookieless traffic shows how to measure that split on your own site. Without those cookies, buyers can't match your visitors through cookie syncing between ad partners either.

So here's our view. Privacy Sandbox was a plan B for a cookie phase-out that didn't happen in Chrome. The real plan B, for the visitors buyers can't recognise today, is the same as it was before:

• Get valid consent where the law needs it, through a certified consent tool.
• Send buyers a first-party ID they can use, such as a publisher provided ID (PPID) in Ad Manager or a Prebid user ID module.
• Send good page context for contextual targeting, so buyers can price an impression without knowing who the visitor is.

None of that depends on a browser API that might be retired.

How to clean Privacy Sandbox out of your ad stack

Remove the Privacy Sandbox code you added and keep the rest of your setup as it is. Dead configuration adds page weight, extra requests and confusing errors in your console. This is the order we check things when we review a publisher's header bidding setup.

1. Check your Prebid.js version and modules

Prebid dropped Protected Audience completely. Its PAAPI module page says the module "was removed in Prebid.js 11.0. Prebid.js no longer supports the Protected Audience API." The Prebid 11 release notes list paapi, paapiForGpt and topLevelPaapi as removed modules.

If you're on Prebid 9 or 10 with any of those modules in your build, they don't add demand any more. Upgrade, or at least rebuild without them. Our Prebid.js setup guide walks through building a custom package with only the modules you need.

2. Remove the Topics module and its config

The Topics first-party data module page says "Chrome has removed the Topics API" and that since Prebid.js 11.26 the module is a no-op that only logs a warning. The userSync.topics setting is ignored too. Take both out so your console stays clean.

3. Search your page code for leftovers

Look through your ad code and tag manager for these strings and delete the ones that belong to old tests:

paapi
fledge
runAdAuction
joinAdInterestGroup
browsingTopics
topicsFpdModule

Some of these come from vendor scripts, not your own code. If an SSP or ad network script still calls them, ask the vendor when they'll ship an update. Don't edit their script yourself.

4. Check with your SSPs and ad server

If your SSP, wrapper or ad server offered a Protected Audience or Privacy Sandbox switch, ask whether it still does anything. Most vendors are removing these quietly, so you'll get a faster answer by asking than by waiting for a release note.

5. Keep consent, IDs and context working

Once the dead code is gone, check the parts that still earn money. Your consent tool should pass a valid signal to Prebid and Google tags. Your ID modules should fire after consent. Your page context should reach buyers. Our guide to contextual advertising for publishers shows the signals to send.

The privacy features Chrome still supports

Not all of Privacy Sandbox is gone. Google said it would keep supporting CHIPS and FedCM because they saw broad adoption, and it would maintain Private State Tokens. These aren't ad targeting tools, but each one touches a publisher's site in some way.

CHIPS (partitioned cookies)

Google's CHIPS page describes it as a way to "opt a cookie into partitioned storage" with a separate cookie jar for each top-level site. Embedded tools on your pages, such as chat widgets, video players or comment boxes, can use it to keep working when a visitor blocks third-party cookies. If an embed breaks for Safari users, ask the vendor whether its cookies are partitioned.

FedCM (sign-in)

FedCM, short for Federated Credential Management, is in Google's words a "privacy-centric and user-friendly approach to federated identity services" that doesn't rely on third-party cookies. Chrome's FedCM overview covers the details. It matters if you offer "Sign in with Google" style logins, and logged-in readers are one of the best sources of first-party IDs.

Private State Tokens (fraud)

Google's Private State Tokens page says they let trust in a user's authenticity pass from one context to another, to help sites fight fraud and tell bots from people without passive tracking. You won't set these up yourself. It's worth knowing about because invalid traffic costs publishers real money. If you use a fraud vendor, ask whether it uses them.

Common mistakes we see after the retirement

Most of the problems we see now aren't caused by Privacy Sandbox itself. They come from plans and code built around it. These are the ones that come up most:

• Waiting for Privacy Sandbox to fix Safari revenue. It was never coming to Safari or Firefox. Those visitors need consent, first-party IDs and context today, which is what a first-party data strategy gives them.
• Keeping old PAAPI config "just in case". It doesn't bring bids, and on older Prebid builds it adds code and requests to every page.
• Assuming cookies are safe forever. Chrome kept cookie choice, and people can still block them. A setup that only works with cookies is a setup that loses value on part of your traffic.
• Trusting out-of-date guides. Several pages that rank for this topic were written or updated in 2026 and still call these APIs live. Check the date of any advice against Google's status page.

If you'd like us to check your stack for these, our reporting and yield service starts with exactly this kind of audit.

Privacy Sandbox FAQ

These are the questions publishers ask us most about Privacy Sandbox, answered in a line or two each.

Is Google Privacy Sandbox still happening?

Not for advertising. Google retired the Privacy Sandbox ad APIs, including Topics, Protected Audience and Attribution Reporting, on 17 October 2025. Chrome keeps supporting a few privacy features from the project, such as CHIPS, FedCM and Private State Tokens.

Is Chrome still getting rid of third-party cookies?

No. In April 2025 Google said Chrome would keep its current approach, where people choose in Chrome's settings, and wouldn't roll out a new standalone cookie prompt. Safari and Firefox still block or partition third-party cookies by default.

What happened to the Topics API?

Google retired it, and its status page marks Topics as deprecate and remove on Chrome and Android. Prebid's Topics module has been a no-op since Prebid.js 11.26, so it does nothing but log a warning.

What happened to the Protected Audience API?

Google retired Protected Audience (formerly FLEDGE) in the same October 2025 update. Prebid removed its PAAPI modules in Prebid.js 11.0, so header bidding no longer runs Protected Audience auctions.

Do I need to change anything in AdSense?

No. AdSense manages its own tags, so there's nothing for you to remove. Keep your consent tool set up correctly, because consent still decides whether visitors see personalized ads.

What should publishers use instead of Privacy Sandbox?

Use what works in every browser: a certified consent tool, first-party IDs such as a PPID or Prebid user ID modules, and strong page context. A publisher DMP can help bigger sites turn first-party data into audience segments buyers will pay for.

Your next step

Privacy Sandbox for publishers now comes down to clean-up. Remove the dead Topics and Protected Audience code, keep the privacy features Chrome still supports, and put your effort into consent, first-party IDs and context.

If you'd like a second pair of eyes on your header bidding setup, send us your site and we'll tell you what's dead weight and what's worth fixing first.