Paapi Module: Autoconfig behavior

[lksharma]

Description

Prebid version 8.37.0 introduced new features allowing auction configurations to be independent of GPT. This version also introduced functionality to clear cached auction configurations by resetting them with null values using setConfig. However, in certain scenarios, cached auction configurations can persist, leading to duplicate impression calls, as observed in version 8.36.0. This ticket also provides additional context to issue #11102 which is pending discussions on the desired default autoconfig behaviour.

Issue Details

• In the latest version of Prebid, with fledgeForGpt.autoconfig set to true (default), cached auction configurations are reset correctly.
• However, when fledgeForGpt.autoconfig is set to false, additional API calls are required to trigger on-device auctions.
• Specifically, the publisher needs to call pbjs.setPAAPIConfigForGPT() whenever pbjs.requestBids is invoked and ensure it's called within the bidsBackHandler function.

Problem Scenario:

If the publisher neglects to call pbjs.setPAAPIConfigForGPT() for subsequent refresh calls, Prebid does not reset the previously set auction configuration, leading to potential duplicate impression calls.

Example Setup:

function initAdserver() {
    pbjs.initAdserverSet = true;
    googletag.cmd.push(function() {
        pbjs.que.push(function() {
            pbjs.setPAAPIConfigForGPT();
			...
        });
    });
}

function refreshBid() {
    pbjs.que.push(function() {
        pbjs.requestBids({
            timeout: 1000,
            bidsBackHandler: function() {
                // pbjs.setPAAPIConfigForGPT(); not called
                ...
            }
        });
    });
}

Steps to Reproduce:

• Set fledgeForGpt.autoconfig to false.
• Initiate bids with pbjs.requestBids and call pbjs.setPAAPIConfigForGPT() in the bidsBackHandler function
• For subsequent refresh calls, don't call pbjs.setPAAPIConfigForGPT()
• Observe behaviour

Potential Solution:

Previously set auction configs are reset by the logic within the slotConfigurator function, which executes when pbjs.setPAAPIConfigForGPT() is called. Automating pbjs.setPAAPIConfigForGPT() calls within setTargetingForGPTAsync() or similar functions could reduce the likelihood of configuration errors and mitigate potential duplicate impression calls.

[patmmccann]

If the publisher neglects to call pbjs.setPAAPIConfigForGPT() for subsequent refresh calls, Prebid does not reset the previously set auction configuration, leading to potential duplicate impression calls.

Another solution is we just tell pubs not to make this mistake. We could potentially warn them if they request bids on a slot thrice but only called pbjs.setPAAPIConfigForGPT() once

Thanks for flagging as relevant to #11102

[patmmccann]

@lksharma any objection to closing this and tracking on #11102 ? Or the inverse, closing that and tracking here?

[lksharma]

Let's close issue #11102 and continue discussions within this ticket since it contains most of the relevant context.

[patmmccann]

Sounds good, ty!

[patmmccann]

One thought: if we start handing auction configs to gam or another TLS before targeting is ready, marrying them together might present some challenges as we try and solve for latency

[patmmccann]

Spoke with the GAM team, a 'allAuctionConfigAreSubmitted' function might be coming to GPT. That would make marrying these more difficult if publishers plan to take advantage.

[patmmccann]

Consensus - provide this feature request with a new name and delete the autoconfig feature.
The new name could be ‘submitAuctionConfigsWithTargeting’ or something more compact

[lksharma]

Reviewing the MR, it looks like the issue of cached auction configurations has not yet been addressed. As long as pbjs.setPAAPIConfigForGPT() can be misconfigured for subsequent refresh calls, cached auction configurations remain a possibility. Is there a concern with including a call to pbjs.setPAAPIConfigForGPT() within setTargetingForGPTAsync consistently?

[patmmccann]

That's covered in #10930

[patmmccann]

@lksharma we're chatting about this and realizing we may have achieved your goals; where do we go from here?

[lksharma]

Agreed. I've also recently updated the documentation to reflect this case as well: prebid/prebid.github.io#5526. I think we are good to close this out. Thanks.