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:
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.
At a high level, the flow of data is described as follows:
- On device, sellers collect information from Protected Audience using the
getAdSelectionData
API. - The on-device SDK sends a request to their Seller Ad
service. This request includes contextual payload and
encrypted
ProtectedAudienceInput
. - 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.
- The Seller Ad service sends a request to their SellerFrontEnd service running in a TEE.
- The SellerFrontEnd service sends requests with buyer specific data to BuyerFrontEnd services.
- 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.
- 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.
- The Seller Ad service returns the encrypted winning result, and optionally a contextual result, to the on-device SDK.
- 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:
- Adding
ad_render_id
inCustomAudience
so that it is sent usingadSelectionData
instead of using ad render URI and metadata. Ad techs can further optimize this by not sending ad data inadSelectionData
. This option will be supported in theCustomAudience API
in future releases. - Ensure
user_bidding_signals
are not sent inadSelectionData
. Instead, ad techs can fetchuser_bidding_signals
from their Key/Value server. - Allow the buyers to prioritize
CustomAudience
. - Allow the buyer to specify seller priority.
- 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.