FLEDGE: extend runAdAuction to support multiple ad slots

[brodrigu]

Publishers run multiple ad slots (ad spaces) on each of their pages. There are several use-cases that are impossible to solve for when each auction is run independently and no knowledge of outcome can be shared with a following auction.

For example:

• A buyer may be interested in a whole page takeover where they are the only advertiser on the page, providing their own ad/creative for each ad slot on the page.
• Publishers may need to avoid channel conflict where an ad for buyer (let's say Ford) should not be shown on the same page as an ad for another (like say, Chevrolet).

Both these use cases (and perhaps others) could be solved if runAdAuction supported one or more auctions that could provide winning ads to multiple ad slots.

[michaelkleber]

This does seem desirable, but whole-page auctions seem like they could add an awful lot of complexity. Do you have any thoughts on what the SSP and DSP on-page interactions would need to look like for this?

This certainly will not be a V1 feature.

[brodrigu]

DSPs and SSPs could provide meta-data needed to determine conflicts or dependencies.

One possible flow:

1. runAdAuction extended with ad_slots array supporting meta-data about available slots
2. Each slot gets a separate run of bidding and scoring functions
3. Independent winners chosen for each ad slot
4. all winners passed into a conflict resolution function (provided by the publisher)
   • function determines ads which cannot serve due to conflicts or missing dependencies
5. next best bid chosen for each eliminated ad (much like when a bid is eliminated due to not enough unique users)
6. repeat 3-5 up to some reasonable limit, if hit bail out and render contextual ad

runAdAuction could return an array of promises (in same order as ad_slots array) which could then be passed to each fenced frame.

[michaelkleber]

This sounds like a frighteningly large amount of business logic to leave up to the browser. The kind of flow you're talking about seems reasonable to me, but I strongly believe we would need to find a privacy-preserving way to let that logic be controlled by the auction runner, not by a spec.

[brodrigu]

That's a great idea! In fact, letting the publisher provide the full business logic for running the auction (instead of simply scoring bids) as is detailed in PARRROT would get the browser out of this business logic altogether and allow for this problem to be solved by the publisher or their technology partner(s) according to their business needs.

[Pl-Mrcy]

On a tangent point, I would like to make sure that I understand what is proposed in the current proposal as the basis of this discussion.
It is unclear to me who is implementing and running the auction, in the sense of deciding the cost of printing an ad for the winner (the ad with the highest desirability score).
​
Here is what I understood:

• the auction mechanisms would be implemented by Chrome. Thus there will be a limited number of options available (for example first-price auction; second-price auction).
• The seller can pick among these options using the auction_signals
• The buyers use generate_bid to get a bid for each eligible IG
• The seller scores each answered ad independently using score_ad
• The browser "runs" the auction: the highest desirability score (output of score_ad) is picked as winner and the cost of the ad is computed based on the list of eligible ads and their bids and the auction config picked by the seller.

Is that right?
​
If so: is there a particular reason why the full auction logic is not open for the seller (the seller would not only be responsible to score ads but to run the entire auction, including determining the cost, using an arbitrarily complex auction implementation)?

[michaelkleber]

@brodrigu If the publisher (or their agent) gets to see all the bids from all the interest groups, then they are certainly looking at a unique fingerprint for the user. If they can use this information to pick winners for all N ad slots on the page, or decide the on-device auction has no winner for that slot, then the function that knows a unique user identity just got to send N bits of data to the outside page. That means loading a single page with a bunch of ads on it is a cross-site tracking mechanism.

This is why I said "we would need to find a privacy-preserving way to let that logic be controlled by the auction runner." It's easy to satisfy your feature request if we give up on preventing tracking. I don't see a way to satisfy it that meets our privacy needs.

[michaelkleber]

@Pl-Mrcy No, this is not at all correct! Things like "first-price auction" or "second-price auction" are entirely defined and controlled by the entity running the auction — the publisher / seller / SSP.

• The buyers use generate_bid to get a bid for each eligible IG
• The seller scores each answered ad independently using score_ad
• The browser "runs" the auction: the highest desirability score (output of score_ad) is picked as winner
• The seller determines the cost, using an arbitrarily complex implementation

If the seller got to see information about all of the interest groups together when picking the winner, that would essentially be an opportunity for them to make decisions based on cross-site information about the user. Also that would let the seller use membership in owner1's interest groups to influence owner2's ad rankings. This is why FLEDGE lets score_ad only look at one bid at a time.

[brodrigu]

Thanks @michaelkleber, I see your point about the potential to leak information with N bits. Given N=1 is what we have in Fledge and N=32 is roughly enough to uniquely identify all users, it seems like maybe there is a discussion to be had about what N is acceptable. A multi-ad-slot feature could be useful where N=3 or 4 which seems to be an acceptable precision for things like Private Click Measurement.

[michaelkleber]

I don't think it's even that simple. The 3 bits for click measurement have many additional protections, including (a) they can only be learned after a person clicks on an ad, and (b) the information they reveal — this person converted on side X — is only revealed to someone who already knew the baseline information that this person visited site X, because they saw the person click on the ad link in the first place.

Even allowing the one bit to leak, as proposed in TURTLEDOVE and FLEDGE, is pretty risky, and we may need to put extra guards in place to protect from abuse. Ramping up the leakage is really the wrong way to go here.

[brodrigu]

I agree there is some trade off between functionality (which leads to publisher-> user benefits) and privacy. Perhaps your stance is 0-1 bits exposed here provides the best value. In that case the runAdAuction function could only ever return null (when no ads should win) or a list of opaque promises when a set of interest group ads have been chosen. This still exposes the same amount of information while allowing for the requested feature.

[michaelkleber]

Ah! That is a very interesting thought indeed! Is that a reasonable trade-off to make, or do pages usually run with a mixture of contextually-targeted and userlist-targeted ads? (I understand that you personally might not be in a position to answer that, of course.)

This will need some careful thinking still — presumably some interest groups would want to bid on individual slots, and some on the page as a whole ("roadblock", right?). So a mechanism where we run each individual ad slot's auction, and then have an opportunity for a whole-page auction as well, which needs to beat out the sum of the individual-slot optima, essentially?

[brodrigu]

It shouldn't matter what order we run individual and roadblock auctions in so perhaps they could be combined, with each bidding (or bid scoring) function could aware of all available slots, returning one or more bids targeted to specific slots. The browser could select the combination of slots/bids that produce the highest total bid score.

These solutions would solve for the roadblock but wouldn't solve the brand conflict use-case and we would still need a way to ensure the combination of IG ads are compatible.