Google is deprecating Topics, Protected Audience, Attribution Reporting and the related Privacy Sandbox APIs in Chrome 144, with full removal targeted for Chrome 150. Third-party cookies are staying. If you shipped code against any of those APIs — and a lot of measurement and ad-tech teams shipped at least a feature-detection branch — the cleanup is straightforward but easy to get wrong in one specific way: some of these calls fail loudly, and some fail quietly.

How this ended up here

The short version is that adoption never arrived. The APIs were complicated, the replacement signals were weaker than what they replaced, and the schedule slipped repeatedly. By July 2024 Google had already abandoned the plan to deprecate third-party cookies. In April 2025 it dropped the scaled-back version too, keeping existing cookie controls in Chrome settings rather than introducing new prompts. What remained was a set of APIs with no forcing function behind them, and by late 2025 Google began retiring the remaining ones in both Chrome and Android. The competition-authority oversight that shaped much of the design has stepped back accordingly.

For engineering purposes none of that history matters except one implication: this is a removal, not a migration. There is no successor API to port to.

What is actually going away, and what is not

The retirements cover the advertising-specific surface: Topics, Protected Audience (PAAPI), Attribution Reporting, and the tooling built around them.

Several platform primitives are being kept, and they are the ones worth knowing because they are not ad-targeting features and they solve real problems:

  • CHIPS — partitioned cookies, which is how a legitimate embedded third-party context keeps its own state without a cross-site cookie.
  • FedCM — the federated identity flow, relevant if you implement or consume third-party sign-in.
  • Private State Tokens — anti-fraud signal passing without cross-site identifiers.

If your build has these confused with the ad APIs — and in a lot of consent-management and tag-manager codebases they all live in the same “privacy sandbox” module — split them before you start deleting.

The audit, in the order that finds things fastest

1. Grep for the API surface, not the marketing name. The call sites you are looking for are document.browsingTopics(), navigator.joinAdInterestGroup, navigator.runAdAuction, attributionsrc attributes on anchors, images and scripts, and the Attribution-Reporting-Eligible / Attribution-Reporting-Register-Source header pair. Header-based registration is the one teams forget, because it lives in an edge worker or a CDN rule rather than in application code.

2. Find the permissions-policy entries. browsing-topics, join-ad-interest-group, run-ad-auction and attribution-reporting often appear in a Permissions-Policy response header or an iframe allow attribute. These become inert rather than erroring, so they will sit in your config for years if nobody looks.

3. Separate the hard failures from the silent ones. A removed method throws a TypeError when called, which your error monitoring will surface immediately. But a feature-detected branch — if ('browsingTopics' in document) { ... } else { ... } — will simply stop taking the first path, with no error at all. That is the dangerous case, because the fallback branch is usually the one nobody load-tested. Check what the else path does under real traffic before Chrome 150 makes it the only path.

4. Check your measurement reconciliation. If Attribution Reporting output was feeding a conversion model as a secondary signal, its disappearance shows up as a step change in a dashboard, not as an exception. Note the removal date in whatever runbook your analysts use for anomaly triage, or someone will spend a week attributing the drop to a campaign change.

What to do with the measurement gap

The honest answer is that the gap is smaller than the Privacy Sandbox discourse implied, because adoption was low. For most teams the practical replacements were already carrying the load:

  • Server-side event collection with first-party identifiers, which is where most of the reliable signal already lives.
  • Platform-native conversion APIs — the advertising platforms’ own server-to-server endpoints, which are unaffected by any of this.
  • Modelled and incrementality-based measurement, which is what you fall back on when deterministic joins are unavailable regardless of browser policy.

None of those are new, and if you built them during the deprecation scare, the work was not wasted — it just turned out to be the main path rather than the contingency.

The cleanup is also a chance to delete the contingency code

A lot of codebases carry a dual-path implementation written in 2023 and 2024: the cookie path, the Sandbox path, and a flag to switch between them. All three now collapse into one. Removing a runtime branch that has been dead in production is a small, pure win — fewer code paths in the consent flow, fewer permutations in QA, one less thing that behaves differently in Chrome than in Safari or Firefox, neither of which implemented these APIs at all.

Do the grep, split the keepers from the retirees, look hard at every feature-detection fallback, and put the removal dates where the people reading the dashboards will see them. The rest is deletion, which is the best kind of migration.