Skip to content

Latest commit

 

History

History
301 lines (221 loc) · 14.6 KB

bidding-auction-services-payload-optimization.md

File metadata and controls

301 lines (221 loc) · 14.6 KB
Raw

FLEDGE has been renamed to Protected Audience API. To learn more about the name change, see the blog post

Author:
Priyanka Chatterjee, Google Privacy Sandbox

Bidding and Auction services payload optimization

The Bidding and Auction (B&A) services outlines a way to allow Protected Audience auctions to take place in a trusted execution environment (TEE) on a supported cloud platform.

The seller's code in a publisher's web page or Android app sends a unified contextual and Protected Audience auction HTTPS request (unified request) to the seller's ad service. The request includes contextual payload and encrypted ProtectedAudienceInput data.

This document provides guidance for optimization of the Protected Audience data payload size for DSPs / buyers. This guidance is needed for the following reasons:

  • With Bidding and Auction services, sending interest group information to server side from the client is expensive, because this impacts overall auction latency and increases network cost for sellers and buyers. To mitigate this issue, the total size of compressed request payload must be small (less than 50 KB).

  • The seller or client may impose a per-buyer payload size limit for ProtectedAudienceInput.

Note: The ProtectedAudienceInput request payload is compressed, padded and then encrypted on the client. The payload is decrypted and decompressed in Bidding and Auction services.

Payload optimization is not impacted by K-anonymity integration. The details about K-anonymity integration with Bidding and Auction services will be published separately.

Higher payload driving factors

ProtectedAudienceInput payload sizes can be large due to the following reasons:

  • ads in interest groups that includes renderUrl(s) and ad metadata
  • adComponents in interest groups
  • userBiddingSignals in interest groups
  • browserSignals generated by the browser that are required for generateBid()

Options for payload optimization

Following are the proposals to optimize compressed ProtectedAudienceInput for DSPs and buyers.

ba-payload-optimization

The above diagram illustrates the data flow when adRenderIds are sent to Bidding and Auction services using browserSignals and interestGroups instead of ad objects.

Optimizing size of ads using ad render ids

Summary: DSPs / buyers should generate a short bytestring up to 8 characters long (or 12 characters when Base64 encoded) that can serve as an identifier for an ad in an interestGroup. This will be passed to the client (browser / Android) when interestGroups are fetched. The client will send adRenderId(s) in interestGroup(s) (instead of ad objects) in ProtectedAudienceInput to Bidding and Auction services. Bidding and Auction services will pass adRenderId(s) in interestGroup(s) to generateBid() that execute in Bidding service. Note that no ads object will be passed in interestGroup(s) to generateBid().

Step 1

Buyer generates an identifier for each ad.

  • Generate an adRenderId, such as an ID for ad render url.

  • For component ads, similarly generate render identifiers.

  • It is recommended that ad render id (or ad component render id) be a string of length 8 bytes or less. If the string is Base64 encoded, it should be within 12 bytes.

Note: The ad render id (or ad component render id) size limit is open for feedback from ad techs.

Step 2:

Buyer passes adRenderId information to the client during interest group fetch.

Buyer can pass the following information to an interestGroup when clients fetch interest groups from buyers' servers.

  • An optional adRenderId field will be available in the ads object in interest group object.

    • _ Note: The field must be populated by buyers who want to generate bids in TEE based Bidding service. Turtledove design proposal is updated with details about this step._

  • An additional field (enum) will be available in interest groups that can help ad techs tell the client how to send the adRenderId to the Bidding and Auction service. Refer to step 3 for details.

    • Note: This enum will be supported by browser by September 2023. The Chrome integration design proposal and Turtledove design proposal will be updated with more details about this step.

Step 3:

Client sends adRenderId(s) to the Bidding and Auction service.

Clients will provide a field (enum) in interest group to help ad techs provide their preference between the following two options. Option 1 is supported by Chrome and Android. Option 2 will be supported by September 2023.

Option 1:

Client sends adRenderId(s) (instead of ad objects) in an InterestGroup.

  • The client would send adRenderId(s) (and ad component render ids) instead of ad objects in an interestGroup.

  • The client sends ad render ids instead of ad objects in prevWins of browserSignals in an interestGroup.

  • The remaining data is passed by the client as described in an interestGroup.

Pros: The winning render URL is validated on the client so that they belong to the interestGroup that the client has information about. In this case, the winning render URLs would always pass validation on the client. Ad techs don't need to ensure that the client is always in sync with their servers or devise a way to generate render URLs that pass validation on the client deterministically.

Cons: The payload size will be higher compared to Option 2. Buyers opting for Option 1 may be able to send lesser interest groups within the per-buyer payload size limit as compared to Option 2.

Option 2:

Client (browser, Android) doesn't send ad render ids in interestGroups. Browser sends ad render ids only in prevWins of browserSignals..

  • The client doesn't send any adRenderId in an interestGroup. Some ad techs can select this option to further optimize their payloads.

    • Note: In this case, the client will also not send any ad information to Bidding and Auction services.

  • The browser sends ad render ids instead of ad objects in prevWins of browserSignals in an InterestGroup. Note, this is not relevant to Android since prevWins are not sent in AndroidSignals.

Pros: Smaller ProtectedAudienceInput payloads.

Cons: The URL of the winning ad candidate sent to the client is validated such that they belong to the interest group that the client has information about. With this option, the URL may fail validation if the device goes out of sync with interestGroups in adtech servers.

Mitigation

Ad techs must use adRenderId(s) in interestGroup and information in trustedBiddingSignals to dynamically generate ad render urls for bids in GenerateBid().

One idea that can ensure that the winning ad candidate always passes validation on the client may be versioning interest group data. The version of the interestGroup data can be passed to the client when the client fetches interest groups; then client would pass the version of interest groups for each buyer in BuyerInput of ProtectedAudienceInput. Bidding and Auction services can pass the version when fetching trustedBiddingSignals from buyer's Key/Value server.

This mitigation is up for discussion and not supported yet. If an adtech is interested in this mitigation, Google Privacy Sandbox (clients, Bidding and Auction services) can support it.

Specification for browser signal

Browser signals are sent to Bidding and Auction services by the browser. This information is not relevant for Android app advertising.

Refer below for the spec of browser signal for bidding required for generateBid() for Protected Audience API for web advertising. The only difference here is that instead of an ad object, an ad render id is passed in prevWins. Also refer to BrowserSignals message in B&A API.

{ 'topWindowHostname': 'www.example-publisher.com',
  'seller': 'https://www.example-ssp.com',
  'topLevelSeller': 'https://www.another-ssp.com',
  'joinCount': 5,
  'bidCount': 24,
  'recency': 1684134092,
  'prevWins': [[time1, adRenderId1],[time2, adRenderId2],...],
  'wasmHelper': ... /* a WebAssembly.Module object based on interest group's biddingWasmHelperURL */
  'dataVersion': 1, /* Data-Version value from the trusted bidding signals server's response(s) if available */
}

Note: An ad object includes an ad render url and ad metadata. To ensure the request payload size is kept small, these are not sent from the client to the Bidding and Auction services.

Step 4:

generateBid() can ingest the adRenderId(s) in interestGroup(s) and browserSignals.

Bidding and Auction services would pass adRenderId and ad component render ids to generateBid().

  • The Bidding and Auction service passes ad render ids and ad component render ids in interestGroup to generateBid() if that information is received from the client in Step 3.

    • If ad render id (or ad component render ids) information is not available, no ad information is passed to generateBid(). This is valid if the buyer selects Option 2 in Step 3.

  • generateBid() must be updated so that it can ingest ad render ids (or ad component render ids) in the interestGroup field.

  • generateBid() needs to be updated so that it can ingest ad render id in prevWins in browserSignals.

    • This is not relevant for Android app advertising.

  • The trusted bidding signals fetched from the buyer's Key / Value service must include ad render id and ad metadata information.

  • generateBid() must recreate the ad render urls for final bids.

    • generateBid() can maintain a URL template with the base URL. The variable part of the URL must be recreated using the information in interestGroup and trustedBiddingSignal arguments.

    • When a buyer selects Option 2 in Step 3, ad render ids are not available in the interestGroup argument of generateBid(). In this case, the buyer generates the URL dynamically based on the information available in trustedBiddingSignal`. Refer to mitigation section that proposes an idea to ensure URL passes validation on the client deterministically with Option 2.

Optimization of user bidding signals

If a buyer doesn't depend on user bidding signals, they can skip this section.

Summary: If an ad tech requires user bidding signals, they can use trusted bidding signal keys to lookup user bidding signals from Key / Value services.

This is optional for alpha testing, but recommended for further optimization.

Pros: Smaller ProtectedAudienceInput payload.

Cons: Ad techs may require additional trusted bidding signal keys so that user bidding signals can be fetched from buyer's key/value server.

Steps:

  • Ad techs can append additional trusted bidding signal keys so that user bidding signals can be made available in trustedBiddingSignals. This can help reduce ProtectedAudienceInput payload further.

  • During the alpha phase, clients pass the user bidding signals in InterestGroup if that information is available / required by a buyer.

Higher priority interest groups sent from the device

Summary: Prioritize interest groups sent from the device.

Chrome allows buyers to set a priority value (floating point number) per interest group, however this is optional for buyers today.

This step is optional for alpha testing.

Pros: Fit higher priority interest groups in the per buyer limit.

Steps:

  • Buyer may set priority value per interest group when interest groups are fetched by the client.

  • The client can sort interest groups for buyers based on the priority value, and drop lower priority interest groups to meet the per-buyer payload size limit that may be set by the seller or the client.

Related material