Chrome 144 Starts Retiring Topics and Protected Audience. Now What?

For five years, publishers planned around a day when Chrome would remove third-party cookies and replace them with Privacy Sandbox APIs. That day is not coming. In October, Google announced it would retire most of the Sandbox, including Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation and Related Website Sets, citing ecosystem feedback and low adoption. Chrome 144, which reached the stable channel on January 13, is the version where deprecation begins. According to the Chromium intent to deprecate and remove Protected Audience, removal is planned for Chrome 150.

It is tempting to read this as "cookies won, back to normal." That would be a mistake. Here is what actually changed, what did not, and what to clean up.

What is going away, and what stays

• Retiring: Topics, Protected Audience (the on-device auction API formerly called FLEDGE), Attribution Reporting, Private Aggregation, Shared Storage, Related Website Sets, IP Protection and the related Android APIs.
• Staying: CHIPS (partitioned cookies) and FedCM, both of which saw broad adoption and support from other browsers, plus Private State Tokens. Google also said it would work on an interoperable attribution standard through the W3C.
• Third-party cookies in Chrome: Google had already said in 2025 that Chrome would keep its current approach to offering users a choice about third-party cookies rather than deprecating them or adding a new standalone prompt.

What did not change

Chrome keeping third-party cookies does not restore the cookie-based web of 2019.

• Safari and Firefox still block third-party cookies by default. For many publishers, especially those with large iPhone audiences, a big share of traffic is already cookieless.
• Privacy law keeps tightening. Consent requirements in Europe and opt-out rights in a growing number of US states apply regardless of what the browser allows.
• Cookie match rates were never perfect. Every sync between partners loses users, and cookies expire and get cleared.

So the realistic position for 2026 is a mixed environment: cookies available on a portion of Chrome traffic, absent on Safari and Firefox, and constrained by consent everywhere.

Cleanup: remove what you no longer need

Prebid modules

Many publishers enabled Privacy Sandbox related features in their wrappers during testing, such as Topics collection or Protected Audience support. Once the APIs are deprecated, those modules add code weight and complexity for no return. Audit your Prebid build, remove modules tied to retired APIs, and rebuild. Smaller wrappers load faster, which directly affects auction participation on slower devices.

Ad server and SSP settings

Check for any Sandbox-related settings you turned on in your ad server or with SSPs, including interest group or component auction configurations. Turn off what no longer applies so you are not debugging dead paths later.

Response headers and permissions policies

If your engineering team added headers or permissions policy entries for Sandbox APIs, document them and remove them once the APIs are gone. Leftover configuration is how mystery issues appear two years later.

Vendor claims

Some vendors built products around Topics or Protected Audience. Ask what their plan is. If a partner's value depended on a retired API, you need to know now rather than at renewal.

Build an identity plan that works across browsers

The good news is that the work many publishers did to prepare for cookie deprecation is still useful, because it is the work that monetizes Safari and Firefox today.

1. Measure addressability by browser

Segment revenue per session by browser and consent state. The gap between addressable Chrome traffic and non-addressable traffic is the size of your identity opportunity.

2. First-party identifiers

Logged-in users and newsletter subscribers give you a consented, first-party relationship. Where users have agreed, hashed-email-based identity solutions can be passed through Prebid's user ID modules to partners that support them. Choose a small number of ID providers your demand actually bids on, rather than enabling every module available.

3. Publisher-provided signals

Your own audience segments and contextual data can be passed in bid requests using standard taxonomies. These do not depend on any browser API and work the same on every browser.

4. Contextual first for cookieless traffic

For traffic without identifiers, make sure bid requests carry strong page-level context: content category, keywords where appropriate, and accurate page URLs. Buyers who can target context will bid on inventory they cannot identify.

5. Keep consent signals clean

None of this works if privacy signals are wrong. Test that consent and opt-out states reach bidders correctly, including Global Privacy Control where required.

Timing

Deprecation is not removal. Between Chrome 144 and the planned removal release, the APIs may still respond in some form, which is exactly why leftover code is dangerous: it can appear to work in testing and then fail silently once removal ships. Put the cleanup on this quarter's roadmap, assign an owner, and track it against the Chrome release calendar rather than waiting for errors to show up in your logs.

A note on testing

If you ran Topics or Protected Audience tests, keep the results. They are a record of what signal-based targeting did and did not deliver on your inventory, and that is useful context when a vendor pitches the next alternative. Just do not keep the code running.

The bottom line

The Privacy Sandbox wind-down removes a planning uncertainty, but it does not remove the need for an identity strategy. Chrome cookies are one input among several, not a foundation. Publishers who clean up retired integrations, measure addressability by browser and invest in first-party and contextual signals will do well regardless of what browsers decide next. And if you ran Sandbox experiments through a partner, now is a good time to ask them what they are removing from your stack, and when.