Bidding and Auction services

In the initial Protected Audience proposal, bidding and auction for remarketing ad demand is executed locally on device. This requirement can demand computation requirements that may be impractical to execute on devices with limited processing power, or may be too slow to select and render ads due to network latency.

The Bidding and Auction services (B&A) proposal outlines a way to allow Protected Audience computation to take place on cloud servers in a trusted execution environment (TEE), rather than running locally on a user's device. The B&A proposal aims to support a unified flow for considering contextual and remarketing ad demand. Moving computation to servers can help optimize the Protected Audience auction by freeing up computational cycles and network bandwidth for a device.

Google will provide the components of B&A, and they will be made available as open source. Interested ad techs can host their own instances with supported public cloud providers. You can read more about the B&A proposal on GitHub. Note that the dates presented in that document reflect implementation for Chrome, and we will publish more information about integration with Android in the future. This document serves as an introduction to B&A, and the new APIs Android will provide to interact with B&A. We will post more technical information about how to use these new APIs in future updates.

Where B&A services fit in

B&A provides an additional option for running an auction inside ad tech owned trusted servers running an open source binary provided by Google. User data still lives on the device, and Google will provide APIs for securely moving that data to the TEE. More on our encryption strategy below.

This means that some parts of the auction process happen on device, and others in the cloud. From a DSP's perspective, custom audiences (included candidate ads for remarketing campaigns) are still managed on device using the same custom audience management APIs as when the auction is run on the device. From an SSPs perspective, requests are still triggered on device, and this document describes the new APIs that will be used. For all parties, reporting the result of an auction still starts from the device, after the B&A call completes.

The major difference comes with where the bidding, scoring and reporting URL generation logic is executed. Instead of running bidding, auction, and reporting logic on the device, generateBid(), scoreAd(), reportResult(), and reportWin() logic is executed in the TEE. A buyer's bidding logic and seller's scoring logic is executed within their own B&A environment, in the middle of the Protected Audience auction flow:

Illustration showing the Protected Audience auction flow and where bidding and auction fits.
The Protected Audience auction flow

Data Encryption

With B&A, Protected Audience information such as custom audiences and bid amounts flow from the device, through seller ad tech servers, to buyer ad tech servers, and back through to the device. Because of this, the platform encrypts data going to Protected Audience services, and is only able to be decrypted by services that have been attested. Read more about encryption strategies on GitHub.

Architecture and auction flow

This proposal includes the need for several new components detailed on GitHub, including the flow of data from device to B&A.

Illustration showing the unified contextual and protected audience auction flow, described next.
Unified contextual & Protected Audience auction flow, with bidding and auction services.

At a high level, the flow of data is described as follows:

  1. On device, sellers collect information from Protected Audience using the getAdSelectionData API.
  2. The on-device SDK sends a request to their Seller Ad service. This request includes contextual payload and encrypted ProtectedAudienceInput.
  3. The Seller Ad service sends a request to the buyers' real time bidding (RTB) service running outside of a TEE to obtain candidate contextual ads, and then score and select a winning contextual ad.
  4. The Seller Ad service sends a request to their SellerFrontEnd service running in a TEE.
  5. The SellerFrontEnd service sends requests with buyer specific data to BuyerFrontEnd services.
  6. Buyers use their own Key/Value service and Bidding service, which generates bids for ad candidates sourced from the device for all custom audiences considered for remarketing.
  7. The SellerFrontEnd service reads from their Key/Value service and scores the candidate ads. The result is encrypted and returned to the Seller Ad service.
  8. The Seller Ad service returns the encrypted winning result, and optionally a contextual result, to the on-device SDK.
  9. On the device, sellers retrieve the winning ad using the processAdSelectionResult API, which decrypts the response from Seller Ad service.

A detailed description of each step and how data is encrypted is found on GitHub. The code for these components will be made available via open source. The code provided will handle federation of requests from SellerFrontEnd service to BuyerFrontEnd services.

Cloud Deployment

Ad techs will deploy B&A services to a supported public cloud platform. These deployments are to be managed by ad techs who will be responsible for defining an availability service Level Objective.

Run an auction

The first step to running the B&A auction is to gather the data from on-device custom audiences and encrypt it to be sent to the server side auctions. To do this, use the getAdSelectionData API:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

The getAdSelectionData method generates the required input for B&A components, such as BuyerInput and ProtectedAudienceInput, and encrypts the data before making the result available to the caller. To prevent data leaking across apps, this data contains information from all buyers present on the device. Read more about this decision in the privacy considerations section.

This API returns an AdSelectionData object:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Using this AdSelectionData, the on-device SDK can send a request to their Seller Ad service by including the data in a POST or PUT request:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

The on-device SDK is responsible for encoding this data. It is recommended to use a space efficient solution such as sending the request to the Seller Ad service as multipart/form-data.

Once the request is initiated, the Seller Ad service forwards the request to the SellerFrontEnd service running in a TEE. When configuring a SellerFrontEnd service, sellers will provide a list of domain addresses that correspond to the BuyerFrontEnd services operated by the buyers that the seller is partnered with. Requests will be federated to the various BuyerFrontEnd services the seller has provided, so that buyers will be able to generate bids for their selected ad candidates. For a specific buyer, B&A will only send information about custom audiences that buyer owns so that there is no cross-leaking of data between buyers. After generating the bids, the list of candidate ads comes back to the SellerFrontEnd service where a winner is selected. Finally, the SellerFrontEnd service returns the encrypted winning ad to the device.

With the response from the request to the Seller Ad service back on the device, the platform offers a second new API to decrypt the result and provide an AdSelectionOutcome, the same object that is returned from an on device auction today.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Reporting

Reporting URLs will be generated in B&A services. Pings to those URLs for reporting impressions and interactions for auctions will still need to be triggered on device. The on-device SDK will still need to invoke reportImpression() and reportInteraction() APIs using AdSelectionId generated during the B&A flow. Beacons generated for interaction reporting and the corresponding URLs are contained in the encrypted response, so during decryption of the response that events and URL mappings are stored on the device.

Privacy Considerations

The Browser Bidding & Auction API proposal on GitHub describes how privacy considerations have been considered. This proposal uses Chrome's nomenclature, but the same principles apply to Android.

adSelectionData is encrypted to ensure that data in transit is accessible only to PPAPI and the trusted servers. To mitigate the risk of data leakage due to adSelectionData size changes, , we plan to generate the same adSelectionData for all calls to getAdSelectionData API. This implies that all the CustomAudience on the device are used for creating adSelectionData. We also plan to restrict the influence of GetAdSelectionData input parameters on the adSelectionData generated.

Generating the same adSelectionData for all ad techs using all the on-device auction data leads to a higher payload that needs to be transferred in every call to the ad tech server, while potentially opening the ecosystem to abuse from malicious entities. These concerns are addressed in the Size considerations and Anti-abuse considerations sections below.

Size considerations

The ad tech client SDK is expected to package the encrypted bytes of adSelectionData into a call for contextual ads made to the Seller's server. For optimal performance, it is important to optimize the size of adSelectionData without compromising functionality. We plan to introduce optimizations as mentioned in the Payload optimization explainer to reduce adSelectionData size. These optimizations will include:

  1. Adding ad_render_id in CustomAudience so that it is sent using adSelectionData instead of using ad render URI and metadata. Ad techs can further optimize this by not sending ad data in adSelectionData. This option will be supported in the CustomAudience API in future releases.
  2. Ensure user_bidding_signals are not sent in adSelectionData. Instead, ad techs can fetch user_bidding_signals from their Key/Value server.
  3. Allow the buyers to prioritize CustomAudience.
  4. Allow the buyer to specify seller priority.
  5. Generate adSelectionData in a few fixed buckets to limit bit leakage while reducing payload size.

Size optimizations will be made while adhering to the concerns raised in privacy considerations.

Anti-abuse considerations

As mentioned in Privacy considerations, adSelectionData is generated by using all the buyer data on the device.

This opens the ecosystem to potential malicious entities that could add fraudulent buyer data that could degrade performance, bloat payloads to increase costs, etc.

To combat abuse of adSelectionData, we'll introduce the following measures

  • Allow CustomAudience to explicitly specify approved sellers and seller priority
  • Allow SSPs to explicitly specify buyer, buyer priority, per-buyer quota in the payload generated
  • Provide a mechanism for SSPs to define a maximum number of buyers per call or max size per buyer.

These measures are designed to allow ad techs to define which other ad techs they collaborate with, and to set acceptable limits on the adSelectionData payload they would need to process. We propose allowing the seller to specify this buyer list and priority in a separate call. This specification will be constant throughout some interval of time to avoid exposing additional data about the user via repeated calls.

The mitigations mentioned above are under discussion and subject to evolve over time. As mentioned earlier, all mitigations introduced for anti-abuse and size restrictions must adhere to privacy considerations.