Integration of mobile web interstitial ad with prebid

[tandalevaibhav]

Can someone please help me to get an example of how I can use mobile web interstitial ad with prebid. https://developers.google.com/doubleclick-gpt/samples/display-web-interstitial-ad

[tandalevaibhav]

I found some suggestions just to pass size 1x1 for this but I am confused about how I can generate code for the prebid ad unit.

[bozghiyy]

I do not have an answer or solution for this, but I looked into it and I can share the challenges I found, if anyone is interested in this, maybe will find them useful.

1. Cannot set targeting by code (Div ID). The GPT adunit definition doesn't have a code: googletag.defineOutOfPageSlot('PUB AD UNIT PATH HERE', googletag.enums.OutOfPageFormat.INTERSTITIAL).addService(googletag.pubads()); Of course, GPT generates a Div ID for it, but not being able to set one custom in the adunit definition will make it hard for most of people implementing it. You can set the targeting by adunit, or there are ways around it. (if you know the adunit name, you will know the div id generated by GPT)

2. The interstitial is an iframe and the creative in a nested iframe. This means that the Prebid Universal Creative will need to "jump" two iframes to get to the prebid global object. A solution here is to use window.top instead of window.parent for render function, but for us (we are managing a variety of sites with different implementation) this is not a proper solution across the board. There are implementation when prebid's global object is not within window.top. I guess window.parent.parent will work, but I think the PUC needs to know when to call this and when to call window.parent.

Same things apply to cross domain creatives (if using safe frames), with window.parent.postMessage.

I think there are solutions, but not without changes to both prebid.js and PUC and I cannot say what would the best flow here. (maybe adding a new mediaType). For us the investigation stopped here, since seems that there is a lot of work ahead and if the header bidding demand partners will see this inventory as standard banner, what is the benefit of implementing it. Google's demand is 2-3X over the standard banner, so HB demand partners will not have a chance competing with standard banners here.

[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]

Discussed in Issue review today, any other publishers with experience implementing please feel free to chime in, otherwise we'll prioritize this in the product backlog with other work.

[patmmccann]

re: @bretg 's comment: "what is the benefit of implementing it. Google's demand is 2-3X over the standard banner, so HB demand partners will not have a chance competing with standard banners"

-Programmatic Direct is an immediate application, even with minimal or zero open market wins.

[bszekely1]

There is a bit of work involved to support it. Magnite has identified all the key areas to update should we move forward with it. Since this is new demand, i would say this is a new avenue to see if there is additional demand to open up. Also, header bidding demand at it's very core is not just competing in the ad server but also filling demand when there is none.

[patmmccann]

I believe magnite's list is longer than necessary and includes some 'nice to haves'. For example, the list says there is nowhere to put the instl flag in the current ad unit config. I think this is mistaken and the flag is already supported in the ortb2 object setConfig instead of requiring special work. Also publishers could flag this unit for deals using existing workflows and expect to receive plenty of demand even if open market demand were weak.

[bszekely1]

Given the openRTB2 object, yes, the list of items can be shortened some.

• We would need some documentation around the instl flag
• Communicate to bid adapters to ingest it
• Set the GAM flag

I suspect we would not need to make any changes for the S2S adapter, but this should be tested.

[bszekely1]

I created a PR document describing the ortb2 object behavior for the adUnit imp object here: https://github.com/prebid/prebid.github.io/pull/2851

We can review on the pbjs PMC call.

[jackmasterson]

We’re working on serving an interstitial with Prebid demand in a SafeFrame, and it seems like it can be done without too much code. There are still issues we’re working through but it seems like a good time to knowledge-share. There are three places changes need to occur:

1. In secureCreative.js in the resizeRemoteCreative function, we identify when it is an interstitial unit and resize the element to 100vh and 100vw (taking care of the background behind the interstitial modal).

We currently rely on checking for a Slot ID that contains ‘Interstitial’, which we know will exist in our request. However, to have a more universal approach we could add a flag to the bid when the adUnit contains an “instl: 1 flag” in it’s FPD. As suggested here)

2. In our GAM creative similar to integrationExamples/gpt/x-domain/creative.html, we postMessage to the window.parent.parent when it’s an interstitial unit (again, currently relying on custom targeting we set, but we should be able to find a universal solution)

3. Also in our GAM creative, just before this functionality, we check to see if there is an iframe already in the SafeFrame, which is the case when the Interstitial is served. We then resize that iframe to fit the ad dimensions, which is the iframe of the modal that opens in the interstitial, containing the close button that exists in a GAM-only interstitial, using the following: var interstitialIframe = window.parent.document.body.querySelector('iframe'); if (interstitialIframe) { interstitialIframe.style.height = winningBid.height + 'px'; interstitialIframe.style.width = winningBid.width + 'px'; }

The inner-iframe mentioned in step 3 always has the id #ad_iframe, but grabbing it by that selector seemed riskier since that could be arbitrarily changed at any time.

Feedback is welcome on the above, as are any suggestions on a more universal approach to flag a bid as intended for an interstitial unit. One idea is to set hb_format to “Interstitial” when ‘instl’ is included in the request. Then from the creative check the bid’s adserverTargeting for that hb_format key to match.

[bretg]

Why can't we just solve this problem in the script that calls the PUC? Rather than the PUC itself. e.g.

<script src = "https://cdn.jsdelivr.net/npm/prebid-universal-creative@latest/dist/creative.js"></script>
<script>
  var ucTagData = {};
  ucTagData.adServerDomain = "";
  ucTagData.pubUrl = "%%PATTERN:url%%";
  ucTagData.targetingMap = %%PATTERN:TARGETINGMAP%%;
  ucTagData.hbPb = "%%PATTERN:hb_pb%%";

// Need someone to work out this code so we can post it on docs.prebid.org
// SIZE="%%hb_size%%" or "%%hb_size_BIDDER%%"
// WIDTH=parse size to get first field
// HEIGHT=parse size to get secon field
// this script can get it's parent iframe
// iframe.style.width=WIDTH+"px"
// iframe.style.height=HEIGHT+"px"

  try {
    ucTag.renderAd(document, ucTagData);
  } catch (e) {
    console.log(e);
  }
</script>

[danielguedesb]

I tested @bretg's suggestion it solves the issue where the iframe isn't resized when using GPT managed OutOfPage slots:

<script src = "https://cdn.jsdelivr.net/npm/prebid-universal-creative@latest/dist/creative.js"></script>
<script>
  var ucTagData = {};
  ucTagData.adServerDomain = "";
  ucTagData.pubUrl = "%%PATTERN:url%%";
  ucTagData.targetingMap = %%PATTERN:TARGETINGMAP%%;
  ucTagData.hbPb = "%%PATTERN:hb_pb%%";

  var size = "%%PATTERN:hb_size%%";
  if (size && document.defaultView && document.defaultView.frameElement) {
    var sizes = size.split('x');
    if (sizes && sizes.length === 2) {
      document.defaultView.frameElement.style.width = sizes[0] + "px";
      document.defaultView.frameElement.style.height = sizes[1] + "px";
    }
  }

  try {
    ucTag.renderAd(document, ucTagData);
  } catch (e) {
    console.log(e);
  }
</script>

[bretg]

@tandalevaibhav , @jackmasterson , @bozghiyy - I realize we've been slow on this one, but better late than never? Please take a look at the suggestion above and see if the approach could meet your use cases. Thanks.

[patmmccann]

9640 should make this possible, as the blocker was gam was firing the markup regardless of if it showed the unit

We need this path to get adopted by any ssp before we build?