The Publisher's Guide to Google's Privacy Sandbox and the Topics API

On October 17, 2025, Google announced the retirement of the Topics API and the Protected Audience API on Chrome and Android, along with the Attribution Reporting API and other Privacy Sandbox technologies. Google reached that decision after evaluating ecosystem feedback about the expected value of those tools and in light of low levels of adoption. The same October 2025 retirement announcement states that Chrome maintains its current approach to offering users third-party cookie choice.

That pairing defines the problem for anyone monetizing a site above one million monthly pageviews. The intended replacement for third-party cookie signals is headed out of the browser, while the constraints that produced it stay in place: Safari and Firefox have blocked or partitioned third-party cookies for years, and consent rules keep tightening across major markets. Publishers now work with a narrower signal set than third-party cookies delivered, and no browser-provided substitute will arrive to fill the gap. Every engineering hour booked for Topics mapping or on-device interest group auctions went into surfaces that now have no future.

What retired and what stayed

The retirement covers the interest-based advertising core of the Sandbox program: Topics and Protected Audience on Chrome and Android, plus the Attribution Reporting API and additional Sandbox technologies grouped into the same announcement. For planning purposes, treat the program as closed rather than paused. None of it forms part of the plumbing you already run: OpenRTB 2.6 request and response flow, Prebid auction logic, VAST video delivery, and TCF consent strings all operate independently of the retired APIs.

The Android half matters for app inventory. Protected Audience on Android ran on the same interest group model inside the mobile stack, so mediation layers and SDK configurations that enabled it during testing need the same audit as the web side. The announcement groups the Android work into the same retirement, which simplifies planning: one removal project covers both surfaces.

The cookie stance deserves a close read. Chrome maintains its current approach to offering users third-party cookie choice, which splits Chrome traffic user by user into sessions that carry third-party cookies and sessions that do not. Measure that split in your own analytics before you plan around it, because it varies by market, audience, and device mix. Safari and Firefox traffic behaves differently again: those browsers block or partition third-party cookies, so a large share of your audience has lived in the cookieless state for years.

How Topics worked, one epoch at a time

Topics grouped users into inferred interests without letting any caller assemble a cross-site profile. The API operated in epochs, one week by default. During an epoch, a classifier model mapped the hostnames of the sites a user visited to zero or more topics from a fixed taxonomy. At the end of each epoch, the API refreshed the user's top five topics and recorded the callers that observed them. A caller, typically a demand partner's script on a publisher page, received at most three topics: one from each of the three most recent epochs, and only from epochs in which that caller had observed the user. The Topics API reference documentation lays out the epoch mechanics, the classifier model, and the user controls.

Implementations fed those labels into normal programmatic flow. Header bidding setups passed returned topics into OpenRTB user data objects, and demand partners bid against the labels as a coarse interest signal. The design added deliberate noise: 5 percent of the time, the API replaced the true topic with a random pick from the full taxonomy, which stopped callers from stitching repeated observations into a stable identifier. Classification ran at the hostname level rather than the page level, so a generalist news site carried the same handful of labels regardless of section or article.

For a publisher, participating meant adding an API call to the page and passing up to three labels per request into the bid stream. The labels arrived without a durable user identifier, without page-level context, and without enrichment a sales team could pitch. Compare that with first-party data: registration status, newsletter engagement, and content affinities all tie to identifiers you control and package cleanly for direct deals. Topics offered none of that, which limited its appeal on the sell side as much as on the buy side.

The taxonomy capped the signal before privacy did

The v2 taxonomy listed 469 topics. Google manually curated it for the top 50,000 sites and excluded categories that people generally treat as sensitive, such as ethnicity or sexual orientation. Users could remove individual topics or opt out of the API entirely.

Stack the compression layers and the low adoption reads as rational rather than surprising. Four constraints did most of the damage.

1. A grid of 469 labels covered the entire web, a coarse mesh next to the cookie-level segments buyers already priced against.
2. Hostname-level classification gave a generalist site one set of labels whether a visitor read sports, personal finance, or cooking.
3. The classifier mapped hostnames to zero or more topics, so sites below the curation line often carried no label at all, which handed long-tail publishers no signal and no revenue case.
4. The 5 percent random swap diluted the data at the point of sale.

A buyer comparing a Topics label against an existing cookie segment saw less precision, less coverage, and no incremental reach, so there was little reason to prefer the new signal. The privacy design succeeded on its own terms and still failed the market, because the market priced the signal rather than the intent.

Protected Audience moved the auction into the browser

Google designed Protected Audience so third parties cannot track browsing across sites. Advertisers added visitors to interest groups on their own properties, and when those users reached a publisher page, the browser ran an auction on the device among the eligible groups and rendered the winning creative in place. The ad space seller role belonged either to a content publisher acting for itself or to a supply-side platform working with the publisher. Chrome allowed up to 1,000 interest groups per owner and up to 1,000 interest group owners. The Protected Audience API overview documents the seller roles and those interest group limits.

The seller role carried the real cost. A publisher or its supply-side partner had to ship and maintain auction code inside browser worklets, execute buyer bidding logic on the user's device, and debug outcomes that never appeared in server logs. A standard Prebid or OpenRTB flow shows every bid, timeout, and error in logs you control; Protected Audience traded that observability for privacy. Buyers carried their own burden: demand-side code had to run inside worklet constraints, with bidding logic rebuilt for an on-device model before any incremental revenue appeared. Both sides took on that work for a system whose payoff depended on the other side showing up first.

Adoption collapsed before the retirement did

Digiday reported in May 2025 that publishers had already stopped investing in Sandbox after the cookie reversal, citing weak advertiser participation and yield uncertainty. Treat that as reported sentiment from before the announcement, but the sequence behind it is structural. Google spent years promising to deprecate third-party cookies in Chrome, then reversed course and moved to a user-choice model. That reversal removed the only forcing function in the plan: with no deadline, buyers kept cookies where they still worked and put new investment into first-party data deals, and publishers saw no incremental yield from on-device experiments. Interest drained from both sides of the market well before the retirement made it official.

The yield uncertainty had a mechanical cause. On-device auctions and topic-keyed bids produced outcomes that standard reporting could not attribute cleanly, and lift measurement required test cells most publisher teams had no budget to run. Faced with ambiguous upside and certain engineering cost, the reported publisher position was to stop spending on it. That position took shape months before the official announcement.

The planning lesson matters more than the obituary. Monetization technology ships only when both sides of a market have an incentive to build it, and a single vendor's roadmap is not an incentive. Gate publisher engineering against surfaces that have shipped, gathered adoption, and produced measurable yield, and keep everything else on a watch list. Agencies that built 2025 and 2026 client plans around Sandbox milestones should reallocate those hours this quarter.

What to remove from your stack now

The retirement creates housekeeping work with a real payoff. Dead code paths add payload to every page load, complicate QA, pollute reporting, and confuse whoever inherits the codebase next. Walk the stack in this order.

1. Search front-end bundles, tag manager containers, and vendor tags for the browsing topics entry point and the Protected Audience interest group and auction entry points. Remove the calls or park them behind a feature flag you plan to delete.
2. Drop the browsing-topics Permissions-Policy header from origin servers, CDN rules, and edge configurations.
3. Prune Sandbox-era modules out of your Prebid package and header wrapper. An unused module adds weight to the auction path for zero return.
4. Review Ad Manager settings for Sandbox experiments or beta toggles you enabled during testing, and retire line items keyed to Topics or interest group data.
5. Audit server-side connectors and warehouse segments built from Topics or Protected Audience outputs, and delete every segment that no longer feeds a live campaign.
6. If you run apps as well as sites, check Android SDKs and mediation layers for Protected Audience flags shipped during the testing window.
7. Document what you removed and when, so the next audit does not rediscover the same dead paths.

Keep three things while you clear the rest. Keep consent management, because TCF strings and their equivalents remain the entry ticket to European demand regardless of any browser vendor's plans. Keep first-party identifiers collected legitimately, because logged-in audiences form the one signal set no browser vendor can retire. Keep contextual targeting, because a page's own content requires no user profile and works in every browser.

Where yield comes from now

With browser-provided interest signals off the table, yield comes from auction configuration and demand quality, and neither depends on a browser roadmap. First-price auctions with bid shading, reserve prices, and expected-value ranking decide most of what an impression earns, and those levers respond to tuning within days. Our auction mechanics guide covers the settings that move revenue per mille on live traffic.

Buyers adjusted too. Demand-side spend now concentrates on verified audiences and curated supply paths, and buyers want stable structure, honest first-party signals, and an auditable path from deal to impression. Because the announcement retired the Attribution Reporting API as well, buyers will press for conversion visibility from sources you control: order confirmation pixels, server-side conversion feeds, and clean post-click reporting. Publishers who can evidence conversions from their own logged-in base hold a stronger hand in deal negotiations than any browser API ever offered.

First-party capture is where the engineering effort belongs now. Registration flows, newsletter signups, and logged-in sessions produce identifiers and behavioral signals that no browser update retires, and they package cleanly into private marketplace deals. The checklist is short: raise the logged-in share of sessions, attach consented signals to bid requests through your own user data fields, and give sales teams segment counts they can put in a deck. Publishers that treat first-party capture as an engineering project will outearn those still waiting for a browser vendor to ship an audience solution.

We sit on all three sides of the trade: an ad network, an SSP, and an agency inside one company. At OnlyMedia we integrate OpenRTB 2.6 seats and Prebid for header and server-side demand, so the retirement changes nothing about how bids reach your pages. We work with thousands of publishers, each above one million monthly pageviews, through our curated programmatic demand network. We pay publishers Net 30, CPM based: no chasing, no sliding terms. Publishers track every impression in a ten minute reporting console, which means yield changes show up the same day you make them.

None of this dissolves the signal problem; it relocates the work. Chrome maintains its current approach to offering users third-party cookie choice, so cookie availability varies user by user across Chrome traffic, and Safari and Firefox users lost third-party cookies years ago. Plan for that split directly: measure cookie availability in your own analytics, grow the logged-in share of sessions, package first-party and contextual inventory into deals a buyer can audit, and hold every demand partner to shipped technology and fixed payment terms. The retirement ended a project most publishers had already stopped funding. The levers that remain are the old ones, and they still pay.