Multi-seller auction support with Protected Audience Mediation

Note: This article reflects the Privacy Sandbox on Android's current design proposals and is subject to further change. We encourage your feedback and comments to assist in these efforts.

Sell-side ad platforms typically diversify their ad demand sources to optimize for ad revenue. With ad mediation, an ad network or service invokes multiple ad networks to determine the best ad for a given ad slot. This proposal introduces how the Protected Audience API on Android can be extended to implement waterfall mediation functionality in a privacy-preserving way. Today, ad networks provide various ways for app developers to mediate ad auctions from multiple ad sellers:

1. Waterfall mediation: App developers define an ordered list of ad networks, often ranked by historical eCPMs for the given network. This list is known as a mediation chain. The app developer's mediation platform uses this list to call ad networks in the order they are listed to determine relevant ad demand sources.
2. Programmatic mediation: Multiple ad networks are configured by the app developer to participate in bidding for ad opportunities. These networks are allowed to bid in real-time based on how they value the opportunity.
3. Hybrid mediation: A combination of waterfall and programmatic mediation techniques.

Waterfall mediation

In waterfall mediation, when an ad opportunity arises, an ad SDK sends a request to its backend server. Instead of responding to the request with a winning ad creative, the server responds with a mediation chain that contains a list of ad networks ordered by historical eCPM.

Figure 1. The waterfall mediation model.

In the traditional waterfall model, an ads SDK calls each ad network (or its own auction SDK) in the order specified by the mediation chain. If an ad network can fulfill the ad request, the ad network renders the ad. If not, the request is sent to the next network in the chain. This process is repeated until the request is fulfilled or the chain is exhausted.

Waterfall mediation is often optimized by regularly reordering the mediation chain based on the re-evaluation of eCPM from first-party ad demand sources.

Programmatic mediation

Programmatic mediation (also known as "header bidding") is an alternative to using historical eCPM to determine which ad network gets the chance to serve an ad request. With programmatic mediation, providers instead use live bid values to find the winning ad.

Figure 2: The programmatic mediation model

Hybrid mediation

Some programmatic mediation solutions combine ad networks in a hybrid mode of waterfall and bidding to provide more control to the ad while getting the benefit of using live eCPMs to maximize revenue from participating ad networks.

In hybrid mediation models, ad networks and mediation providers can provide increased flexibility to app developers by combining elements of waterfall and real-time bidding. Hybrid models allow app developers to configure ad networks based on historical eCPMs, giving them the opportunity to show an ad before running real-time bidding with participating networks to fill ad opportunities.

Protected Audience waterfall mediation

Protected Audience API on Android supports waterfall mediation by having multiple auctions, each for an individual node in the mediation graph. If there is no winner from an auction, the next network auction node is called until the chain is exhausted. The waterfall mediation process is as follows:

1. The mediation SDK fetches the mediation chain from the contextual ad server endpoint, which may return either contextual ads or mediation chains.
2. If the ad server endpoint returns a mediation chain, the mediation SDK iterates through each item of the chain in order, invoking the participating ad network's SDK to run a contextual and remarketing ad selection. Each item in the chain represents an ad network's request to purchase ad space for a specific price for a specific amount of impressions, clicks or ad time.
3. If none of the line items in the chain pick a winning ad, the mediation SDK may choose to show an ad from its own ad network by running a Protected Audience ad selection that considers both remarketing and contextual ads.

Figure 3. Waterfall mediation with the Protected Audience API.

The preceding diagram represents an example of a waterfall mediation algorithm that a mediation SDK can implement, but without the ability for the first-party ad network to optimize. The Protected Audience API supports first-party ad network optimization by allowing chaining of ad selection workflows and reporting winning impressions.

AdSelection outcome

The return type of selectAds() is an AdSelectionOutcome object. AdSelectionOutcome contains the render URI of the winning ad and an AdSelectionId, which is an opaque integer that identifies the winning line item's ad creative.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

Note: Access to the render URI is ephemeral and ceases to work after fenced frames rendering for AdSelection winners is enabled.

AdSelectionId acts like a pointer to the AdSelectionOutcome. Today, AdSelectionId is passed into the reportResult() method as the ReportImpressionInput parameter to help identify the correct ads that the reportWin() and reportResult() methods are invoked upon.

Chain ad selections proposal

We propose to overload selectAds() with AdSelectionFromOutcomesConfig.

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

This allows the mediation SDK to compare its winner ad's bid to the next-inline network's bid floor.

Example 1:

• 
• 
• 
• 
• 
• 

Example 2:

• 
• 
• 
• 
• 

Note: The return value of this selectAds(AdSelectionFromOutcomes) call is another AdSelectionOutcome object. A value of null is returned in case there is no ad selected. An AdSelectionOutcome with the same ad selection ID is returned in case the mediation SDK's ad's bid is greater than the bid floor of the next network.

Report winning impressions

If there is a winner from selectAds(AdSelectionFromOutcomes) then that ad wins the mediation. Then reportImpression is called with the ad selection ID of the winning ad from selectAds(AdSelectionFromOutcomes) and the corresponding AdSelectionConfig.

If the winner is returned from a selectAds(AdSelectionConfig) for any of the networks, then reportImpression is called with the ad selection ID and config from that call.

Run waterfall mediation

Here is the order of operations for running through the waterfall mediation process.

1. Run 1st party ad selection.
2. Iterate over the mediation chain. For each 3rd party network, do the following:
   1. Build AdSelectionFromOutcomeConfig, including the 1st party outcomeId and the 3rd party SDK's bid floor
   2. Call selectAds() with the config from the previous step.
   3. If the result is not empty, return the ad.
   4. Call the current SDK network adapter's selectAds() method. If the result is not empty, return the ad.
3. If no winner is found from the chain, return the 1st party ad.

Best practices

Run contextual auctions before first-party optimization

Remarketing demand can generate high bids that can yield winning outcomes in a mediation chain. Truncation is a process that is often used to enable first-party optimization by refining the remarketing audience list.

The Protected Audience API's remarketing demand is only available client-side with Protected Audience auctions. This can make it challenging to enable first-party optimization on the server side. To mitigate issues with first-party optimization, run the contextual auction first, and then perform first-party optimization based on the winning ad result as described earlier on this page.

Keep your on-device mediation chains small

For optimal performance, on-device mediation chains should be kept small. The compute cost for on-device execution may be linear at the number of auctions evaluated as part of the mediation chain. In other words, more nodes leads to more computational cycle requirements and increased latency. Consider the impact of latency on revenue when you pass nodes to on-device mediation evaluation.

Additional considerations

The Protected Audience API doesn't offer a comprehensive solution for mediation of multiple ad slots. Each ad slot must be processed independently.

The Protected Audience Mediation API supports waterfall mediation and limited programmatic mediation. More details on supporting additional programmatic mediation use cases will be shared in the future.

Since Protected Audience ad selection runs after contextual ads are fetched, invoking the Protected Audience API may impact the end-to-end latency of ad requests.