-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Remove BID_TARGETING_SET as criteria for a "used bid" #4148
Comments
Looking at the risk of rendering the same bid twice, can we add a logic to use a bid in one auction only at a given time, maybe something like |
That is basically the same thing that |
Mostly after getting the bids from Prebid, a publisher would call the guaranteed server (say GAM). |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Bad practice but seen quite often in production on publisher sites. Personally, I have seen as bad as 30sec refreshes / re-running of the auction. It would be nice to see support for observables so AJAX requests could be terminated. That or something like others suggested using |
pretty sure this is good to close, as it is now changed to rendered |
Closing because changed to render #6020 |
Type of issue
I2I.
Description
Currently we mark bids as used if they are rendered or set in an auction (
BID_TARGETING_SET
). This means that we will not be able to use a bid (aka, via bid caching) if it is not ultimately rendered in the 1st auction. code linkThis makes bid caching somewhat ineffective in most cases when bid caching is enabled.
We will therefore remove the criteria of
BID_TARGETING_SET
from a used bid and the bid will only be marked as used if it has been rendered.Risks:
There is a slight risk of sending the same bid to the ad server multiple times if subsequent ad server calls are made repeatedly in a short period of time (such that the 1st ad call did not have time to renderer before the next ad call is made).
Since this is a bad practice (to rapidly refresh ads) we think the risk is worth the tradeoff.
Open for comments.
The text was updated successfully, but these errors were encountered: