Introduction

GenerateBid is set to return a single candidate ad and bid for each IG. With the introduction B&A serving, k-anonymity checks, this limitation could become problematic.
We propose to return more than one candidate ad per IG from GenerateBid and have those candidates scored in scoreAd.

Limitations of current approach

In the current api spec, generateBid returns a single candidate per IG while the scoring of the other ads in the IG is discarded (link). The information discarded could be instead used to optimize some of the follow up computation in FLEDGE.

1: K-anonymity - on device

The k-anonymity enforcement prescribes that if a non k-anonymous ad wins the auction, we need to run a second auction with only k anonymous ads.
By returning more than one ad per generate bid, the k-anonymity second auction could skip the generate bid part and only keep those ads that are k-anonymous.
Related concerns have been raised in github issue 592, and this proposal addresses the issue of “auction rewind” for k-anon.

2: K-anonymity - B&A

The same applies to the B&A implementation. By allowing more than one render url to be returned by the generateBid, it is possible to avoid repeating computation to get a k anonymous ad.

3: Coverage loss

Limiting 1 ad per IG to participate in the auction, we are penalizing IGs with a large number of ads vs smaller IGs. The scenario could be a user with 2 IGs: one large (call it IG1) and 1 small IG (IG2). After generateBid, the AD1 and AD2 respectively go to SSP and AD1 is rejected. AD2 serves. It is likely that in this case IG1 could have a few ads in “reserve” that are more valuable than AD2 but never get considerate for auction.
This mechanism could steer DSPs towards IG proliferation to get more ads in the auction.

Proposed changes

1: Return 2+ (or all) ad candidates per IG

We propose for generateBid to return a priority-ordered list of ads to be considered for the auction, potentially returning all ads it validated and scored.
On device, each of the ads will have a known k-anon status while on B&A the k-anon status needs to be queried.

A subset of these ads then run in SSP scoreAd. The first ad and the first k-anonymous ad in the list need to be passed to scoreAd per IG. If the first ad in the list is k-anonymous then only one ad needs to be passed to scoreAd to reproduce the current k-anonymity auctions. However, we propose passing additional ads to scoreAd to address the coverage loss from large IGs.

2: Establish a cap for ads

It is possible that the total number of ads generated per owner is too large to be handled by SSP/k-anon servers so the runAdAuction could impose some restrictions on the number of ads that can participate in the server side auction.

One possible solution is to have a cap for each IG owner on the sorted list of ads (by bid). As a result the most valuable ads will be considered in the SSP score ad.

This limit could be specified in auctionConfig.

3: Auction rewind

If a non k-anon ad wins the auction, it is a matter of choosing the first ad in the sell side auction that is k-anon as a winner.

Summary of asks:

1. Make generate bid return more than one ad per IG
2. Run more than one ad per IG in SSP score ad
3. Reuse the already computed ads to enforce k-anonymity