Support for submitting fledge auction configs before GPT is ready

[patmmccann]

From #10477: Both Prebid.js and GPT scripts are asynchronous. We load them in parallel to speed up time when ads are displayed. Thanks to this approach it's more likely that user won't leave the page until ads are displayed. In addition Active View metric should be better.

I will try to describe this process. Let's assume that we need for example 2 seconds for loading GPT script and only 1 second to load Prebid.js script. Additionally we set for example 0.8 seconds as a timeout for Prebid standard auctions (in fact this is timeout for bidders to respond).

Our current approach
We start Prebid auction immediately without waiting for GPT script to load so we can start fetching ads from Google Ad Manager after 2 seconds - exactly the moment when GPT script is loaded because in this example Prebid needs only 1.8 seconds to do its job.

Your approach
You need to wait for GPT script to be fully loaded before running Prebid auction (I don't mean Protected Audience API auction but ordinary Prebid auction) because publisher are not able to define any slot before full GPT API is available (defineSlot function is not defined before that moment). So ads can be fetched after 2.8 seconds even though Prebid script was loaded after 1 second.

Solution
There are two ways to resolve issue mentioned above:

1. You would need to set auction config on GPT slot inside googletag.cmd.push(callback). This would change your code into asynchronous call - as callback has to be used. As far as I know it's not possible to do it in this specific fragment of Prebid code.
2. You provide some function with all Protected Audience API auctions configuration so publisher may set auction config on desired GPT slots by oneself. Furthermore such function could be used also with with different ad servers. So you don't need to implement many different Prebid modules for every ad server which code would be almost exactly the same - the only difference would be using certain ad server SDK to set configuration of its internal Protected Audience API component auction.

Originally posted by @skoklowski in #10477 (comment)

[patmmccann]

Committee is favoring the second option and looking for additional feedback or consensus.

cc: @JoelPM and @skoklowski

[patmmccann]

We discussed further in committee, marking ready for dev

[jdwieland8282]

Notes from the Identity PMC's 12/6 mtg regarding this topic.

Option 1 - Prebid creates a “fledge for other adserver” module we should move ahead with this gptUtils.js 
DM:puts constraints on what new adservers can do. 
If this is hrs worth of work why not do it?



Option 2 - Fledge for pubs not wanting to use GAM, adx is not able to participate as a component seller. 
Prebid providers top level config so anyone can run the Fledge auction
JC: only logical approach
Who hosts the attestation file? Pub or prebid.org 

Option 3 - Fledge for pubs (invoked by pubs) who want to continue using GAM. 
Prebid runs top level seller, this means no adx demand, but DV360 demand is still available. 
Ankur, this is the most immediate need

Problem: for option 2 & 3 to work the Publisher must sign the attestation and host file, 
for option 1 the ad server should host the attestation (maybe..)

Adx will not participate in a component auction not invoked by GAM. AdWords is 7 out 8 PAA $s. 
Adwords tethering demand to Adx and GAM is problematic

**What are the cost and benefits to doing each option, from the publisher perspective, from prebids perspective?**

Demand availability by option..

Prebid.org should / should not host attestation 

The committee decided to move forward with option 2. Moving forward on option 2 requires attestation files.

[rdgordon-index]

Both Prebid.js and GPT scripts are asynchronous.
While testing PBJS + fledgeForGPT + GAM integrations, I stumbled upon an apparent race condition -- it's noted #10477 (comment) as well -- the setConfig call never be attempted if the GPT slot isn't ready yet -- and then I see the following in the console logs:

WARNING: fledgeForGpt unable to register component auction config for /<network-ID>/test-adunit-code

The offending line is the module is at

Prebid.js/modules/fledgeForGpt.js

Line 49 in 2493f98

if (gptSlot && gptSlot.setConfig) {

-- and in fact the description captures the problem:

You would need to set auction config on GPT slot inside googletag.cmd.push(callback)

And that's indeed the gap here with the module as it's written today.

[patmmccann]

tagging @laurb9 for visibility

[dgirardi]

Proposal:

• split fledgeForGpt into two modules: a base paapi module, and a slimmer fledgeForGpt that auto-includes the base module (in a similar way to how including an ID provider also brings in the base ID module)
• 'paapi' contains most of the existing logic, and provides a new API method pbjs.getPAAPIAuctionConfigs with an interface that mirrors pbjs.getAdserverTargeting
• fledgeForGpt only contains the GPT-specific slot configuration logic, and provides a new pbjs.setPAAPIAuctionConfigsForGPT mirroring pbjs.setTargetingForGPTAsync;
• a new config flag, fledgeForGpt.autoconfig, defaulting to true, decides whether fledgeForGpt should attempt to automatically set slot config, the way it does now
• in prebid 9 the default switches to false

We could also:

• update the current autoconfig logic to detect whether GPT is loaded, and if it isn't, queue up the slot config in googletag.cmd. This would allow some setups that run GPT and Prebid in parallel to work without setting the new flag / calling the new method. (the page would still need to be set up so that the GPT slot definitions are queued before the prebid auction).

[rdgordon-index]

It would indeed be preferable to have the autoconfig logic be as smart as possible so that only the most advanced publisher setups require additional work.

Along those lines -- given that the most async setups are already leveraging setTargetingForGPTAsync -- is there any way we can "somehow" use that function to also call the new setPAAPIAuctionConfigsForGPT -- since, by definition, you'd need to both whenever 'GPTAsync" is in play?

The goal IMO is to make it "just work" out of the box -- even if that means a few more configuration options via setConfig -- but we're definitely looking to make it as easy as possible -- and since there's already a setConfig block required, it would be trivial to add another parameter there; that's quite different than finding all places where you set async targeting and update all of those with the new async PAAPI auction config function call.

Thoughts?