Protected Audience moves the ad auction into the browser

The revenue mechanism

Protected Audience, the API Google previously called FLEDGE, is the Privacy Sandbox mechanism for remarketing, showing an ad related to a product or site a person already visited, without the third-party cookie that used to let an ad-tech company recognise the same browser across sites. Google's own developer documentation, as retrieved 16 September 2026, describes an 'interest group': a browser-side record, created when a site calls a join function, naming an owner such as an advertiser or its buying platform. Membership in that group is stored on the device and, critically, cannot be read back out by any script; it can only be used later when an ad auction runs.

What the documents show

Google's overview page describes the auction as a six-step sequence: a person visits a publisher's site; a seller, typically an ad exchange, starts an auction; buyers whose interest groups match generate bids using data fetched at auction time; the seller scores the bids; the winning ad renders inside an isolated fenced frame whose destination is hidden from the publisher and seller; and results are reported back afterward. The developer guide adds the mechanical detail that matters for trust in the design: bidding and scoring code runs inside 'isolated JavaScript worklets that can't talk to the outside world', meaning the auction logic cannot itself export the interest-group data it uses to decide a winner. Real-time bid inputs come from what Google calls Key/Value services, which the documentation says run inside trusted execution environments rather than on ordinary ad-tech servers.

The assumptions exposed

The design assumes that running the auction on-device, with isolated code and no read-back of interest-group membership, is sufficient to prevent the cross-site profiling third-party cookies enabled, while still letting a legitimate remarketing auction happen. Google's documentation describes the isolation mechanism in detail but does not publish independent, audited figures on whether this auction produces bid prices or fill rates comparable to the cookie-based remarketing it replaces; that is a commercial outcome for each ad-tech participant to measure, not a claim this specification makes. The 'trusted execution environment' language describing Key/Value services is Google's own architectural description, not a third-party security audit result.

What to check before you rely on it

A publisher whose programmatic partners rely on remarketing demand should ask those partners directly which auction mechanism is generating a given bid, since Protected Audience bids are structurally different from a conventional real-time-bidding request. This is an editorial checklist, not guidance from Google.

• Does my ad exchange or SSP actually run Protected Audience auctions today, or is this still on its roadmap?
• Can I see, in my own reporting, which impressions were won through an on-device auction versus a conventional bid request?
• Am I comparing this mechanism's yield against a documented prior baseline, or an assumed one?

The auction's isolation properties are documented engineering choices; what they are worth to a specific publisher's remarketing revenue is a separate, unmeasured question.