prebid
Fledge/PAAPI: Support for additional bids/negative targeting
Type of issue
Question
Description
Currently, through the FledgeForGpt module, Prebid allows returning a tuple {bids, auctionConfigs}, and if we understand correctly, contextual bids simply serve as bid floors for the on-device auction.
The Fledge team is developing an alternative scenario (already available in Chrome Dev) where contextual bids become part of the on-device auction, enabling a range of improvements such as the ability to implement capping for contextual bids and negative targeting.
Do you plan to support this new feature within Prebid.js? We assume that the feature is quite transparent for you as it involves setting fields at the auctionConfig level, but at the same time, we believe that coordination with GPT and supervision of feasibility is necessary on your part.
Thank you in advance
Other information
https://github.com/WICG/turtledove/issues/260 https://github.com/WICG/turtledove/issues/739 https://github.com/WICG/turtledove/issues/319
it involves setting fields at the auctionConfig level
As I understand it, the only missing piece is allowing bid adapters to set the adAuctionHeaders fetch option - assuming that additional bids can be provided for component auctions. (If they can't, it all depends on what is/will be possible through GPT).
Most of the real work is going to be on the SSPs - packaging their bids into the fledge headers and setting up their auctionConfigs to accept them with the appropriate auction nonce / interest group buyers.
coordination with GPT is quite difficult; what do you propose we coordinate with them.
As I understand it, the only missing piece is allowing bid adapters to set the
adAuctionHeadersfetch option
It seems correct; you are assuming that additional bids are returned (via headers) directly in response to the prebid request. In that case, the adapters will need to set, once the response is obtained, the additionalBids field of the auctionConfig with an immediately resolved promise (to notify that additional bids are available), something like
const {auctionConfigs} = serverResponse.body;
const auctionConfigsWithAdditionalBids = auctionConfigs.map(auctionConfig => auctionConfig.additionalBids = Promise.resolve());
you are assuming that additional bids are returned (via headers) directly in response to the prebid request
That is my assumption, but as I understand the proposal it's also the only way to return additional bids:
Additional bids are not provided through the auction config passed to runAdAuction(), but rather through the response headers of a Fetch request, as described below in section 6.3 HTTP Response Headers.
DV360 is interested in testing addtitional bids / negative targeting feature with SSPs. Are there still changes needed to be done on prebid.js side to enable that flow?
Hi there, want to quickly bump up this issue as DV360 want to test this with SSP. We'd like to follow up on this feature request.
As requested by @patmmccann here, here's a document shared by DV360 => [External] PA API (a.k.a. FLEDGE) Additional Bids with Negative Interest Group Targeting.pdf
#12542 just errors on insecure use of the header, is that really all that was needed for support of the header? If so, can we add a short blurb describing how one may access it?
Furthermore, the doc shared by DV3 also requires passing the nonce from the sellers to the buyers via OpenRTB -- which, in turn, suggests that this needs to be created by the paapi module and included 'alongside' ae=1 by the paapi module... cf. https://github.com/WICG/turtledove/blob/main/FLEDGE.md#61-auction-and-bid-nonces
Along the same lines, this requires knowledge of both the seller origin (not a problem, known server-side), but also the top-level seller origin, which isn't available today at the time that the fetch() call is made. So that's another aspect we'll need to address.
but also the top-level seller origin, which isn't available today at the time that the fetch() call is made. So that's another aspect we'll need to address.
On the weekly WICG calls, it was noted that if there's an issue regarding top-level-seller implementation, we should bring it to Chrome's attention to see if they can help close this gap.
@rdgordon-index Can you provide more details on the top level seller issue?
https://github.com/WICG/turtledove/blob/main/FLEDGE.md#6-additional-bids indicates that
The ...
topLevelSellerfields are used to prevent replay of this additional bid.
Additional bids don't have a corresponding call to
generateBid(), and so thesellerandtopLevelSellerfields in an additional bid are intended to allow for the same acknowledgement as those inbrowserSignals.
Also documented as such in the spec - https://wicg.github.io/turtledove/#additional-bids-section.
Hi Prebid team, is there update on this work item? DV360 is looking forward to testing this feature with SSPs.
Note from sandbox team: each component seller generates a nonce and puts it in their config. Prebid should call const auctionNonce = navigator.createAuctionNonce(); repeatedly until it has one nonce per component seller, and include it each component seller config. This is compatible with Parallel PAAPI, as it can be in the component config submitted before communication with the seller even occurs. Creating each nonce has very low cost, perhps queue some in advance. No issues creating too many nonces other than nonce performance creation cost.
@dgirardi this is ready for dev again, we talked to the sandbox team, basically the nonce we need to pass is the component nonce and calling it auction nonce was poorly named and perhaps was named before component auctions were envisioned
In general Prebid does not know how many nonces are enough, since bid adapters can return multiple component auctions. I think our best option is to give bid adapters the ability to generate nonces (they could call the API directly already, but we could provide a wrapper) and let them deal with it.
Alternatively if we want to populate ext.abidc[0].nonce (question: why is it an array @FlorentDancy ?) we could do it for adapters that support parallel / buildPAAPIConfigs, but for the rest we'd have to decide on some speculative maximum number of expected auction configs.
When the topLevelPaapi module is in use, we can also provide ext.abidc[0].top_level_seller.
Actually,
they could call the API directly already, but we could provide a wrapper
is not quite true as the API is asynchronous and it's needed in synchronous buildRequests or buildPAAPIConfigs. So my plan would be to provide a synchronous method that generates placeholders that Prebid swaps later.
since bid adapters can return multiple component auctions But they're still 1:1 with Prebid's bidID, correct?