-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browser-side auction, resource management #79
Comments
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. |
My understanding of the preliminary score idea was that invoking |
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! |
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? |
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:
|
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:
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
The text was updated successfully, but these errors were encountered: