You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following Prebid's introduction of prebid/Prebid.js#11730, there have been a few discussions buried in various threads about how a seller should indicate which interest group origins (i.e. buyers) are eligible to participate in a given PAAPI auction when using promises in auctionConfig setups. Since interestGroupBuyerscannot be delivered as a promise, sellers are required to include a superset of all possible buyer origins when the PAAPI auction begins, and then use the resolve promises to further limit them.
However, it's not clear how to best achieve this. There have been a few suggestions regarding the use of sellerSignals, adjusting timeouts, or tweaking desirability scores.
From my testing, a timeout value of 0 results in a worklet error -- prebid/Prebid.js#11730 (comment) -- which would skew all sorts of real-time API buyer metrics -- since, after all, there was no such error.
In a similar fashion, a value of 1 would just yield a timeout -- prebid/Prebid.js#11730 (comment) -- which also provides misleading timeout metrics, since this has little to do with what buyer's execution.
Tweaking desirability is technically an option, via sellerSignals in the contextual response, but that would require very wasteful on-device work regarding the calculation of bids by generateBid() and scoreAd() -- include costly KV calls to seller -- just for it be thrown away, which could be known earlier in the workflow. In addition, we'd need to design a way to isolate these kinds of 'undesirable' bids from the usual ones.
In summary, none of these seem optional -- can the Chrome team comment on these findings, and how we should proceed with leveraging parallel IG auctions without these undesirable side effects?
The text was updated successfully, but these errors were encountered:
Following Prebid's introduction of prebid/Prebid.js#11730, there have been a few discussions buried in various threads about how a seller should indicate which interest group origins (i.e. buyers) are eligible to participate in a given PAAPI auction when using promises in
auctionConfig
setups. SinceinterestGroupBuyers
cannot be delivered as a promise, sellers are required to include a superset of all possible buyer origins when the PAAPI auction begins, and then use the resolve promises to further limit them.However, it's not clear how to best achieve this. There have been a few suggestions regarding the use of
sellerSignals
, adjusting timeouts, or tweaking desirability scores.From my testing, a timeout value of
0
results in a worklet error -- prebid/Prebid.js#11730 (comment) -- which would skew all sorts of real-time API buyer metrics -- since, after all, there was no such error.In a similar fashion, a value of
1
would just yield a timeout -- prebid/Prebid.js#11730 (comment) -- which also provides misleading timeout metrics, since this has little to do with what buyer's execution.Tweaking desirability is technically an option, via
sellerSignals
in the contextual response, but that would require very wasteful on-device work regarding the calculation of bids bygenerateBid()
andscoreAd()
-- include costly KV calls to seller -- just for it be thrown away, which could be known earlier in the workflow. In addition, we'd need to design a way to isolate these kinds of 'undesirable' bids from the usual ones.In summary, none of these seem optional -- can the Chrome team comment on these findings, and how we should proceed with leveraging parallel IG auctions without these undesirable side effects?
The text was updated successfully, but these errors were encountered: