Discrepancy in interstitial ad rendering and analytics reporting

[nirav777]

Background

We are encountering a discrepancy between Prebid bidders and Google Ad Manager (GAM) regarding impression counts for interstitial ad units. The analytics adapter is registering the ad unit as rendered before actual user display.

Below are impression tracking pixels -

1. GAM: Impression pixel triggered by Google Ad Manager.
2. Analytics Adapter: Pixel fired using bidWon event listener.
3. DSP Pixels: Fired from ad code when creative is loaded on the publisher’s page.

Prebid suggestions

We implemented prebid's suggested solution to tackle the impression discrepancy issue.
We utilized deferBilling: true to delay the adRenderSucceeded event and subsequently triggered it using pbjs.triggerBilling() when GPT's impressionViewable event was fired.

Observations

1. Bid Expiration: Occurs when adRenderSucceeded is delayed excessively during interstitial ad loading.
2. Analytics Adapter Fix: Utilizing Prebid's defer solution solves some differences but does not fully address the discrepancy with DSP-recorded impressions. DSP pixels won't match that of GAM's recorded pixels and Analytics recorded pixels.

Proposed Solution

• Modify the logic within PUC to await the complete loading of interstitial ad code before firing DSP pixels. Similar to this #10594

sequenceDiagram
    participant Prebid
    participant GAM
    participant PUC
    Prebid ->> GAM: pick line item
    GAM ->> PUC: call PUC
    PUC ->> Prebid: drop PUC on page
    PUC ->> PUC: delay if interstitial ad
    PUC ->> Prebid: Post message to Prebid script
    Prebid ->> Prebid: getAd()
    Prebid ->> Prebid: renderAd()

Loading

Environment Details

Prebid.js Version: 10.7.0
Browser: Chrome

[dgirardi]

#10594 should already do what you suggest; bids marked with deferBilling are (by default) not rendered until triggerBilling(); the creative code and any pixels within it should not run until then. I'm not sure from your description if you are reporting this as not working.

Could you clarify what is happening at the wrong time? If your analytics "is registering the ad unit as rendered" before the adRenderSucceeded event it sounds like a bug in the analytics (which adapter is it?)

[dqureshiumar]

Hi @dgirardi,

Even when an ad unit is marked with defer billing, the bidWonEvent in the analytics adapter is still triggered. Likewise, if a DSP has winning pixels embedded in the ad code, those pixels fire immediately when the GAM creative is rendered on the page.

It does not wait for the Ad to be in view. GAM records the impression only when the ad is in view.

It’s important to note that marking an ad unit with defer rendering only delays the ad render succeeded event, along with the firing of SSP billing URLs. Other events, such as bidWonEvent or DSP’s inline pixels, are not affected by this setting and will still trigger right away.

[dgirardi]

It’s important to note that marking an ad unit with defer rendering only delays the ad render succeeded event, along with the firing of SSP billing URLs. Other events, such as bidWonEvent or DSP’s inline pixels, are not affected by this setting and will still trigger right away.

the adRenderSucceeded event happens together with rendering and therefore together with pixels within the creative. Delaying one should necessarily delay the others. bidWon does happen earlier (when the bid wins), and it's possible that will cause discrepancies if the receiver doesn't make a distinction between winning and rendering, but I'm not seeing how you can get inline pixels firing before adRenderSucceeded. Are you able to provide steps to reproduce?

[dqureshiumar]

Steps to reproduce:

1. Test Page: https://jsfiddle.net/evoh3nrq/
2. Provider a analytics adapter
3. Render a sample ad containing any image pixel

You will see Bid Won Event getting triggered even before the ad was visible. The Adcode having any pixels will also be fired

[dgirardi]

You will see Bid Won Event getting triggered even before the ad was visible

This is intended behavior; the bid has won after all, even if it's rendered later or not at all. We can add an option to delay this event as well.

The Adcode having any pixels will also be fired

I can't reproduce this, or I don't understand what you mean by adcode. Are you sure that the pixels you see are in the ad creative?

I modified your example page to make it work, and added a console statement in the creative. You can see it running only after triggering the interstitital: https://jsfiddle.net/hm0uagtf/

[nirav777]

Regarding the interstitial defer rendering flow. It might be beneficial to delay the bidWon event until pbjs.triggerBilling is executed as analytics adapter listen to this event before firing their Winning Bid Pixel.

Additionally, I'm curious about the best approach to handle bid expiry scenarios when the adRenderSucceeded event is delayed for a significant amount of time. If there's a delay in rendering, how do you suggest we manage the potential expiration of bids to ensure that we don’t lose the opportunity to display these ads once the rendering is ready to proceed?

[dgirardi]

If there's a delay in rendering, how do you suggest we manage the potential expiration of bids to ensure that we don’t lose the opportunity to display these ads once the rendering is ready to proceed?

It appears that GPT interstitials cannot be altered after being set up, so I don't think you can do much about expired bids currently - I opened #13838 to discuss this.

It might be beneficial to delay the bidWon event

The concern is that some systems are actually interested in the winning bid, not the rendered one, and delaying would penalize them for doing the "right" thing. For example a floor provider is interested in the winning price even if it's never rendered. Likewise, a winning bid that fails to render for whatever reason - even if not an interstitial - would not trigger DSP pixels and also cause discrepancies if counted using bidWon.

It is however the case that many adapters are currently not making any distinction between winning and rendering. IMO we should either push everyone to start doing so, or provide some way to fill the gap.

[lcorrigall]

PMC:

• Changing when the events fire is a breaking change
• We shouldn’t be specifying a billing event in Prebid, but track each actual event (bidWon, start-to-render, rendered, in-view, etc.) and let the publisher decide when the billable event happens
• Might need to allow pubs to adjust the billable event based on the buyer
• For Prebid 11, push bid adapters to listen to the correct events and introduce breaking changes