Request for indefinite timeout on GDPR wait

[Sir-Will]

Type of issue

bug/question

Description

During the first time loading the page the timeout of the consentManagement config is being triggered after the cmpuishown event. Isn't prebid supposed to wait until the tcloaded or useractioncomplete state or is this an intended result? How are we supposed to start the auction after the consent? Init prebid after tcloaded/useractioncomplete or force reload the page?

Expected results

Stop timeout after cmpuishown event.

Actual results

Timeout cancels auction although cmp loaded successfully and is awaiting user interaction.

Platform details

Prebid 4.12.0 Quantcast Choice

[Fawke]

Hi @Sir-Will,

The timeout occurs if the CMP does not respond with the consent string in the prescribed time. So, regardless of the cmpuishown event, the timer ticks till either you get a consentString or your time runs out, in which case, you'll get this error.

There are a few ways to tackle this first view - new user scenario.

• Increase the timeout. The default is 10000 ms
• Initialize prebid once you get the consentData.
• Listen to CMP events and trigger a ad refresh once consentData is available. (Calling pbjs.requestAds again.)

[Slind14]

Quick question, if prebid is being initialized once the CMP is ready, the Prebid CMP timeout feature becomes useless no?

[Fawke]

Quick question, if prebid is being initialized once the CMP is ready, the Prebid CMP timeout feature becomes useless no?

If by "CMP is ready", you mean - "The CMP has responded with the consentString", then timeout is useless, but in the case where CMP is loaded on the page, but consentString is not available, then the timeout feature is useful to block the auction for a certain time period in hope of obtaining the consent string.

[Sir-Will]

What exactly do you mean with calling pbjs.requestAds ?

This is what I ended up doing now, not sure if there is a better way without refresh.

__tcfapi('addEventListener', 2, function(tcData, success) {
    if (tcData.eventStatus === 'useractioncomplete') {
        var slotCodes = tagSlots
            .map( function(slot) { return slot.getSlotElementId() || ''; } )
            .filter( function(id) { return id; } );

        pbjs.que.push(function() {
            pbjs.requestBids({
                timeout: PREBID_TIMEOUT,
                adUnitCodes: slotCodes,
                bidsBackHandler: function() {
                    pbjs.setTargetingForGPTAsync(slotCodes);
                    googletag.pubads().refresh(tagSlots);
                }
            });
        });
    }
});

[Fawke]

@Sir-Will, Your setup should work fine, basically, this will make the timeout feature (the one you configure with consentMananement module) useless as @Slind14 pointed out since you should ideally have the consentString by the time you call pbjs.requestBids.

Don't worry about pbjs.requestAds, I meant to write pbjs.requestBids, which you're already doing.

[benjaminclot]

Like Google, I believe Prebid should have the option to wait indefinitely if a CMP is detected (i.e. replies to the AddEventListener function).

[Fawke]

@benjaminclot You can imitate - to some extent - "waiting indefinitely behaviour" by setting a very high gdpr.timeout value, the default is currently 10s.

I can see certain advantages of having the option to block auction indefinitely, especially in the "New user - First page load" scenarios, but incorporating this change may require some major code change. Do you have any other use case in mind where this might be useful and setting a very hight gdpr.timeout value may not work?

@jsnellbaker @bretg - Let me know what you guys think...

[Slind14]

In cases where the CMP did not load at all, which is probably the intention behind the timeout.

[benjaminclot]

@Fawke My point of view is that in a GDPR world, if the CMP doesn't load, the consent cannot be retrieved, thus no ad provider can work and no ad can be shown (empty consent = no consent). Provided that the stub is loaded early on (which it should), Prebid knows if there is a CMP or not, and if there is one, it can wait indefinitely for the consent, because it is event-based. This seems to be Google's stance too and I think it is a reasonable one. You can't possibly know how much time someone will spend on the CMP screen and the goal here is to emit bids (or not) as soon as a consent has been expressed.

[bretg]

If consent never comes and defaultGdprScope=true and Purpose 2 is being enforced, then no auctions will happen. So we're good there, right?

Our operating assumption is that every page should have a "failsafe" timeout which causes the page to stop waiting for header bidding and just call for ads directly. Once the failsafe timeout fires, anything Prebid does is pointless. Waiting for a chance to bid at that point isn't worthwhile.

If a publisher wants to handle the scenario where a user takes 20 seconds to read and answer the consent and then still get both header bidding and ads they can orchestrate the page:

• update the failsafe timeout to 21 seconds
• update the gdpr.timeout to 20 seconds. Prebid will initiate the auction in the case where the user responds positively

Setting the timeout to anything longer than a minute is probably not worth much revenue. They're not likely to ever respond on that page.

That said, I don't care deeply either way. if the Publisher Taskforce tells us they want an indefinite wait option, we'll build it. Or if someone in the community wants to take matters into their own hands, go for it. If timeout=0, then assume indefinite.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gglas]

Adding @ChrisHuie -- after discussing today, we think a default behavior change would be relatively far reaching with potentially unintended consequences for current publisher implementations. Since the functionality can essentially be achieved via the example above, we'd like to focus on enhancing documentation as opposed to a core change. @ChrisHuie will address.

[ChrisHuie]

closing with #7244 submitted