FLEDGE has been renamed to Protected Audience API. To learn more about the name change, see the blog post
Authors:
Jaspreet Arora, Google Privacy Sandbox
Priyanka Chatterjee, Google Privacy Sandbox
This document explains the proposed multi-seller auction flows using Bidding and Auction services. We propose following types of multi-seller auctions:
- Device-orchestrated component auction
- Server-orchestrated component auction
This explainer provides building blocks for ad techs to participate in multi-seller auctions with their ad management solution. While this explainer does not provide step-by-step instructions for each specific ad tech’s integration, we aim to provide options to meet your auction use cases.
Note: SSP and DSP can operate Bidding and Auction services on different cloud platforms that are supported. For multi seller auctions, SSPs can operate on different cloud platforms.
Refer to this section for related explainers. You can share feedback on the design by filing a GitHub issue.
Additional questions remain open for comment. As we build this technology, we’ll provide more detailed setup instructions.
Note: We will publish reporting designs for multi seller auctions in a different explainer. If you developed reporting scripts using Chrome on-device Protected Audience specification, that would work with Bidding and Auction services.
A party running an ad auction, likely to be an ad tech supply-side platform (SSP).
A party bidding for ad space in an ad auction, likely to be a demand-side platform (DSP), or the advertiser itself. Ad space buyers own and manage Protected Audience interest groups.
A server owned by a seller to orchestrate real-time bidding (RTB) requests and Protected Audience auction requests to Bidding and Auction services.
A seller’s single request for the contextual and server-side Protected Audience auction, from their code on a publisher site. This was described in the Bidding and Auction services high-level design and API explainer.
- The seller’s ad service makes two sequential requests.
- [Existing flow] The seller sends real-time bidding (RTB) requests to buyers for contextual bids, then conducts the contextual auction.
- [Server side Protected Audience flow] The seller sends a SelectAd request to SellerFrontEnd service to start the Protected Audience auction. The request payload includes encrypted Protected Audience data, contextual signals, buyer_list, seller_origin, per_buyer_timeout and other necessary information.
- The SellerFrontEnd conducts the Protected Audience auction. It returns an encrypted response that includes either the winning bid, or an encrypted padded response if the contextual bid filters all Protected Audience bids. For privacy reasons, the seller's ad service will be unable to determine if the payload has a winning Protected Audience ad or not, so it should also pass the contextual winner to the client.
In this explainer, we use "Contextual auction" to mean everything that does not involve cross-site data. This includes the contents of the web page or URL where the ad will appear, which is the traditional sense of "contextual." But for our purposes, first-party data that the publisher provides about their user, or Seller-Defined Audience data, are also bundled into what we are calling "contextual".
An auction conducted by a single seller among a collection of buyers, as part of a multi-seller auction. The auction winners then participate in a top-level auction. In a unified flow, the top-level auction includes the winners for the contextual auction and/or the winner for the Protected Audience auction. Each Component auction follows the single seller unified flow specified in Bidding and Auction Services Design.
The auction which decides the final winner, conducted after individual seller auctions (component auctions).
Note: The top-level auction runner cannot use Protected Audience data to bring its own demand. Therefore buyers can not participate in the top-level auction. The top-level auction scores winning bids from component auctions.
Auctions with participation from multiple sellers and their partner buyers, where the final winning ad candidate is decided by a top level auction.
The sell-side ad tech or the publisher conducting the top-level auction. This ad tech specifies the scoreAd() script and auction config for scoring the winning candidates from Component auctions.
The sell-side ad techs that integrate with a top-level seller and conduct their own Component auction. The winners from those auctions are scored in the top-level auction.
We expect to make Multi seller auction support with Bidding and Auction services available for testing by September 2023.
This type of multi seller auction will be supported for web advertising with Bidding and Auction services.
The Bidding and Auction services allow Protected Audience computation to take place on cloud servers with a trusted execution environment (TEE), rather than locally on a user's device. Each Bidding and Auction service is hosted in a virtual machine (VM) within a secure, hardware-based TEE. Ad tech platforms operate and deploy Protected Audience services on a public cloud.
The sell-side services include the SellerFrontEnd service and the Auction service. The SellerFrontEnd service orchestrates requests in parallel to buyers by communicating with multiple BuyerFrontEnd Services. This service also fetches real-time scoring signals from the seller's Key/Value service required for the auction and calls the Auction service for Protected Audience auction. The Auction service will execute the seller-owned code to score the bids from their seller partners. Review a detailed overview of the sell-side services.
The buy-side services include the BuyerFrontEnd service and the Bidding service. The BuyerFrontEnd service communicates with the Buyer-operated Key/Value services to fetch bidding signals and call the Bidding service to generate bids. The Bidding service will execute the buyer-owned code to generate the bids for the interest groups. Review a detailed overview of the buy-side services.
The seller’s ad service starts the Protected Audience auction on the Auction service by sending a request to the SellerFrontEnd Service with the encrypted Protected Audience data (from the browser), and contextual signals in plaintext. Read about the Protected Audience auction flow using the Bidding and Auction Services.
The Bidding and Auction services API will be extended to support multi-seller auction flows, with an updated API. There are two different ways in which a multi-seller auction could make use of these services, based on where the top-level auction takes place.
Device-orchestrated Component auction: Each component auction is orchestrated by the respective seller in the publisher web page, in the browser. Each component auction can be conducted with the Bidding and Auction services or on-device. The top-level Protected Audience auction is executed on the browser.
Note: If all component sellers run auctions on-device, the component auction flow should be the same as described in Chrome Protected Audience on-device explainer.
Server-orchestrated Component auction: The top-level seller makes one request for an auction, from the publisher web page, to its ad service, The top-level seller’s ad service orchestrates unified requests to other sellers for Component auctions that can run on Bidding and Auction services. Then, the top-level Protected Audience auction is executed in the top-level seller's TEE-based Auction service.
Each component seller sends a unified request for its specific Component auction. Each sellers' code calls the browser API to obtain the encrypted Protected Audience request payload. Then, they forward this payload to their own ad servers as a unified request. Requests can be sent from the client in parallel.
Each component seller decides where its auction takes place. This means sellers can run a Protected Audience component auction on-device or with the Bidding and Auction services.
-
If a seller decides to run a Protected Audience component auction on-device, their partner buyers that participate in the auction must generate bids on-device. If a seller decides to run a Protected Audience component auction in the Protected Audience Auction service, their participating partner buyers must generate bids server side in the Protected Audience Bidding service.
-
If a seller decides to run a Protected Audience component auction on-device, the seller code in the publisher web page on browser sends contextual request to seller's ad service, the contextual response include contextual signals required to build Protected Audience auction config, then the Protected Audience component auction executes on-device.
The contextual auction winner and encrypted Protected Audience response from each Component auction are made available to the browser. The top-level seller conducts the final contextual auction with the contextual auction winners from the contextual half of the component auctions, and populates the auction config (scoring signals and auction signals). This can happen on-device or on the top-level seller’s ad service. Then the top-level seller's ScoreAd() function scores the Protected Audience bids received from the Protected Audience half of the component auctions. This takes place on the device.
The flow describes Protected Audience component auction in Bidding and Auction services or on the browser, followed by top level auction on the browser.
-
Following is the flow if Protected Audience component auction happens server side:
-
Each component-level seller’s code on a publisher’s web page on browser calls respective seller's ad service for a Component auction with one unified request, as per the Contextual and Protected Audience auction flow. If the seller decides to run server side Protected Audience auction in Bidding and Auction services, then a unified request is sent; if the seller decides to run Protected Audience auction on the browser, the contextual request is sent to seller ad service. The requests fan out in parallel from the publisher web page for each Seller.
- The unified request includes contextual payload and encrypted Protected Audience data.
- The seller's ad service uses the contextual payload to run a contextual auction.
- The seller's ad service forwards the encrypted Protected Audience data and contextual signals to the TEE-based
SellerFrontEnd service to conduct the Protected Audience auction.
- This flow is similar to the Protected Audience auction described in Bidding and Auction services with one special handling for which bids are skipped for scoring if corresponding allow_component_auction field is set to false in the AdWithBid response from Buyer.
- For the bids that are scored, the allowComponentAuction flag and modified bid field would be returned by the scoreAd() script. For the winning Protected Audience bid, these will be returned to the client in the encrypted Protected Audience response.
-
Each component seller's ad service sends its contextual ad winner ad and/or encrypted Protected Audience response from component auctions back to the browser.
-
If the seller's component Protected Audience auction does not produce any winner, an encrypted, padded (fake) Protected Audience response is returned from the TEE-based SellerFrontEnd service to the seller's ad service.
-
The seller code in the publisher web page passes the encrypted Protected Audience response to the browser. Note: Only the browser API can decrypt the response. The client-side design details are documented in the Browser API design for Bidding and Auction services integration.
-
-
Following is the flow if Protected Audience component auction happens on-device:
-
Each component-level seller’s code on a publisher’s web page on browser calls respective seller's ad service for a contextual auction. This response includes contextual ad winner and contextual signals (that are part of the auction config) required for component-level Protected Audience auction.
-
Component-level Protected Audience auction happens on-device if the buyers and sellers determine if there is incremental value for Protected Audience. The highest scored bid and other data from this auction are made available for the top-level ScoreAd() on-device. See Chrome on-device explainer for details. See the explainer for Protected Audience API on browser for more details.
-
-
The code in a publisher’s page can pick the contextual winner on the browser or sends contextual ad winners to the top-level seller's ad service to pick the contextual ad winner.
- Contextual signals (seller signals and auction signals) are part of the top-level Protected Audience auction config and are required for the top-level Protected Audience auction.
-
Top-level Protected Audience auction scores Protected Audience bids that are made available from component auctions. The top-level Protected Audience auction happens in the browser. The client-side design details are documented in the Browser API design for Bidding and Auction services integration.
- The browser may fetch scoring signals for top level auction as done today in top-level Protected Audience auctions in the browser. However, the top-level seller can decide whether their script requires scoring signals for the top-level auction.
Note: The Bidding and Auction services will conduct a component auction or a top-level auction, based on the input to the SelectAd RPC.
The following new fields will be added to the plaintext AuctionConfig object sent to the SellerFrontEnd service by the Seller Ad server:
- string top_level_seller(optional): It’s similar to the seller field passed in the single seller auctions and will signal the Bidding and Auction services that this is a Component auction. This is passed in the deviceSignals field to the generateBid() and reportResult() code by ad-techs. The component auction output includes other information required by the client for the top-level auction (for example, allowComponentAuction).
syntax = "proto3";
// Plaintext. Passed by the untrusted Seller service for configuring options for // the auction.
message AuctionConfig {
// Existing fields ....
// Optional, but must be specifed if this is meant to be consumed for
// Component auctions. If this value is not present, the auction will be
// treated as single seller.
string top_level_seller = 9;
}
The following new fields will be added to the encrypted AuctionResult object, sent in the SelectAdResponse from the SellerFrontEnd service:
-
float bid (optional): This will be used to provide a modified bid value for the top-level seller scoring script. The original bid value will be returned in the “bid” field in AuctionResult. This will be populated from the “bid” field of the component seller’s scoreAd() code as described in the Chrome Protected Audience explainer. If this is not present, the original bid value will be passed to the top-level scoring script.
-
string ad_metadata (optional): This will be used to pass the ad's metadata to the top-level seller's scoring function. This will be populated from the “ad” field of the component seller’s scoreAd() script as described in the Chrome Protected Audience explainer. If this is not present, an empty string will be passed to the top-level seller scoring script.
-
string top_level_seller: This will contain the value passed by the seller’s ad server in the auction config object. This will be used by the device to validate that this is only used in a top-level auction run by the specified top-level seller.
The updated definition for AuctionResult will be as follows:
syntax = "proto3";
message AuctionResult {
// Existing fields ....
// Bid price corresponding to an ad.
float bid = 6;
// Optional name/domain for top-level seller in case this
// is a component auction.
string top_level_seller = 15;
// Optional. Metadata of the ad, this will be passed to top-level
// seller's scoring function. Represents a serialized string that is
// deserialized to a JSON object before passing to script. If this is
// not present, an empty string will be passed to the top-level
// seller scoring script.
string ad_metadata = 16;
// Reporting metadata required for top level auction will be updated
// later.
}
Note: Additional metadata will be sent back to the client for reporting (URL generation and report URL ping) after the top-level auction on the browser. The API changes will be published at a later date in a different explainer.
The seller's ad server orchestrates the flow to conduct the component auction as follows -
- Sends a SelectAdRequest to SellerFrontEnd service with a B&A payload ciphertext and an auctionConfig as described in the API changes.
Note: For a component auction, the auctionConfig must contain a topLevelSeller field with the domain of the top level seller which will call runAdAuction on the browser.
- Includes the encrypted AuctionResult responses (returned from the SelectAd request in step 1) sent back in the HTTP response body back to the JavaScript Fetch initiated by the browser with "adAuctionHeaders: true".
- Attaches base64url encoded SHA-256 hash of each encrypted response included in an HTTP response header (Ad-Auction-Result header) back to the browser.
Note: This is required by the browser to ensure that the encrypted AuctionResult response is in fact coming from the correct seller origin. Refer here for more details.
Following is an example of Ad-Auction-Result header:
Ad-Auction-Result: ungWv48Bz-pBQUDeXa4iI7ADYaOWF3qctBD_YfIAFa0=,
9UTB-u-WshX66Xqz5DNCpEK9z-x5oCS5SXvgyeoRB1k=
The following is an open question for the top level Seller:
In Device-orchestrated Component Auction, the top level auction would score Protected Audience (winning) bids from Component Auctions. In this case, are real-time scoring signals required to be fetched from the Seller's Key/Value service?
This type of multi seller auction will be supported for app and web advertising with Bidding and Auction services.
The top-level seller code in the publisher web page in the browser would send a unified request to the seller's ad service that includes separate contextual request payload for each seller participating in the auction and one encrypted Protected Audience request payload. The top-level seller’s code in the publisher web page asks the browser for this encrypted Protected Audience data to include in the unified request.
The top-level seller's ad service orchestrates the multi-seller auction, by sending contextual and server side Protected Audience auction requests in parallel to other component sellers' ad services. This orchestration is new work to be done by the top-level seller; it will not be handled by the open-sourced Bidding and Auction services code that runs inside a TEE. All sellers, including the top-level seller, execute respective unified flows for a contextual auction followed by Protected Audience auction if there is demand for Protected Audience as determined by buyers and the seller.
The top-level seller's ad service receives the contextual auction winners and encrypted Protected Audience winners from each Component auction. The top-level seller conducts the final contextual auction on their server, and prepares the contextual signals for the top-level Protected Audience auction. The top-level seller conducts the top-level Protected Audience auction in its TEE-based Auction service.
After the top-level Protected Audience auction, the SellerFrontEnd service will send an encrypted response payload to the top-level seller's ad service in SelectAd response. The top-level seller's ad service will be unable to determine if the encrypted Protected Audience response payload has a winning Protected Audience ad or not. The seller's ad service would pass both the top-level contextual ad winner and the encrypted Protected Audience response back to the client.
-
The top-level seller code on a publisher web page sends one request to the top-level seller's ad service for contextual and Protected Audience auction. The request payload includes:
-
Separate contextual request payloads for each participating seller.
-
One Protected Audience request payload for all component-level sellers. This payload is encrypted and padded by the browser, so that it’s the same size across all users and auctions.
-
-
The top-level seller server orchestrates unified requests in parallel for each component-level seller partner. The unified request payload includes the contextual request payload and the encrypted Protected Audience payload meant only for the partner seller.
-
The top-level seller's ad service calls SellerFrontEnd service to obtain encrypted payload for other sellers; this request payload also includes a list of partner sellers for the multi-seller auction.
-
The SellerFrontEnd service running in TEE decrypts the encrypted Protected Audience data and creates different payloads for each seller by adding different random noise to the input and re-encrypting the Protected Audience data. This ensures different encrypted data, in other words ciphertext is sent to each partner seller.
-
The SellerFrontEnd service returns different encrypted Protected Audience data mapped to the list of sellers back to the seller's ad service.
-
-
All sellers (including the top-level seller) execute respective unified flow in parallel. Each seller conducts a contextual auction with their respective ad service. If buyers and sellers determine if there is incremental demand for Protected Audience, the seller conducts a Protected Audience auction in TEE-based Auction service. Within the Protected Audience auction flow:
-
Bids are skipped for scoring based on the allow_component_auction field in the AdWithBid response from Buyer.
-
For scored bids, the allowComponentAuction flag and modified bid would be returned by the ScoreAd() script. For the winning Protected Audience bid, these will be returned to the client in the encrypted Protected Audience response.
-
-
Each component-level seller partner returns a contextual bid and / or an encrypted Protected Audience response to the top-level seller's ad service.
- Note: The top-level seller's ad service can not decrypt encrypted Protected Audience responses received from Component auctions; it can only be decrypted within an attested TEE-based service.
-
The top-level seller conducts a top-level contextual auction in its seller's ad service. The top-level seller also generates contextual signals (part of the AuctionConfig) that are required for the top-level Protected Audience auction.
-
The top-level seller conducts the top-level Protected Audience auction incorporating Protected Audience bids in the TEE-based Auction server.
-
The top-level seller sends all encrypted Protected Audience responses received from Component auctions to TEE-based SellerFrontEnd service. The TEE-based SellerFrontEnd service decrypts them. If there’s a Protected Audience ad winner from component auctions, the SellerFrontEnd service sends a request to the Auction service for top-level Protected Audience auction. If there's no Protected Audience ad winner from component auctions, the SellerFrontEnd service would return an encrypted padded (fake) response to the top level seller's ad service.
-
The SellerFrontEnd service returns a fixed-size encrypted padded Protected Audience response back to the seller's ad service. This is true whether or not the Protected Audience auction produced a winning ad.
-
The seller’s ad service won’t be able to determine if the encrypted payload has a winning Protected Audience bid or not, so it should also pass the contextual winner to the client.
-
-
The top-level seller returns the final contextual bid and / or Protected Audience winner back to the browser.
-
Seller code in the publisher web page passes an encrypted Protected Audience response to the browser.
- The seller code in the publisher web page can not decrypt the encrypted Protected Audience response, only the browser API will be able to decrypt that.
In a device-orchestrated component auction flow, the auction result contains a top level seller field which the device matches to make sure the component auction is only used by the appropriate top-level seller. In this case, the AuctionResult will also include an AuctionParams object which contains the following fields:
- string component_seller: This field will be used make sure the top level seller is not able to use the result ciphertext of a component seller for another component seller.
- string ciphertext_generation_id: This field will be used to make sure the component auction result is only used for the intended Protected Audience Auction initiated on the device and cannot be replayed.
syntax = "proto3";
message AuctionResult {
// Existing fields including auction_config....
message AuctionParams {
// The generation id in the request ciphertext. This is to ensure that
// the result from a component auction can only be used in the same
// top level auction as other component auctions conducted from the original
// ciphertext. This is checked in the top level seller SFE and the request
// is rejected in case of mismatch of result generation IDs.
string ciphertext_generation_id = 1;
// Component Seller domain.
// This field is used to tie the auction result to the specific seller who
// conducted the auction and is used in the top level auction as input
// to the scoreAd function.
string component_seller = 2;
}
// This is only populated for component auctions.
AuctionParams auction_params = 18;
}
The SelectAdResponse for Server component Auctions will contain the following additional fields:
- string key_id: Version of the public key used for encryption by component seller SFE. The top-level seller SFE needs to use private keys corresponding to same key_id to decrypt 'component_auctions_results'.
syntax = "proto3";
message SelectAdResponse {
// Existing fields
// Encrypted AuctionResult from FLEDGE auction. May contain a real candidate
// or chaff, depending on ScoreAd() outcomes.
bytes auction_result_ciphertext = 1;
// ------------- New fields --------------
// Version of the public key used for encryption by component seller SFE. The
// top-level seller SFE needs to use private keys corresponding to same key_id
// to decrypt 'component_auctions_results'.
string key_id = 3;
}
The auction config for component auctions will include the cloud platform information for the top level seller to make sure the results are encrypted with the correct public key which can be decrypted on the top level seller’s SFE.
syntax = "proto3";
message AuctionConfig {
// Existing fields including auction_config....
// Optional. specifies the cloud provider for the top-level seller. If this
// field is populated along with top-level seller field, this will be
// treated as a server orchestrated component auction, and the AuctionResult
// object in SelectAdResponse will be encrypted with a public key instead
// of the shared encryption context.
EncryptionCloudPlatform top_level_cloud_platform = 11;
}
The following new fields will be added to the SelectAdRequest object to conduct a top-level auction in the Bidding and Auction service with "Server-Orchestrated Component auction":
- repeated ComponentAuctionResult component_auction_results: For conducting a top-level auction in top-level Seller's Auction service, the top-level seller can pass in the encrypted responses from component-level Protected Audience auctions. Along with this, the seller would also have to populate the AuctionConfig for passing the contextual signals for the top-level auction. The seller can leave the existing protected_audience_ciphertext field empty; it will be ignored otherwise.
The updated definition for SelectAdRequest will be as follows:
syntax = "proto3";
message SelectAdRequest {
// Existing fields ....
message ComponentAuctionResult {
// Encrypted AuctionResult from a server component auction.
bytes auction_result_ciphertext = 1;
// Version of the public key used for encryption. The service
// needs to use private keys corresponding to same key_id to decrypt
// 'auction_result'.
string key_id = 2;
}
// List of encrypted SelectAdResponse from component auctions.
// This may contain Protected Audience auction bids from the component level auctions,
// that will be scored by the top level seller's ScoreAd().
// If this field is populated, this is considered a top-level auction and the other
// protected_audience_ciphertext field (if populated) will be ignored.
repeated ComponentAuctionResult component_auction_results = 5;
}
A new API endpoint will be added to the SellerFrontEnd service: GetComponentAuctionCiphertexts.
For server-orchestrated Component auctions, this endpoint can be used to get encrypted Protected Audience payloads for partner component sellers. The API uses the encrypted Protected Audience data sent from the device to create unique / distinct ciphertexts for the partner sellers.
syntax = "proto3";
// SellerFrontEnd service operated by Seller.
service SellerFrontEnd {
// Returns encrypted Protected Audience request payload for component level sellers for
// component auctions.
rpc GetComponentAuctionCiphertexts(GetComponentAuctionCiphertextsRequest) returns (GetComponentAuctionCiphertextsResponse) {
option (google.api.http) = {
post: "/v1/getComponentAuctionCiphertexts"
body: "*"
};
// Request to fetch encrypted Protected Audience data for each seller.
message GetComponentAuctionCiphertextsRequest {
// Encrypted ProtectedAudienceInput from the device.
bytes protected_audience_ciphertext = 1;
// List of partner sellers that will participate in the server orchestrated
// component auctions.
repeated string component_sellers = 2;
}
// Returns encrypted Protected Audience data for each seller. The ciphertext
// for each seller is generated such that they are unique.
message GetComponentAuctionCiphertextsResponse {
// Map of sellers passed in request to their encrypted ProtectedAudienceInput.
// Key ID is baked into the payload as done on device.
map<string, bytes> seller_component_ciphertexts = 1;
}
Note: For event level win reporting, urls will be generated on the server side and sent back to the client for pinging from the device. The API changes around reporting URL generation will be published at a later date in a different explainer.
Following are the specifications for ad tech owned code to support multi seller component auctions. Ad tech's code for scoreAd() and GenerateBid() would work with the following changes.
Note: If scoring happens in TEE-based Auction service, bid_metadata is built by Auction service.
The seller scoreAd() code needs to return the allowComponentAuction flag and a bid.
scoreAd(adMetadata, bid, auctionConfig, trustedScoringSignals, bidMetadata) {
...
return {...
//Modified bid value to provide to the top-level seller script.
'bid': modifiedBidValue,
// If this is not true, the bid is rejected in top-level auction.
'allowComponentAuction': true
};
}
The bid_metadata / browerSignal passed to ScoreAd() for top-level Protected Audience auction would also include componentSeller which is the seller for the Component auction.
GenerateBid() should set the allowComponentAuction flag to true. If this is not present or set to ‘false’, the bid will be skipped in the Protected Audience component auction.
generateBid(interestGroup, auctionSignals, perBuyerSignals, trustedBiddingSignals, browserSignals) {
...
return {...
'allowComponentAuction': true,
};
}
- Bidding and Auction services
- Bidding and Auction services payload optimization
- Bidding and Auction services system design explainer
- Bidding and Auction services AWS cloud support and deployment guide
- Bidding and Auction services GCP cloud support and deployment guide
- Protected Audience services
- Chrome client design for Bidding and Auction services integration
- Android - Bidding and Auction services integration high level document