For two decades the programmatic auction lived on a server: a publisher’s ad server received a request, ran an auction (or passed it to SSPs and DSPs), and returned a winner. The Protected Audience API breaks that assumption. Part of the auction now runs inside the browser, on the user’s device, so that interest-based ads can be served without any party seeing a cross-site profile. Integrating it is a real architectural shift — here is how the pieces fit together.
01 — LIFECYCLEBrowser-side auctions, in two phases
Protected Audience splits the work across time. While the user browses an advertiser’s site, a buyer asks the browser to remember them with joinAdInterestGroup() — storing an interest group locally, along with the bidding logic and candidate ads. Later, on a publisher’s page, the seller calls runAdAuction(); the browser runs the auction on-device across the stored interest groups, and the winner renders in a fenced frame. No cross-site identity ever leaves the device.
02 — INTEREST GROUPSWhat the browser stores
An interest group is owned by a buyer origin and carries a name, a bidding-logic URL, a set of candidate ads, optional user bidding signals, and a lifetime. The browser holds these groups; k-anonymity gates which ads are even allowed to win, so an ad can’t be used to single out one person. The ad server’s job at this stage is to make joining easy — firing the right tags on advertiser pages — and to be ready to convene the auction later.
03 — ON-DEVICE BIDDINGBidding and scoring in worklets
When the auction runs, each interest group’s generateBid() executes in an isolated worklet, and the seller’s scoreAd() worklet scores the bids. Trusted bidding and scoring signals are fetched from key-value servers. These worklets run under tight constraints — limited time and compute, no arbitrary network access, and no direct logging; measurement comes back later through aggregated reporting. The ad server, acting as the seller, supplies the auction configuration: the decision-logic URL, trusted-scoring-signals endpoint, auctionSignals and perBuyerSignals.
The auction no longer just happens on a server. Half of it now runs in the user’s browser.
04 — OPENRTBHow it maps onto the bid request
The contextual half of the auction still flows through OpenRTB exactly as before — the request goes server-side to SSPs and DSPs. What changes is signalling: the request now indicates that the impression is eligible for an on-device auction, and the contextual response can carry the configuration and per-buyer signals needed to seed it. The annotated request below shows the shape of those changes (field names follow IAB Tech Lab Protected Audience guidance).