FLEDGE has been renamed to Protected Audience API. To learn more about the name change, read the blog post.
Author:
Rashmi Rao, Google Privacy Sandbox
Bidding and Auction services outline a way to allow Protected Audience auctions to take place in a trusted execution environment (TEE) hosted on a supported cloud platform.
This explainer describes the system design for event level reporting using the Bidding and Auction services specifically in multi seller scenarios. For single-seller event level reporting refer to this explainer.
For detailed design of multi seller auction support on Bidding and Auction Services refer to this explainer.
For high level design, ad tech specifications, API, refer to the Bidding and Auction services explainer.
The seller and the winning buyer each have an opportunity to generate URLs for event-level reporting based on an auction outcome.
Reporting with Bidding and Auction services is planned to be supported in multiple phases.
| Reporting support with Bidding and Auction services | Timeline |
| Win reporting for single seller auctions | LAUNCHED |
| Win reporting for device-orchestrated multi seller auctions. | Beta 2 |
| Win reporting for server-orchestrated multi seller auctions. | Beta 2 |
| Private Aggregation API | Scale Testing |
This document details the design to generate win reporting urls with the Bidding and Auction Services for multi seller auctions. The urls are sent back to the client (browser, Android) and pinged from the client after the ad is rendered.The design for single seller auctions is covered in a different explainer.
Multi seller auctions are those auctions with participation from multiple sellers and their partner buyers, where the final winning ad candidate is decided by a top level auction. There multiple types of multi seller auctions:
- Device-orchestrated component auctions - Only for browsers
- Server-orchestrated multi seller auctions - For browsers and Android
- WaterFall meditation - Only for Android apps
This document will focus on device-orchestrated and server-orchestrated multi seller auctions.
In device-orchestrated component auctions, 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.
In server-orchestrated component auctions, 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.
For a single-seller auction, reporting urls are generated for the winning buyer and seller (as explained here).
For multi seller auctions, event level reporting urls are generated for the top-level seller, winning component seller and winning buyer.
The inputs to each reportResult and reportWin function are expected to be different for each of them:
| Input Signals | Provided to
Top Level Seller’s reportResult |
Provided to
Component Seller’s reportResult |
Provided to Component Buyer’s reportWin |
| Auction Signals | Yes
(Top Level auction config) |
Yes \ (Component level auction config) | Yes \ (Component level auction config) |
| topWindowHostname | Yes | Yes | Yes |
| topLevelSeller | Yes | Yes | Yes |
| componentSeller | Yes | Yes | Yes |
| interestGroupOwner | Yes | Yes | Yes |
| renderURL | Yes | Yes | Yes |
| bid | Yes
(modified bid) |
Yes \ (buyer bid) | Yes \ (buyer bid) |
| desirability | Yes
(Top level score) |
Yes
(Component level score) |
No |
| topLevelSellerSignals | No | No | No |
| modifiedBid | No | Yes | No |
| highestScoringOtherBid | No | Yes | Yes |
| madeHighestScoringOtherBid | No | No | Yes |
| adCost | No | No | Yes |
| interestGroupName | No | No | Yes
(may be included if the tuple of interest group owner, name, bidding script URL, ad creative URL, and ad creative size were jointly k-anonymous once B&A supports K-anonymity). |
| seller | No | No | Yes |
| joinCount | No | No | Yes |
| recency | No | No | Yes |
| modelingSignals | No | No | Yes |
| signalsForWinner | No | No | Yes |
| perBuyerSignals | No | No | Yes |
On-device Protected Audience auctions support passing output of the top level seller reportResult call as the topLevelSellerSignals input to the component seller's reportResult call. This creates a dependency in the reporting function execution for the component seller and buyer on the reportResult() execution of the top level seller for the topLevelSellerSignals.
This dependency may not be necessary and adtechs have not provided requirements for supporting this. This dependency is removed for reporting URL generation in Bidding and Auction Services and the topLevelSellerSignals will not be passed to the component seller’s reportResult.
The reporting URLs for the component auctions will be generated immediately after the component auction for both component level seller and buyer. The win reporting urls for the seller and buyer from the component auction are passed to the top level auction in the response from SFE for both device orchestrated and server orchestrated component auctions.
The top-level seller will receive the reporting urls for all the component sellers and winning buyers in the response from the component auctions. After the top level auction, the browser will run the top-level seller’s reportResult(). All the reporting urls will finally be pinged after the ad has rendered.
For component auctions, the reporting urls will be populated in component_seller_reporting_urls instead of the top_level_seller_reporting_urls
The top-level seller will receive reporting urls for the component seller and winning buyer in the response from the component auctions. After the final top level auction in the top level seller's TEE based Auction service, the top level seller can run the reportResult() to generate a reporting url and return all the urls back to the client. The client will get the reporting urls for all the sellers and winning buyers and the top level seller in AuctionResult ciphertext in the response.
For component auctions, the reporting urls will be populated in component_seller_reporting_urls ScoreAdsResponse instead of the top_level_seller_reporting_urls
For top-level auctions, the reporting urls will be populated in top_level_seller_reporting_urls
Note: If the top_level_seller field in the AuctionConfig of SelectAdRequest is set, it will be considered a component auction. This field will be set by the component seller's ad server,based on an agreement with the top-level seller.
Once the ad has been rendered on the client, all the reporting urls will be pinged. The clients will perform a check for enrollment_ _and attestation. There will be additional validation to ensure that the reporting url domain matches the domain of the AdTech on Android.