-
Notifications
You must be signed in to change notification settings - Fork 760
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
Proposal: previous auction info module #3333
Comments
Discussed in committee. This is still of some interest, but not a high priority. This addresses only a "min bid to win" use case, not a "pacing improvement" use case. |
Discussed in committee: keeping this on hold until there's enough interest to push it further. |
There's a Prebid.js pull request open around this general topic -- prebid/Prebid.js#11086. So apparently there's some interest out there. I believe from pubmatic. The pull request isn't aligned with the proposal here. |
Update: there's been work on on this done for Prebid.js in prebid/Prebid.js#11086 I've requested that the community take this up and debate the details.
|
Over the years, the Prebid Server team has gotten requests to support "loss notifications" so bidders can refine their bidding algorithms. Whenever the request comes up, we decline with 3 objections:
But the issue comes up again periodically, so in the spirit of trying to move the conversation forward, here's an option for Prebid Server to offer a relatively inexpensive way to provide the info that is available. Bidders need to be willing to (A) read from a Prebid extension, (B) accept incomplete info and (C) be flexible about the timing of getting the data.
In the future PBS could also forward PBJS previous auction info in a separate object. (?)
Runs at 2 stages:
However this is efficiently implemented in the code, logically, it's just a queue for each bidder:
NoBids (seatnonbid code 0) are not added to the data structure.
That's it. Configuration of the module would define which bidders to do this for and max queue length.
To minimize mutex contention, I would propose very loose timing requirements. It would be ok for every thread to have it's own copy of the bidresponse queue, or for there to be a configurable number of queues per server that are processed round-robin. The implication is that there's absolutely no guaranteed about when the bidder would receive the additional information. e.g if there are 1000 threads in a large server and traffic is declining, the previous auction info in thread 999 might get stuck there until traffic rises the next day.
We'll need an approach to removing older auction info that hasn't yet gotten reported.
Discuss.
The text was updated successfully, but these errors were encountered: