Support sizemapping for responsive ads

[prebid]

As a publisher using GPT's sizemapping feature, I'd like Prebid.js to auto detect the browser size and read from my GPT sizemapping array, so that Prebid.js can send out ad requests for different ad sizes depending on the user's browser size.

Acceptance Criteria

1. On load, Prebid.js detects the browser size.
2. Prebid.js reads an optional passed in sizemapping array for screen width>ad sizes
3. Prebid.js will use the optimal sizes in sizemapping, instead of the sizes passed in the adUnits, as the size to pass into header bidding partners.
4. Prebid.js will clean up the targeting, so that if GPT refreshes the ad call, the same header bidding ad from the previous round will not be served twice.

GPT's sizemapping feature:
https://support.google.com/dfp_premium/answer/3423562?hl=en

If user resizes the browser and GPT refreshes the ad slots with different sizes, header bidding partners cannot easily participate in that round of auction
Because GPT does not have a callback when it detects the resize of a page. Thus when GPT issues a new ad request when it detects a page resize, header bidding partners do not have time or the opportunity to run an auction.

[geoff616]

For mappings defined inside googletag.cmd like in the example here: https://support.google.com/dfp_premium/answer/4578089?hl=en the mapping variable isn't accessible from outside that function's scope.

It is possible to pull out the sizes defined inside the googletag object by iterating over: googletag.pubads().X to pull out the valid sizes for each slot, but this involves something like accessing: googletag.pubads().X[0].I.j[0].j to get the sizes for one of the slots.

Do you think we can assume the mapping will be defined as a global? If not, do you think it makes sense to pull the out of the object directly? Another option appears to be parsing the DFP log, but that is less obvious than pulling out of each slot in the googletag object.

Re numbers 1-3 above, would you prefer prebid to determine the size of the window and parse the sizes out of the mapping itself, or just copy what DFP has determined are valid sizes inside the googletag object? The latter appears to be simpler to implement, have less risk of getting out of sync with DFP, and would be more straight forward in cases where there are multiple size mapping arrays applying to different kinds of slots on the same page (i.e. one size mapping for 2 leaderboards and another size mapping for 2 sidebars).

[nickjacob]

the 2nd option would be awesome. Found this API which I think will work -- when you call getSizes() it checks the sizemapping against (what looks like) the window, so it's the eligible sizes

I was using one of the obsfucated property paths in another project & it changed when google recompiled GPT, but hopefully this one is a real (just undocumented) api --

slot.getSizes()

[7LayersDesign]

getSizes() is what we have been using for our responsive slot size checks. We also got burned by a GPT recompile when using the GPT object keys. I really wish Google would update GPT. Last I checked the getSizes() is undocumented, but we have not had issues with it failing. Would be nice if they would at least update the docs so we know what is safe or not.

[mkendall07]

Thanks for the idea @geoff616 & @nickjacob unfortunately the way we integrate with GPT is after the auction takes place so we need to know the sizes up front. In order to use slot.getSizes() we need to wait for GPT to load before calling the bidders. If there is another way or this can be done without waiting for GPT I'd be interested in learning more.

[prebid]

We're working on this ticket this week and should have the proposed solution out in the ticket description in 2 weeks.

[mjwhaley]

@mkendall07 Has there been any update on this subject?

I have pushed live a client with a responsive website and we are now seeing some winning ad's delivering into the wrong size ad sizes. Most ad units have multiple sizes and we are using sizemappling to deliver different sizes based on the users screen size. I'm assuming the wrong size adverts and size mapping are linked.

[BartVB]

There seems to be a mostly functional version with responsive sizes in git. We are also waiting for this to stabilise. In the meantime we use something like this:

var BrowserWidth = window.innerWidth && document.documentElement.clientWidth ? Math.min(window.innerWidth, document.documentElement.clientWidth) : window.innerWidth || document.documentElement.clientWidth || document.getElementsByTagName('body')[0].clientWidth;

pbjs.que.push(function(){
    var adUnits = [
        {
        code: 'div-gpt-ad-firstpost',
          sizes: (BrowserWidth > 740) ? [728, 90] : [300, 250],
          bids: [
            {
                bidder: 'appnexus',
                params: {
                    placementId: (BrowserWidth > 740) ? '1234' : '5678'
                }

Works well enough for the time being.

[mkendall07]

We are currently working on a solution for this. You can see the work in progress here:
https://github.com/prebid/Prebid.js/tree/gpt_sizemapping

Example usage : https://github.com/prebid/Prebid.js/blob/gpt_sizemapping/integrationExamples/gpt/gpt_sizemapping.html#L130

Any feedback on this solution is welcome. I expect we will merge it in early January once we are confident it's working as expected.

[mjwhaley]

@mkendall07 @BartVB Do you both think this issue is causing the wrong size ad frame to load around an say larger ad?
I'm currently passing multiple bid offers on the same ad unit to the same SSP as below. Each offer is for a different size with the same ad unit. Is there a way to pass the size with it in an effort to stop the above issue happening.

            bidder: 'appnexus',
            params: {
                placementId: '*******'
            }
        },{
            bidder: 'appnexus',
            params: {
                placementId: '********'
            }
        },{
            bidder: 'appnexus',
            params: {
                placementId: '********'
            }

[mkendall07]

@mjwhaley any sizes you define into a adUnit are assumed to be "safe" to be delivered there. If you are auto sizing based on screen resolution you need to request only those sizes that would fit into the adjusted size. It sounds like this feature will resolve it for you.

[mjwhaley]

@mkendall07 Thanks. I will have a look at the solution above. The part i'm find strange is that I'm offering out a 970x250, 970x90 and 300x250 (via the same AdUnit) and the winning bid is a 970x250, but DFP then sizes the window to a 300x250 and then delivers the advert.

[mkendall07]

You may need another line item with the correct size that matches to the 'hb_size' param. I'm not a DFP expert so I could be wrong.

[mjwhaley]

@mkendall07 I've been working on this issue for quite few days now and have even setup additional line items in DFP targeting only, but with no luck sorting it.
I have come across something though.
I have set the script up with multiple AppNexus calls per ad unit as below, to hopefully get different bids per adsize.

//UNIT 1
code: 'ad-leader-lg',
sizes: [[970, 90], [728, 90]],
bids: [{
//970x90
bidder: 'appnexus',
params: {
placementId: '',
referrer: '**',
alt_referrer: '**'
}
},{
bidder: 'rubicon',
params: {
rp_account: '**',
rp_site: '**',
rp_zonesize: '**'
}
},{
bidder: 'aol',
params: {
placement: '**',
sizeId: '**',
alias: '**'
}
},{
//728x90
bidder: 'appnexus',
params: {
placementId: '**',
referrer: '**',
alt_referrer: '**'
}
},{
bidder: 'rubicon',
params: {
rp_account: '**',
rp_site: '**',
rp_zonesize: '**'
}
},{
bidder: 'aol',
params: {
placement: '**',
sizeId: '***',
alias: '*******'
}
}]
},{

But what seems to be happening is the adapter takes the placementId and then adds the sizes of [970, 90], [728, 90] from the beginning on the ad unit setup. So in my example above its offering the placement twice for each size instead of once per size, as i was expecting it to work.

Is this assumption correct?

[chaqu170]

@mkendall07 - I was wondering what happened to this URL?

https://github.com/prebid/Prebid.js/tree/gpt_sizemapping

[jorgepinon]

Has any progress been made on this request? I just noticed this is the oldest open issue.

I'm setting up prebid with DFP and would like to know how prebid can honor gpt's sizeMapping.

[minsider]

Agreed with @jorgepinon, any status update?

I found this #108, not sure if this has fully been integrated and tested.

[mkendall07]

No progress on this unfortunately. We will review PRs for this feature but it's not a priority to build at the moment.

[dmsinger]

I'm working on my own work-around for the moment. I have to imagine most sites are responsive in some form nowadays. Subscribing to this. Would love to know when it kicks off, and if I learn anything along the way I can add, even better.
(translation: please do this, and if I can help after doing something like it myself, I will)

[minsider]

Why was it closed?

[James328]

Agreed with @jorgepinon @minsider @dmsinger, would be nice to have this functionality. So far it seems like custom JS workarounds are required at the moment

[mkendall07]

I've added a PR for this feature here #651

[natanavra]

@nickjacob response was very helpful for me
This seems to work well, for those of you who don't have access or a list of the size mapping and need it to work out of the box

the 2nd option would be awesome. Found this API which I think will work -- when you call getSizes() it checks the sizemapping against (what looks like) the window, so it's the eligible sizes

I was using one of the obsfucated property paths in another project & it changed when google recompiled GPT, but hopefully this one is a real (just undocumented) api --

slot.getSizes()