PAAPI: Parallel Contextual and IG auctions

[patmmccann]

Feature outline:

Bid adapters should be able to specify, as a hard coded object, an auction config with promises that will later be filled in from the igi:igs object on their bid response. The auctionConfig gets submitted immediately (before the auction commences) to the TLS (or paapi submodule representing the TLS, eg fledgeforgpt).

The interestGroupBuyers presents a wrinkle, as it cannot be a promise and could have the following logic:

Value in local storage that a bidder can set and read, falling back to publisher config list of ssp buyers, falling back to a hardcoded list in the adapter. The resulting list could then be filtered by the pub. Sellers should endeavor to list all buyers they work with. Prebid could have a constants file with all known buyers and sellers could import the constants they wish to avoid respecification of tons of long-ish strings in each adapter.

Bid responses should have an extension location the ortbConvertor can pick up for the replacement list of buyers they want to call on future auctions. Bid requests should have a new place for current known buyer list version so the endpoint can know if it wants to update the list. They should also have a new place to say: 'paapi auction style is parallel, I have already submitted an config for you, your response will be for promise filling.'

InterestGroupBuyer timeouts of buyers to exclude from the auction can be set to zero by the seller.

For example, if dsp A doesnt need a PBS object and dsp B and C do, and there is only DSP B PBS object available, the IGB timeouts would be set to {a:X, b:X, c:0} where X is some reasonable integer. Alternatively, since sellerSignals is also a promise, sellers can set desirability of whichever bids they want to zero based on the igs response, providing a second 'boot buer' opportunity.

TLS should provide an API that allows the pub to say something like 'I am done submitting paapi auction configs'. Prebid TLS module (currently for either GAM or pub designated TLS) would call this function at the same time as requestBids, with all the auction configs that were promise based.

Bidders unable to provide promise shell configs would be excluded from the parallel paapi auction.

Paapi module config should take a flag saying the publisher wants to run a parallel paapi auction. Bidders submitting auctionConfig too late should generate console warnings.

[rdgordon-index]

A few comments following our verbal discussion on Friday:

Bid adapters should be able to specify, as a hard coded object, an auction config with promises

Do you envision that the awareness of the parallel nature of a given PAAPI auction will be visible to the bid adapters at runtime?

Paapi module config should take a flag saying the publisher wants to run a parallel paapi auction.

Further to the previous comment, I'm assuming that this will be visible...

Bidders submitting auctionConfig too late should generate console warnings.

As in, a 'late biding timeout' state?

Value in local storage that a bidder can set and read, falling back to publisher config list of ssp buyers, falling back to a hardcoded list in the adapter.

This just means that sellers need to get 'ahead' of this PR so that they don't miss out on such opportunities, since all of the above require adapter changes.

The resulting list could then be filtered by the pub.

I'm concerned that this would be entirely invisible to sellers, which would make troubleshooting extremely difficult -- it's hard enough as it is to know what's going on in the on-device auction; if arbitrary buyers can disappear from an component seller's auctionConfig, it's going to near-impossible. Thoughts?

InterestGroupBuyer timeouts of buyers to exclude from the auction can be set to zero by the seller.

This also isn't the default seller configuration, since there is no existing case from a list of buyer origins to come from 'outside' a seller's auctionConfig; I suppose this can be added in a backwards-compatible way to existing exchange reponses, but that's stil a change we'd all need to make ASAP.

Bidders unable to provide promise shell configs would be excluded from the parallel paapi auction.

As per my comment earlier, that means sellers need to move quickly to be able to avoid losing PAAPI auction reach, since this is a backwards-incompatible change if adopted prematurely.

[rdgordon-index]

Thinking about this some more -- this implies that the decisionLogicURL and trustedScoringSignalURLs are static and/or known in advance -- and this isn't always the case; this will require a fundamentally different workflow for sellers.

[rdgordon-index]

InterestGroupBuyer timeouts of buyers to exclude from the auction can be set to zero by the seller.

This actually results in a worklet error, which seems undesirable

Worklet error: generateBid() aborted due to zero timeout.

[patmmccann]

InterestGroupBuyer timeouts of buyers to exclude from the auction can be set to zero by the seller.

This actually results in a worklet error, which seems undesirable

Worklet error: generateBid() aborted due to zero timeout.

Interesting, perhaps 1 then

[rdgordon-index]

Interesting, perhaps 1 then

Then you just end up with the timeout error instead....

Worklet error: https://privacysandboxdemos-buyer-1.casalemedia.com/dsp/bidding-logic.js perBuyerCumulativeTimeout exceeded during bid generation.

or

Worklet error: https://privacysandboxdemos-buyer-1.casalemedia.com/dsp/bidding-logic.js execution of "generateBid" timed out.

Depending on which timeout setting is used.

[patmmccann]

Interesting, perhaps 1 then

Then you just end up with the timeout error instead....

Worklet error: https://privacysandboxdemos-buyer-1.casalemedia.com/dsp/bidding-logic.js perBuyerCumulativeTimeout exceeded during bid generation.

or

Worklet error: https://privacysandboxdemos-buyer-1.casalemedia.com/dsp/bidding-logic.js execution of "generateBid" timed out.

Depending on which timeout setting is used.

Paul Jenssen suggested this, at WICG/turtledove#1093 (comment) perhaps we should ask him for more detail when we get the chance. Also, you could update desirability to zero to punt buyers based on sellerSignals telling you which ones to punt.

[patmmccann]

Thinking about this some more -- this implies that the decisionLogicURL and trustedScoringSignalURLs are static and/or known in advance -- and this isn't always the case; this will require a fundamentally different workflow for sellers.

Perhaps that could be solved by publisher config or anything else available at requestBids time entering the url as patterns?

[patmmccann]

Proposal: bidder can define now buildAuctionConfig method, takes the same as buildRequest parameters. Needs to specify decisionLogicURL, interestGroupBuyers, and trustedScoringSignals [if needed]. Should be an array of config for each impression in the auction.

[patmmccann]

Trickyness: s2s bidders would not have a reasonable way to do buildAuctionConfig; we'll have to think about how a publisher could supply incomplete auction config for an s2s participant

In accomodate

Four competing proposals:

1. s2s cant be in parallel paapi [strawman, we want support]
2. bidders will have to understand common parameter in the qs of decision logic url
3. s2s bidders will have to commit construction logic to paapi as a submodule of sort
4. server side bidders could return everything needed for future parallel paapi auction construction on the first auction

[JoelPM]

For PBJS I like the proposal to add a buildAuctionConfig API to the adapter. This allows the implementor to make the decision on whether they build it using config info available on page, or if they cache information from the first bid request and use that on subsequent requests.

I think we should also explore if it's feasible to make that the single API for participating in PAAPI and deprecate the current method that sends extra info from the requestBids method.

[rdgordon-index]

Paul Jenssen suggested this, at WICG/turtledove#1093 (comment) perhaps we should ask him for more detail when we get the chance. Also, you could update desirability to zero to punt buyers based on sellerSignals telling you which ones to punt.

My understanding was that the intent was to prevent any unnecessary work from happening, both in buyer and seller script runners -- but I agree that we should follow up with Paul, it's quite possible we need a tweak to the API.

Perhaps that could be solved by publisher config or anything else available at requestBids time entering the url as patterns?

I don't think that's sufficient -- or, at the very least, requires thinking about how those URLs are built, and how the associated parameters are generated, in a fundamentally different way.

[rdgordon-index]

For PBJS I like the proposal to add a buildAuctionConfig API to the adapter. This allows the implementor to make the decision on whether they build it using config info available on page, or if they cache information from the first bid request and use that on subsequent requests.

Something like that might work -- I also agree that the flexibility of the adapter to decide how to build it is crucial, since it likely won't be a one-size-fits-all.