-
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
PAAPI: parallel contextual and IG auctions #12205
Conversation
Tread carefully! This PR adds 2 linter errors (possibly disabled through directives):
|
Tread carefully! This PR adds 1 linter error (possibly disabled through directives):
|
cc: @wsusrasp would love to consider your adapter as an early candidate for parallel support |
buildPAAPIConfigs: function(bidRequests) { | ||
const origin = getOrigin(); | ||
return bidRequests | ||
.filter(req => req.ortb2Imp?.ext?.ae) | ||
.map(bid => ({ | ||
bidId: bid.bidId, | ||
config: { | ||
seller: origin, | ||
decisionLogicURL: `${getBaseUrl()}/paapi/v1/ssp/decision-logic.js?origin=${bid.params.site}`, | ||
interestGroupBuyers: [origin], | ||
perBuyerMultiBidLimits: { | ||
[origin]: 100 | ||
}, | ||
perBuyerCurrencies: { | ||
[origin]: 'USD' | ||
} | ||
} | ||
})) | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zapo this "freezes" part of the auction configs into the adapter, meaning that updates would need a code change to be deployed, to enable parallel (faster) IG auctions. I got the values by looking at what your endpoint returns - but I don't know if they're universal (and I don't know if your endpoint respects the ae
flag like I do here).
auctionSignals
is still picked up from the endpoint through interpretResponse
(as would a few other signals that I don't see populated in your case), but everything in here must be provided synchronously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dgirardi Looks good, yes they are universal for now. The endpoint does respect ae
but only when set at top level (initial proposal) imp.ext.ae
, I need to fix it to also look for imp.ext.igs.ae
.
config: { | ||
seller: origin, | ||
decisionLogicURL: `${getBaseUrl()}/paapi/v1/ssp/decision-logic.js?origin=${bid.params.site}`, | ||
interestGroupBuyers: [origin], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any consideration to have the PAAPI
configs be dynamically configured, possibly from storing into localstorage from a previous auction result. I'm thinking about origins specifically but could be other things we might want to be dynamic. As a SSP the buyer origin is not a hardcoded value as we have multiple buyers depending on context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any consideration to have the PAAPI configs be dynamically configured, possibly from storing into localstorage from a previous auction result.
The interface should be general enough to allow this from an adapter. If it becomes a common pattern we can consider extracting it to a shared library - right now I don't know how that would look like (I expect SSP will still want to get in the first auction, which requires hardcoded buyers).
As a SSP the buyer origin is not a hardcoded value as we have multiple buyers depending on context.
Yes, and IMO this will quickly devolve into every prebid bundle containing every buyer that exists - but alas we decided that's what we want.
@dgirardi If an adapter chooses not to implement |
@jefftmahoney if a pub sets parallel: true, adapters that do not provide |
That makes sense. And if a publisher does not use the flag but still runs PAAPI auctions, existing setups would still work? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I have all the knowledge to fully review this PR but it looks good to me
I'm concerned about this part effectively not being backwards compatible for bidders. Basically it excludes you from the PAAPI auction if you do not provide |
I cannot see a way to make paapi configs that don't have some way of determining interest group buyers available to the parallel paapi auction, bidders will have several choices in how to do this, with hard coded values, publisher configuration, endpoint responses feeling like a natural ordering of priority from low to high. I don't see that as a compatibility issue so much as a new feature for bidders to support, and bidders may need to make certain choices about how to participate |
Only if the pub enables parallel auctions ( * |
Type of change
Description of change
Adapters can provide a
spec.buildPAAPIConfigs(validBidRequests, bidderRequest)
to be included in PAAPI auctions that can be started in parallel to contextual auctions.If PAAPI is enabled, and an adapter provides
buildPAAPIConfigs
, it is invoked just beforebuildRequests
, and takes the same arguments. It should return an array of PAAPI configuration objects with the same format as ininterpretResponse
({bidId, config?, igb?}
).Everything returned by
buildPAAPIConfigs
is treated in the same way as if it was returned byinterpretResponse
- except for signals that can be provided asynchronously (cfr.ASYNC_SIGNALS
), which are replaced by promises. When the (contextual) auction ends, the promises are resolved.If during the auction the adapter's
interpretResponse
returned matching configurations (samebidId
, and aconfig
with the sameseller
, or anigb
with the sameorigin
), the promises resolve to their contents. Otherwise, they resolve to the values provided bybuildPAAPIConfigs
, or an empty object if no value was provided.Promisified auction configs are available from
getPAAPIConfig
immediately afterrequestBids
. If thepaapi.parallel
config flag is set, PAAPI submodules are also triggered at the same time (instead of when the auction ends). Currently this is only relevant withtopLevelPAAPI
, where it has the effect of starting PAAPI auctions at the time ofrequestBids
. The same could be done for GAM/paapiForGpt
as soon as we have a method to trigger its PAAPI auctions separately from targeting/slot refreshes.Other information
Closes #11730