Browser-side auction, resource management

[jonasz]

Hi,

During browser-side auction execution the computational resources will be limited, and so there will be a need for a resource management mechanism. The main bottleneck will likely be CPU time usage, but other resources should also be managed.

Some questions and thoughts that come to mind:

1. Do you envision a strict CPU usage limit per ad? Per advertiser? Per DSP?
2. What happens if there's too many ads to evaluate? It seems the browser needs to be able to decide which ads to prioritize.
3. It may be beneficial to allow DSPs to assign a "preliminary score" to ads, which could be used for such prioritization.
4. Prioritization of ads coming from different DSPs is more tricky. The prioritization should be "fair", in some sense - for instance, an advertiser/DSP that rarely wins should not be allowed to consume the majority of resources.
   Perhaps we could think of mechanisms that gamify the prioritization process between DSPs so as to optimize the final bid value (or some other metric)?

It would be great to hear your thoughts on that, even if you don't have a specific solution in mind yet.

Best regards,
Jonasz

[jonasz]

During the last FLEDGE call (2021-11-10-FLEDGE-call-minutes.md) there was a discussion about adding a per-interest-group preliminary score.

I'd like to signal that it'd be desirable to be able to adjust such a preliminary score based on certain signals, most notably: number of recent wins and interest group age.

We were wondering internally how to best achieve such an adjustment without adding too much complexity to FLEDGE. Perhaps it'd be the easiest to simply allow generateBid to overwrite the preliminary score for the interest group it's being invoked for?

This approach isn't perfect, but it's quite powerful and straightforward.

@JensenPaul, friendly ping for visibility, I'd be curious to hear your thoughts.

[jeffkaufman]

My understanding of the preliminary score idea was that invoking generateBid for all IGs could be too computationally intensive, and a score could hint to the browser how to prioritize. In which case I don't see how generateBid could be an input to the score?

[jonasz]

Hi @jeffkaufman , right, sorry for not being clear - the idea is not to introduce an additional call to generateBid - rather, to be able to overwrite the preliminary score once generateBid is running anyway.

The idea is that the preliminary score does not have to be super precise, so we don't need to update it right before an auction. However, we do need to update it from time to time at least, and a standard invocation of generateBid is a great opportunity to do so - generateBid has access to lots of relevant signals that affect the score (like IG's age and # recent wins).

A typical use case would be to make sure the preliminary score goes down as time passes and number of impressions rises. generateBid could say "I've gotten a chance to run now, and I see the IG's age is 20 days and this IG has already won 10 times, so let's set the preliminary score to something low now." Then, in the next auction, some other IG would likely have a higher preliminary score.

Let me know if that makes sense!

[jeffkaufman]

Neat idea! The main downside with this approach is that you only get the opportunity to modify the preliminary score after getting to run generateBid, which means it ends up being much easier to decrease preliminary scores than increase them. But given how you were thinking of using them that sounds like it might be fine?

[jonasz]

I think it's fair to say this approach would cover one of the major use cases.

Above that, I think it'd be great to discuss:

1. An ability to adjust the IG's preliminary score using the response from the trusted server. (Perhaps a per-IG multiplier?) This would allow us to respond to changes in the configuration of the relevant advertising campaign. (In this use case the preliminary score could be increased.)
2. How expensive it is to set up and call generateBid if it returns -1 almost immediately. It'd be great if early in generateBid we could take a look at trusted signals, contextual signals, IG signals, and say "we want to skip the calculation for this IG". For this to work well the overhead related to setting up the environment and invoking generateBid would have to be low.