Local Remarketing Auctions with the Protected Audience API

This article explains how the Protected Audience API executes remarketing ad auctions directly inside the Chromium web browser. By shifting the auction mechanics from external servers to the user's local device, the API enables advertisers to re-engage website visitors without relying on cross-site tracking or third-party cookies. We will cover the complete lifecycle of a local auction, including interest group assignment, real-time data fetching, isolated JavaScript execution for bidding and scoring, and private ad rendering.

1. Storing Interest Groups Locally

The remarketing process begins when a user visits an advertiser's website. Instead of dropping a third-party cookie, the site—or its Demand-Side Platform (DSP)—instructs the Chromium browser to add the user to an "interest group" by calling the navigator.joinAdInterestGroup() JavaScript function.

The browser stores this interest group in a local, on-device database. The stored data includes:

  • The owner of the interest group (the buyer/DSP).
  • A list of potential ads creative URLs.
  • The URL for the bidding logic script.
  • The URL for a trusted server to fetch real-time data later.

This information remains strictly inside the browser and cannot be accessed by other websites. Users are automatically removed from the interest group after a maximum of 30 days unless it is renewed.

2. Initiating the Ad Auction

When the user later visits a publisher's website that sells ad space, the publisher's Supply-Side Platform (SSP) triggers the local auction by calling navigator.runAdAuction().

The SSP passes an auction configuration object into this function. This configuration tells the browser which buyers (DSPs) are allowed to participate, provides contextual signals (such as page topic or ad slot size), and supplies the URL for the seller's scoring script.

3. Fetching Real-Time Signals

Before calculating bids, the browser needs current information, such as whether an ad campaign still has a budget. Chromium handles this by making secure requests to "Trusted Key/Value" servers defined by the buyers and the seller.

These servers cannot log user-level data or correlate requests with individual profiles. They simply take a key (like an interest group name) and return a static value (like a remaining budget status or a system-wide bid multiplier) back to the browser.

4. Executing Bidding Logic in Isolated Worklets

Once the browser has the stored interest groups and real-time signals, it calculates the bids. To prevent data leakage, Chromium does not run this code in the main webpage environment. Instead, it spins up dedicated, sandboxed V8 JavaScript "worklets."

These worklets have no access to the network, the page's DOM, or local storage. They can only process the specific inputs handed to them by the browser.

For each matching interest group stored on the device, the browser executes the buyer's generateBid() function inside a bidding worklet. The function analyzes the interest group data, the contextual signals, and the real-time server signals to output three things: a numerical bid, the specific ad creative URL to display, and relevant metadata.

5. Scoring the Bids

As the bidding worklets finish, Chromium passes the generated bids into a separate, isolated worklet controlled by the seller. Here, the browser runs the seller's scoreAd() function for each submitted bid.

The scoreAd() function evaluates the financial bid alongside the seller's own rules and real-time signals (for example, checking if an ad creative meets the publisher's quality standards). The function returns a "desirability" score. A score of zero or less disqualifies the bid. The ad with the highest desirability score wins the auction.

6. Rendering the Winning Ad in a Fenced Frame

To maintain privacy, the publisher's webpage cannot be allowed to see which ad won the auction, as that would reveal the user's browsing history.

Instead of returning a raw URL, navigator.runAdAuction() returns an opaque object to the publisher's page. The page passes this object into a <fencedframe> HTML element. A Fenced Frame is a secure browsing context in Chromium that is visually embedded in the page but completely isolated from it. The surrounding publisher page cannot inspect the frame's URL, its contents, or communicate with it via JavaScript. The browser privately resolves the opaque object inside the Fenced Frame and renders the winning remarketing ad.

7. Post-Auction Reporting

After the ad is rendered, the buyer and seller need to know the outcome for billing and analytics. Chromium re-opens the isolated worklets to run the seller's reportResult() and the winning buyer's reportWin() functions.

These functions trigger the browser to send network pings (sendReportTo()) back to the DSP and SSP servers, confirming the transaction price and that the ad was successfully displayed. To protect user privacy over the long term, these event-level reports are temporary and are being transitioned to use the Private Aggregation API, which bundles auction results into noisy, encrypted summary reports.