The Protected Audience API
The Protected Audience API (formerly FLEDGE) is a Privacy Sandbox proposal for remarketing and custom-audience advertising that runs the ad auction inside the browser. Interest-group membership is stored on-device and used in a local auction, so a buyer cannot learn which user belongs to which audience across sites. This page explains the model and its measurement implications.
On-device auctions
A site can ask the browser to add a user to an interest group (for example, people who viewed a product). That membership is stored locally. Later, on a publisher page, the browser runs an auction among buyers using their bidding logic, and the winning ad is rendered in a fenced frame. Buyers never receive a cross-site identifier or learn the user's full audience membership.
Reporting is intentionally limited so the auction cannot be turned back into per-user cross-site tracking.
What changes for analytics
Because audiences and the auction live in the browser, there is no central server view of audience membership or per-user ad exposure to feed into analytics. Frequency capping, audience size, and outcome reporting all rely on constrained Sandbox reporting rather than raw user-level logs. Remarketing analytics becomes aggregate and privacy-bounded.
- Interest-group membership stored on-device
- Auction runs locally; ad shown in a fenced frame
- Reporting constrained to prevent re-identification
How it appears in analytics and logs
With on-device auctions, you no longer see a centralized log of which user saw which remarketing ad; reporting comes through constrained, privacy-preserving channels.
Diagnostic use case
Understand that remarketing audiences live on-device under Protected Audience, so audience and frequency data is not a server-side, per-user list you can export.
What WebmasterID can help detect
WebmasterID is an on-site measurement product and does not run cross-site ad auctions; it measures first-party engagement that Protected Audience does not touch.
Common mistakes
- Expecting an exportable, server-side remarketing audience list.
- Assuming buyers learn a user's cross-site audience membership.
- Treating Protected Audience reporting like raw impression logs.
Privacy and accuracy notes
Protected Audience keeps interest-group membership on the device to prevent cross-site profiling. This page is educational and describes documented mechanics.
Related pages
- Chrome Privacy Sandbox and analytics
The Privacy Sandbox is a set of Chrome web-platform APIs intended to support advertising and measurement use cases without cross-site tracking of individuals. It includes interest-based targeting, conversion measurement, and anti-abuse APIs that return aggregated or noised results rather than per-user identifiers. This page maps the pieces and what they mean for analytics.
- The Topics API for interest signals
The Topics API is a Privacy Sandbox proposal that lets a browser share a handful of coarse interest topics, inferred on-device from recent browsing, with sites and their ad partners — without revealing the underlying browsing history. This page explains the mechanism, its deliberate limits, and why it is not a replacement for per-user analytics.
- The Attribution Reporting API
The Attribution Reporting API (ARA) is a Privacy Sandbox API that connects ad clicks or views to later conversions without third-party cookies or cross-site identifiers. It produces two kinds of output — limited, noised event-level reports and aggregatable summary reports processed through an aggregation service. This page explains both and their trade-offs.
- Privacy-first analytics
On-site measurement outside cross-site ad auctions.
Sources and verification notes
- Chrome for Developers — Protected Audience APIOfficial Protected Audience documentation.
- WICG — Protected Audience API explainerSpecification draft (formerly FLEDGE/TURTLEDOVE).
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.