Protected Audience for Android Interest Group, Bidding, Auction Clarifications/Questions

[thegreatfatzby]

Couple of diffs between Protected Audience for Web (PaW?) and Protected Audience for Android (PaDroid?):

• Not all attributes from PaW seem to be in PaDroid, and while certainly some may not make sense on device rather than in a browser (executionMode in particular) a few others seem relevant from a functionality perspective: priority and priorityVector, adComponents, adSizes and sizeGroups.
• It looks like generateBid is called once per ad rather than once per IG. I definitely see advantages and disadvantages, what is the thinking here?
• Is the IGs userBiddingSignals passed to generateBid in the user_signals parameter? The description here talks about "installed package information" which makes me think about more generic environment info, instead of the IG specific signals...perhaps I'm wrong?
• Similarly on the audience side some of the more operational flags around timeouts and limits aren't there. The timeouts and such are operational but useful and can help with limiting invited IGs (similar to priorityVector).

I guess this leads to two kind of meta questions:

• Is the goal of PaDroid to, within the degree possible given Android and Chrome Browser aren't the same environment, have an implementation and design that aligns with PaW, allowing Ad Techs to implement to the same "idea" even if certain things on the client have to be slightly different? Is this something the "Android Privacy Sandbox" team and leads are coordinating on with the Chrome folks like @michaelkleber @JensenPaul , or should this be seen as a different effort in important ways?
• Related but separate, how should we understand the status of these docs?

[semyers]

Thanks for these questions an apologies for the delay. Breaking up your questions and addressing them individually below:

Not all attributes from PaW seem to be in PaDroid. [These] seem relevant from a functionality perspective: priority and priorityVector, adComponents, adSizes and sizeGroups.

Some of the differences are due to the fact that Android development started later than Chrome so there is some catching up to do, others are due to the fact that the Android team is prioritizing support for B&A auctions and the current developer documentation focuses on older on-device auction APIs, finally others are caused by differences between the two platforms. For the specific examples you mentioned:

• Priority will be available soon and will be used to control the list of IGs to be included in the payload sent to B&A for the auction as part of the payload size optimization features. We haven’t planned support for priorityVector yet because it is not used for payload optimization
• We will be releasing support for component ads soon
• Support for ad sizes is not planned yet

It looks like generateBid is called once per ad rather than once per IG. I definitely see advantages and disadvantages, what is the thinking here?

For Android on-device auctions, the bidding logic calls generateBid once per ad. For Android Bidding & Auction server-side (B&A) auctions, the bidding logic calls generateBid once per interest group (i.e. custom audience), which matches the behavior in Chrome. We are currently in the process of updating our developer documentation to focus more on Android B&A auctions.

Is the IGs userBiddingSignals passed to generateBid in the user_signals parameter?

For Chrome and Android B&A auctions, userBiddingSignals is a property on the interestGroup parameter, which is the first param passed to generateBid.

For Android on-device auctions, user_bidding_signals is a property on the custom_audience_bidding_signals parameter, which is the last param passed to generateBid.

Is the goal of PaDroid to, within the degree possible given Android and Chrome Browser aren't the same environment, have an implementation and design that aligns with PaW, allowing Ad Techs to implement to the same "idea" even if certain things on the client have to be slightly different?

Yes, it is correct to say that Protected Audience APIs for Android and Chrome are similar conceptually but have some different implementation details.

Is this something the "Android Privacy Sandbox" team and leads are coordinating on with the Chrome folks like @michaelkleber @JensenPaul , or should this be seen as a different effort in important ways?

Privacy Sandbox APIs for Chrome and Android are similar efforts and we do try to keep the implementations consistent where it makes sense.

Related but separate, how should we understand the status of these docs?

The documentation on GitHub represents the design proposals for Privacy Sandbox APIs. Official developer documentation for what has been implemented is located on the Privacy Sandbox Developers site at https://developers.google.com/privacy-sandbox/.