What the Privacy Sandbox Actually Replaces

Third-party cookies carried four distinct advertising functions: interest-based targeting, retargeting, conversion measurement, and frequency capping. The Privacy Sandbox splits these into separate APIs, each with its own consent profile.

Topics API — Interest-Based Targeting

The Topics API assigns each browser a small set of coarse-grained interest topics — around five topics per week, drawn from a curated taxonomy of a few hundred categories. When a publisher calls document.browsingTopics(), the browser returns up to three topics that the ad tech ecosystem can use for contextual personalization without any cross-site identifier. Topics are computed locally, stored on device, rotate weekly, and are subject to user controls in chrome://settings/adPrivacy.

Protected Audience API — Retargeting and Remarketing

Protected Audience, formerly FLEDGE, keeps retargeting alive without a shared cross-site identifier. Advertisers join a user to an interest group on their own site; when the user visits a participating publisher, an on-device auction runs in a Fenced Frame and selects a creative. The winning ad is rendered without the publisher learning which interest group matched.

Attribution Reporting API — Conversion Measurement

Attribution Reporting replaces conversion pixels for a subset of measurement use cases. It supports event-level reports (noisy, lossy, per-conversion) and aggregate summary reports (statistically debiased rollups). Unlike the legacy pixel, it does not expose the individual user-to-conversion link.

Shared Storage and Fenced Frames

Shared Storage is a write-anywhere, read-in-sandbox key-value store for cross-site use cases like frequency capping and A/B experiment consistency. Fenced Frames are isolated iframes that prevent the surrounding page from reading the rendered ad or its interaction data.

Does Privacy Sandbox Require Consent?

This is the single most misunderstood question in the 2026 ad tech landscape, and the answer is jurisdiction-specific.

Under GDPR and ePrivacy

The European Data Protection Board has not issued a blanket position, but national authorities have been more explicit. The UK ICO, the Italian Garante, and France's CNIL have all taken the view that Topics and Protected Audience require prior opt-in consent where they process personal data, including any processing that writes or reads state on the user's device. The logic: the browser still stores interest topics and interest groups locally, and the document.browsingTopics() call transmits inferred personal data to a third party. That is regulated under Article 5(3) of the ePrivacy Directive, which requires consent for any access to or storage on the user's terminal equipment beyond what is strictly necessary for the requested service.

Google's position is more permissive — they argue the APIs are privacy-preserving by design and that consent requirements may not apply in all contexts. This is not a regulator position. Treating Privacy Sandbox as consent-exempt in Europe is a high-risk posture.

Under CCPA, CPRA, and US State Laws

In the United States, Privacy Sandbox flows are generally treated as sharing of personal information for cross-context behavioral advertising under CPRA. That means they trigger the opt-out right and must be honored through Global Privacy Control signals and other universal opt-out mechanisms. The fact that Topics data is derived from the browser rather than sold from a third-party broker does not exempt it.

Chrome's Own Controls

Chrome provides user-facing toggles in chrome://settings/adPrivacy for Topics, Protected Audience, and Attribution Reporting. These user choices sit alongside — not in place of — your CMP's consent state. A user who has said no to advertising cookies in your banner but yes to Topics in Chrome's global settings has still told you no through the banner. Your stack must respect the stricter of the two signals.

The Consent Layer You Actually Need

A production-grade 2026 consent stack treats Privacy Sandbox APIs as distinct processing activities, each gated through IAB TCF purposes or equivalent state-law categories.

Mapping Sandbox APIs to TCF Purposes

• Topics API — IAB TCF Purpose 2 (Select basic ads) and Purpose 3 (Create a personalised ads profile) at minimum; Purpose 4 (Select personalised ads) if the topics feed targeting.
• Protected Audience — Purpose 3 and 4, plus Purpose 7 (Measure ad performance) if the auction uses outcome data.
• Attribution Reporting — Purpose 7 (Measure ad performance) and Purpose 9 (Understand audiences through statistics).
• Shared Storage for frequency capping — Purpose 3 where it feeds personalization, or a legitimate-interest basis where it is purely frequency control.

Mapping to Google Consent Mode v2

Google's Consent Mode v2 signals map to Privacy Sandbox behavior:

• ad_storage denied — disable Topics and Protected Audience API calls entirely
• ad_user_data denied — block Attribution Reporting from sending user-scoped data
• ad_personalization denied — skip Topics inputs into targeting logic

US State Signal Handling

For US traffic, your consent layer should inspect Global Privacy Control and applicable state opt-out signals. When a US user has opted out of sharing, suppress document.browsingTopics(), do not call joinAdInterestGroup, and strip Attribution Reporting registration headers.

Practical Implementation Patterns

Publishers who have already rolled out Privacy Sandbox generally follow one of two architectural patterns.

Pattern 1: Server-Side Orchestration

A first-party tag manager on your origin collects the consent state, user jurisdiction, and any signal overrides, then conditionally renders the Privacy Sandbox hooks into the page. The ad server and SSP receive consent flags through the bid request, and they decide whether to call Topics, Protected Audience, or neither. This pattern centralizes the logic and keeps the consent state authoritative.

Pattern 2: Header Bidding Wrapper Integration

Prebid.js and other header bidding wrappers now support Privacy Sandbox modules. The wrapper reads the consent signal, configures the Topics call behavior, and forwards the auction result through Protected Audience when permitted. This approach is lighter to deploy but pushes more logic into the client and tightens your dependency on wrapper release cadence.

What to Audit

• Confirm document.browsingTopics() is not called unless the CMP's advertising consent is affirmative and no opt-out signal is present
• Confirm joinAdInterestGroup and runAdAuction are gated by the same conditions
• Confirm Attribution Reporting registration headers are only sent on responses for users whose consent state allows measurement
• Confirm your vendor list in the TCF string still matches the SSPs and DSPs using Sandbox APIs on your inventory
• Confirm your privacy policy describes Topics, Protected Audience, and Attribution Reporting as distinct processing activities, with lawful basis and retention

What Privacy Sandbox Does Not Do

Several common misconceptions need to die before you budget against them.

It Is Not a Consent Workaround

The APIs reduce the personal data surfaced to advertisers, but they do not make the underlying processing consent-exempt under European law. The compliance theory that Sandbox adoption lets you skip a CMP is incorrect in every EU/EEA jurisdiction.

It Is Not a Full Replacement for Cookies Today

Topics delivers coarse, lossy targeting signal that is typically weaker than cookie-based audiences. Protected Audience retargeting scales are still maturing. Attribution Reporting has measurement noise floors that can hide small conversion lifts. A publisher moving all monetization to Sandbox today should expect RPM declines of 10-30 percent relative to a cookie-based stack on typical inventory.

It Is Not Permanent in Its Current Shape

The Privacy Sandbox specification is still evolving. The Topics taxonomy is expanding, Protected Audience interest-group limits are under revision, and the regulatory response is ongoing. Design your consent layer to be configuration-driven, not hardcoded to the current spec.

The Right Posture for 2026

Privacy Sandbox is best understood as one layer of a broader cookieless strategy, alongside first-party data, seller-defined audiences, contextual targeting, and server-side header bidding. The publishers who win in 2026 will be those who treat consent as the arbiter, not the obstacle — feeding Sandbox APIs only where law and user choice permit, falling back cleanly to contextual everywhere else, and measuring outcomes across both paths with tooling that does not assume identity.

The worst posture is the wait-and-see one. Regulators are already writing the next wave of rules — the UK Competition and Markets Authority's Sandbox commitments, ongoing CNIL guidance, and the EU AI Act's profiling provisions all touch this ground. The publishers who build Privacy Sandbox into a properly gated consent stack in 2026 will be ready for those rules. The ones who bolt it on as a last-minute cookie replacement will find themselves rewriting under pressure.