Scoring Additional Bids Server-Side

[andrewtao2]

The Protected Audience API should allow additional bids to be scored by the seller on the server-side instead of within the Protected Audience auction.

Scoring additional bids server side would have the following benefits:

1. Lower latency for the Protected Audience auction because additional bids do not need to be scored on the client.
2. Consistent logic for scoring and filtering contextually generated bids for the seller. Currently, sellers would need to run scoring both server-side (for conventional, contextually generated bids that are not additional bids) and client-side (for additional bids).
3. Removal of the dependency of running the Protected Audience auction on the generation of contextual bids. For cases when the Protected Audience auction could be run in parallel with the generation of contextual bids, including additional bids (e.g. Bidding and Auction services), this could result in latency savings.

Currently, the Protected Audience API requires the seller to propagate the buyer’s additional bids into the Protected Audience auction, where the bids are scored and negative interest group targeting is applied. From a seller’s point of view, the scoring of the additional bids in an on-device scoreAd function seems unnecessary because the additional bids are generated using the contextual information server-side by buyers. The sellers have the information sufficient to score these bids server-side, as part of the conventional ad serving flow.

Based on the discussion in #319, additional bids were first introduced as a concept to support negative interest group targeting for contextually generated bids. But, support for negative interest group targeting should be possible without scoring the additional bids on-device. For example, the flow could look like the following for the seller:

1. The seller computes scores for the additional bids server-side, based on the information about additional bids received from buyers.
2. The seller passes additional bids along with their score and other fields specified in the PA API spec to the browser.
3. The browser will apply negative interest group targeting to additional bids, and run the Protected Audience auction to select the final winner.

Would it be possible for the Protected Audience API to be updated to support server-side scored additional bids?

[michaelkleber]

Just for clarification, it sounds like you're talking about a B&A flow, where the Additional Bids in question are something that are coming from some DSP and already passing through the SSP that's going to score them. Is that right? (When I first read this I thought you were asking for some Additional Bids to be passed from the browser up to a server for scoring, which really surprised me! But I think that's not at all what you're talking about.)

In that case, what you're observing is that the SSP handling the Additional Bids already knows enough to do the equivalent of scoreAd() without passing the bid into the PA auction at all — there is no cross-site or hidden information involved in the scoring. Indeed the SSP could already pass along the Additional Bids accompanied by their own metadata with their opinion of the score, and they could implement a trivial scoreAd() function which just copied over that pre-computed score. But that would be bad for latency in two different ways: starting up a whole execution environment just to execute a trivial piece of JS is a waste, and also you might be able to get better parallelism by starting the auction before the Additional Bids are available, if they are (very plausibly) the slowest input.

That all sounds like a quite reasonable additional feature. The implementation may prove tricky, though — these bids would need to be funneled into the on-device auction flow in a place that doesn't really exist right now, still filtered by negative targeting but not triggering a seller worklet.

In summary: No philosophical objections, but will need more thinking on the practical side.