Publishers typically diversify their ad demand sources to optimize for revenue and invoke multiple companies (for example, supply-side platforms and demand-side platforms) to determine the best ad for a given ad slot on the page. Protected Audience can be used to run an auction with cross-site data with multiple sellers each running their own auction.
Before you begin, learn about running a Protected Audience auction with a single seller.
Definitions
The following tables describe some terms used in this document.
Auctions
| Auction | Definition |
|---|---|
| Protected Audience auction | An ad auction that involves bidding on an interest group created on another site. |
| Protected Audience multi-seller auction | A two-tier Protected Audience auction that first involves multiple parallel component auctions that then submit their top scoring ad to the final top-level auction. |
| Top-level auction | The final ad auction within a Protected Audience multi-seller auction that provides the scoring for the component auction winners from the component auctions. |
| Component auction | A nested auction within a Protected Audience multi-seller auction where each component seller is running their component auctions in parallel. The top scoring ads from each component auction is passed up to the top-level auction. |
Participants
| Participant | Definition |
|---|---|
| Advertiser | The party that desires an ad placement and builds the ad creative. |
| Publisher | The party that provides ad inventory for auction. |
| Buyer | The party that bids in an auction to buy the ad space from a seller. Commonly a demand-side platform (DSP). |
| Top-level seller | The party that invokes (that is, creates) the Protected Audience multi-seller auction and participates in the top-level auction. |
| Component seller | The party that runs a component auction within the Protected Audience multi-seller auction to sell the publisher's ad space to the buyers. Commonly a supply-side platform (SSP). |
Configure a multi-seller auction
Configuring a multi-seller auction largely follows the same steps as configuring
a single seller auction with one key difference. To trigger the component
auctions, the top-level seller will need to include the list of auctionConfigs
for each seller in their auctionConfig's componentAuctions field. These
auctionConfigs are the same format as if they were running as a single seller
auction, though they may not include componentAuctions themselves. There can
only be one top-level auction in any given Protected Audience API
auction. Additionally, when componentAuctions is non-empty,
interestGroupBuyers must be empty.
Protected Audience multi-seller-auction
Component auctions are executed in parallel, and in each component auction the browser generates bids from the bidding logic of each buyer participating in that component auction, scores each bid using the component seller's scoring logic, and then returns the highest scoring ad to the top-level auction. Each component sellers' auction can return at most one ad candidate to the top level auction. The auction flow can be described as:
- The publisher site loads the top-level seller's script.
- The top-level seller's client-side library provides component auction configs with signals from buyers to the top-level seller.
- The top-level seller starts the Protected Audience auction by calling
runAdAuction(). - Seller A component auction (running in parallel to Seller B's component auction). The browser reads the user's interest groups for all buyers participating in Seller A's component auction.
- The browser fetches the bidding scripts and trusted bidding signals from the locations specified in the interest groups of the buyers participating in the component auction.
- The browser generates the bids by executing each buyer's bid generation logic.
- The browser fetches the scoring script and trusted scoring signals of each ad from Seller A.
- The browser executes Seller A's scoring logic for each bid.
- The browser chooses the ad with the highest score submitted by Seller A's scoring logic.
- Seller B component auction (running in parallel to Seller A's component auction). The browser reads the user's interest groups for all buyers participating in Seller B's component auction.
- The browser fetches the bidding scripts and trusted bidding signals from the locations specified in the interest groups of the buyers participating in the component auction.
- The browser generates the bids by executing each buyer's bid generation logic.
- The browser fetches the scoring script and trusted scoring signals of each ad from Seller B.
- The browser executes Seller B's scoring logic for each bid.
- The browser chooses the ad with the highest score submitted by Seller B's scoring logic.
After the component auctions complete, the browser has a list of ads that can be sent to the top-level seller's scoring logic.
Top-level auction scoring and ad rendering
After the component auctions from the previous section are executed, the browser runs the top-level seller's scoring logic on each component auction's winning ad.
- The browser fetches the scoring script from the top-level seller along with trusted scoring signals of each ad.
- The browser executes the top-level seller's scoring logic for each winning bid of all component auctions. The script calculates the desirability score, likely based on the component Protected Audience bid price.
- The browser chooses the ad with the highest desirability score submitted by the top-level seller's scoring logic.
- The Protected Audience auction returns a
FencedFrameConfigobject or an opaque URN to the top-level seller's client-side library. - Client-side library sets the fenced frame's
configattribute to theFencedFrameConfigobject or sets the iframe'ssrcattribute to the opaque URN of the winning Protected Audience ad. - The browser fetches the Protected Audience auction winning ad from the buyer.
- The browser renders the ad to the user.