Google Privacy Sandbox
Why Privacy Sandbox exists
For two decades, digital advertising ran on a simple mechanic: a third-party cookie dropped by an ad-tech vendor on one site could be read by that same vendor on a different site, letting it recognize the same browser across the web and build a behavioral profile for targeting. Regulators and browser vendors moved against this model — Safari's ITP and Firefox's ETP blocked third-party cookies outright years ago, and Chrome, which carries the majority of global browser share, committed to following. Google's answer to "how does advertising keep working without cross-site cookies" is Privacy Sandbox: a set of browser-native APIs that aim to support targeting, measurement, and fraud prevention using data that stays on-device or is aggregated, rather than a shared identifier the advertiser can read directly.
The core idea: compute moves to the browser
The architectural shift is the important part, more than any single API name. In the cookie model, the ad-tech server holds the user's cross-site history and runs the targeting logic itself. In the Privacy Sandbox model, the browser holds the signals — pages visited, ad auctions the user's browser participated in — and runs the targeting or auction logic locally, on-device. The server only ever receives an output (which ad won, which topic a user might be interested in) and never the raw cross-site browsing history that produced it. This is the same pattern behind on-device machine learning generally: push the computation to where the sensitive data already lives instead of exporting the data to compute on it elsewhere.
Topics API: coarse-grained interest signals
The Topics API replaces fine-grained behavioral profiles with broad interest categories. The browser observes which sites a user visits, maps each site to one or a few topics from a fixed public taxonomy ("Fitness", "Travel & Transportation", "Fast Food"), and keeps a rolling record of the user's top topics from the last few weeks entirely on-device. When a participating site calls the API, the browser returns a small, randomized sample of the user's recent topics — not a full profile, not a persistent ID, and with noise injected specifically to prevent using the response as a fingerprinting signal. It's a deliberately blunt instrument: contextual-grade targeting granularity, delivered without a cross-site identifier.
Protected Audience API: remarketing without a shared ID
The Protected Audience API (formerly FLEDGE) targets the remarketing use case — "show this user an ad for the product they looked at on another site" — without letting any server actually know who the user is across both sites. The flow: a site adds the user's browser to an interest group (on-device, stored locally, e.g. "visited sneaker-brand.com and viewed running shoes"). Later, on a publisher page, an on-device auction runs: bidding logic supplied by advertisers and the ad network executes inside the browser itself, scoring candidate ads against the browser's locally stored interest groups. The winning ad is rendered, and reporting on the outcome is restricted to aggregated, delayed reports — no party outside the browser ever sees the user's interest-group membership directly.
1. User browses sneaker-brand.com, views running shoes
-> site calls joinAdInterestGroup() -> stored ON-DEVICE only
2. User later visits a news site (the "publisher")
-> publisher's ad slot triggers an on-device auction
-> advertiser + ad-network bidding logic runs INSIDE the browser
-> browser scores bids against its own local interest groups
3. Winning ad is rendered in the slot
-> result reporting is aggregated + time-delayed
-> no server outside the browser ever reads raw interest-group dataThe trade is granularity for privacy, not a free upgrade
Third-party cookies vs. Privacy Sandbox APIs
| Dimension | Third-party cookies | Topics / Protected Audience API |
|---|---|---|
| Where the identifier lives | Shared across sites, readable by any party with the cookie | Stays on-device; never exported as a raw cross-site ID |
| Who computes targeting logic | Ad-tech server | The browser itself, on-device |
| Targeting granularity | Fine-grained behavioral profile | Coarse topic buckets / locally scored interest groups |
| Measurement | Direct, deterministic cross-site joins | Aggregated, noised, often delayed reporting |
| Persistence | Until deleted/expired, often months | Rolling, short windows (weeks) with automatic decay |
Where this actually stands
Chrome's rollout path for third-party cookie deprecation has shifted more than once — Google has repeatedly delayed full removal while continuing to ship and iterate on Privacy Sandbox APIs, and in 2024–2025 signaled it would give users and the industry more time and optionality rather than a hard cutover date. Practically, that means third-party cookies haven't fully disappeared from Chrome on the timeline originally announced, but the direction is unambiguous: Safari and Firefox already block them by default, regulatory pressure (UK CMA oversight of the Sandbox rollout itself) continues, and every major ad platform is investing in cookie-independent signals regardless of Chrome's exact timeline. Treat Privacy Sandbox as the long-run target architecture, not a feature you can indefinitely postpone evaluating.
Don't confuse this with first-party data strategy
What's next
Privacy Sandbox changes how anonymous cross-site targeting works at the browser level, but it doesn't touch how you stitch your own known and anonymous users into one profile — that's a separate, first-party problem.
Next: Identity Resolution Deep Dive →
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.