Prebid.js: Separate size mappings per adUnit cannot be represented using sizeConfig

[chrissjhitc]

Type of issue

Question

Description

We’re switching over our old size mapping code to use sizeConfig but have hit a problem with the implementation. DFP size mappings and the 0.x Prebid size mappings are per adUnit but the sizeConfig rules are global to the page.

We have two types of leaderboard slot that allow billboards at different page widths. Each slot has a separate sizeMapping for DFP and both can appear on the same page at once. With sizeConfig rules it seems it isn’t possible to set up different behaviour for each slot; if you remove the billboard size from one then it gets removed from all of them.

Would the mediaType.banner.sizes need to be manually updated in cases where we can have multiple size mappings on a single page? Or is there a solution using sizeConfig?

Platform details

Prebid 1.16.0

[bretg]

@chrissjhitc - please provide an example.

There's nothing stopping you from having two leaderboard AdUnits with different page widths. e.g.

pbjs.setConfig({
  sizeConfig: [{
       mediaQuery: '(min-width: 1200px)',
       sizesSupported: [[970,90], [728,90], [300,250], [160,600]],
       labels: [ "display"]
     }, {
       mediaQuery: '(min-width: 768px) and (max-width: 1199px)',
       sizesSupported: [[728,90], [468,60], [300,250], [160,600]],
       labels: [ "tablet"]
     }, {
       mediaQuery: '(min-width: 0px) and (max-width: 767px)',
       sizesSupported: [[300,50],[320,50],[120,20],[168,28]],
       labels: [ "phone"]
  }]
});

And then in the LeaderBoard AdUnits, you can define both as being relevant for multiple screen widths:

var AdUnits = [{
    code: "leaderboard-slot-1",
    mediaTypes: {
        banner: {
           sizes: [[728,90]]
         }
    },
    labelAny: [ 'desktop', 'tablet'], 
    bids: [  ...   ]
},{
    code: "leaderboard-slot-2",
    mediaTypes: {
        banner: {
           sizes: [[728,90]]
         }
    },
    labelAny: [ 'desktop', 'tablet'], 
    bids: [  ...   ]
}
];

If you haven't already seen it, the examples in http://prebid.org/dev-docs/conditional-ad-units.html may help to illustrate some of the potential uses of the feature.

[chrissjhitc]

Thanks @bretg ,

It's probably an unusual use case, we have two leaderboard adUnits on the same page with different window width breakpoints. I can't see it covered in any of the examples.

Under the Prebid 0.x sizeMapping you could set the breakpoint to 980px and 1200px independently for each adUnit via adUnit.sizeMapping. But in Prebid 1 the sizeConfig is a global set of rules that apply to all adUnits.

We have tried using multiple rules with labels like below, but we always enable the 970x250 at the same window width for both adUnits. We don't think the two separate breakpoints can be represented in the sizeConfig.

pbjs.setConfig({
  sizeConfig: [{
       mediaQuery: '(min-width: 1200px)',
       sizesSupported: [[970,250],[728,90],[300,250],[160,600]],
       labels: [ "leaderboard2-desktop"]
     }, {
       mediaQuery: '(min-width: 980px)',
       sizesSupported: [[970,250],[728,90],[300,250],[160,600]],
       labels: [ "leaderboard1-desktop"]
     }, {
       mediaQuery: '(min-width: 768px) and (max-width: 1199px)',
       sizesSupported: [[728,90],[300,250],[160,600]],
       labels: [ "leaderboard2-tablet"]
     }, {
       mediaQuery: '(min-width: 768px) and (max-width: 979px)',
       sizesSupported: [[728,90],[300,250],[160,600]],
       labels: [ "leaderboard1-tablet"]
     }
     ...
  }]
});

We've been working around it by tracking the window width ourselves and only adding [970,250] to each of the adUnit banner sizes when the appropriate window width has been achieved. I think we're going to have to keep on doing that unless the mediaQuery breakpoints and sizesSupported can be set independently per adUnit.

[patrick-mcdougle]

One other thing to note here is that there's currently no way to just limit a size when a media query is matched. Ideally the api for this would be really similar to the way that DFP does it. Here's our use case:

We have two slots on the page, a leaderboard on the top and an ad in the sidebar. The leaderboard is some IAB standard sizes: 970x250, 728x90, 970x90. These sizes are always eligible and we do not want to filter these in any way. We also have a sidebar ad that has 300x250 and 300x600. On small viewports (smaller than 900) we no longer want the 300x600 to be eligible.

Here's my two configs, irrelevant fields omitted:

// Size Config
pbjs.setConfig({
  sizeConfig: [{
    "mediaQuery":"(min-width: 0px) and (min-height: 900px)",
    "sizesSupported":[[300,250],[300,600],[160,600]],
    "labels":["upper_rec-normal"]
  },{
    "mediaQuery":"(min-width: 0px) and (min-height: 0px)",
    "sizesSupported":[[300,250]],
    "labels":["upper_rec-short"]
  }]
});

// Ad Units
pbjs.addAdUnits([{
    "code":"leaderboard-0",
    "bids": [omitted],
    "sizes":[[728,90],[970,90],[970,250]]
},{
    "code":"upper_rec-0",
    "bids":[omitted],
    "sizes":[[300,250],[300,600],[160,600]],
    "labelAny":["upper_rec-short","upper_rec-normal"]
}]);

I thought this would work since leaderboard does NOT have any label conditionals, and hence it would not be excluded by filtering, but that is not the case. The behavior of the upper rec ad is correct, but when this sizeConfig is provided, the leaderboard ad gets filtered out. Is this a bug?

I think the only way I can get my leaderboard to not be filtered out, is by adding all the leaderboard sizes to the second size config and labeling it upper_rec-short. (which is kinda gross).

Any advice here?

For now, I'm probably going to do the same thing as OP and just do the media query and size filtering myself before passing to prebid. This is painful to use as currently implemented.

[bretg]

In both of your cases I think there's a way to solve. But first, some observations:

1) sizeConfig is global -- across all adunits. Only one mediaQuery wins.

2) The idea is that the labels in sizeConfig defines a device type, not an adunit. You could define "desktop-wide" and "desktop-narrow".

3) Worth noting that sizesSupported is meant to be the entire list of sizes that's relevant for the whole page. The sizes actually used for the auction are the _intersection_ of AdUnits[].sizes and sizesSupported.

Is this a bad design, or just different from DFP? It's bad if we can't find a way to represent your use cases, so let's see if we can get there. If we can't get to a solution, we can implement an adunit-specific sizeConfig.

@chrissjhitc in your case, the example doesn't fully make sense to me, but one solution could be to define the "breakpoints" with labels in a global way. This sizeConfig sets up a definition where there are 4 different device configurations for different sizes:

pbjs.setConfig({
  sizeConfig: [{
       mediaQuery: '(min-width: 1200px)',
       sizesSupported: [[970,250],[728,90],[300,250],[160,600],[...]],
           // if specified, this needs to be the entire list of sizes supported on the 'desktop-wide' configuration
       labels: [ "desktop-wide"]
     }, {
       mediaQuery: '(min-width: 980px) and (max-width: 1199px)',
       sizesSupported: [[970,250],[728,90],[300,250],[160,600],[...]],
       labels: [ "desktop-narrow"]
     }, {
       mediaQuery: '(min-width: 768px) and (max-width: 979px)',
       sizesSupported: [[728,90],[300,250],[160,600],[...]],
       labels: [ "tablet-wide"]
     }, {
       mediaQuery: '(min-width: 700px) and (max-width: 767px)',
       sizesSupported: [[728,90],[300,250],[160,600],[...]],
       labels: [ "tablet-narrow"]
     }
     ...
  }]
});

Then you apply these labels to adunits:

pbjs.addAdUnits([{
    "code":"leaderboard1-desktop",
    "mediaTypes": { "banner": { "sizes": [size list] } },
    "bids": [omitted],
    "labelAny":["desktop-wide", "desktop-narrow"]  // this adunit shows up in two scenarios
},{
    "code":"leaderboard2-desktop",
    "mediaTypes": { "banner": { "sizes": [size list] } },
    "bids":[omitted],
    "labelAny":["desktop-wide"] // this adunit appears only in the desktop-wide scenario
},{
    "code":"leaderboard1-tablet",
    "mediaTypes": { "banner": { "sizes": [size list] } },
    "bids":[omitted],
    "labelAny":["tablet-wide"] // this adunit appears only in the desktop-wide scenario
},{
    "code":"leaderboard2-tablet",
    "mediaTypes": { "banner": { "sizes": [size list] } },
    "bids":[omitted],
    "labelAny":["tablet-wide", "tablet-narrow"] // this adunit appears only in both tablet scenarios
}]);

@patrick-mcdougle - your scenario is a little easier... just need to define the sizes available in the two screen configurations and the rest happens automatically.

// Size Config
pbjs.setConfig({
  sizeConfig: [{
    "mediaQuery":"(min-width: 0px) and (min-height: 901px)",
    "sizesSupported": [[970,250], [728,90], [970,90], [300,250], [300,600]],
    "labels":["tall-viewport"] // label not needed, but helps focus on device config rather than adunit
  },{
    "mediaQuery":"(min-width: 0px) and (min-height: 900px)",
    "sizesSupported": [[970,250], [728,90], [970,90], [300,250]],  // note 300x600 is gone
    "labels":["small-viewport"]
  }]
});

// Ad Units
pbjs.addAdUnits([{
    "code":"leaderboard-0",
    "bids": [omitted],
    "mediaTypes": { "banner": { "sizes": [[728,90],[970,90],[970,250]] } },
},{
    "code":"upper_rec-0",
    "bids":[omitted],
        "mediaTypes": { "banner": { "sizes": [[300,250],[300,600],[160,600]] } },
        // 300x600 will be suppressed automatically in the 'small-viewport' scenario
        // labels not needed
}]);

So in both cases, I think it's a philosophy difference that is causing the difficulty -- both scenarios were trying to use sizeConfig per AdUnit, rather than:
1) setting up a global device configuration, defining sizes and labels that apply to each configuration
2) defining all possible AdUnits
3) making the AdUnits configurable based on the device label

Does this help? If so, will make some updates to the prebid.org documentation.

Any other feedback from community members welcome.

[patrick-mcdougle]

@bretg I think that certainly gets our use case to work, but it seems overly verbose, considering that the ad units themselves have sizes on them. Ideally there'd be a solution where the ad units could set their own sizes and then be filtered by the size config. I think it might be better if ad units without labels are excluded from the size filtering process which is how I thought it worked based on the documentation...

If a label conditional (e.g. labelAny) doesn’t exist on an ad unit, it is automatically included in all requests for bids.
http://prebid.org/dev-docs/publisher-api-reference.html#setConfig-Configure-Responsive-Ads

I took that to mean that by leaving a label off of an ad unit, meant that it would not use the sizeConfig for filtering, but it doesn't mean that, you still MUST include those sizes in a size config.

One other small point: If more than one size config matches, I think it takes the UNION of the sizes, not the INTERSECTION (see sizeMapping.js:76). This is probably something else the docs should clarify.

[chrissjhitc]

Thanks @bretg.

I think our issue does come down solely to the rules for Prebid being global. I wouldn't say its a bad design, it just means they are less flexible than the per ad unit DFP size mappings. We've been dealing with a few implementations from various third parties lately, and some of them use the DFP size mappings in a too complicated a way to represent with a global ruleset.

On a single page view on the same device we would have wanted an ad unit that followed the desktop-narrow media query and another that followed the desktop-wide media query instead. It's probably easiest to picture the use of this on a desktop machine - if you slowly drag the window wider one position on the page could have the space available to start showing a larger advert before the other does.

Some of the sites we've taken on have used DFP size mappings quite liberally in this way - configuring multiple types of leaderboard mappings to squeeze the largest possible adverts into various positions on the page, often the same page. When the prebid size mappings were per ad unit we could always duplicate the DFP behaviour regardless of the complexity involved.

Our solution is to allow the 970x250 in the media query as soon as it is valid for either slot, then use our own page width tests and a resize event to manage the sizes on each ad unit independently. The only real drawback occurs if the window is resized past one of our own breakpoints - we have to completely rebuild the ad unit to update the sizes, meaning we lose all unexpired bids from the previous auction when some of them may have still been valid.

[bretg]

Thanks for explaining your perspectives on this Chris and Patrick. Handing this over to @mkendall07 to consider revising the feature.

My take is that the current feature works acceptably, but would be easier for complex use cases to adopt a more DFP-like approach rather than requiring the integrator to re-think the mappings at a global level.

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

[redemption]

Actually, after reading through the examples some more, I think the below can be achieved using labelAny: ["phone"], on one unit and labelAny: ["tablet","desktop"], on the other unit.

---

Hi @bretg - some great examples of how to work around the global sizeConfig setting.

I wonder if you can apply your workaround concept to a slightly different scenario:

Say you have a responsive design where there's a 300x250 either in the right column or a different 300x250 in the main column depending on desktop vs mobile layouts (respectively).

So in a desktop, only Ad_300x250_1 displays
In a mobile device, only Ad_300x250_2 displays.

In GPT this can be set using sizeMapping like this:

var mapping_300_desktop = googletag.sizeMapping().
addSize([0, 0], []). // doesn't show in mobile
addSize([750, 100], [300, 250]). // Desktop
build();

var mapping_300_mobile = googletag.sizeMapping().
addSize([0, 0], []). //
addSize([310, 100], [300, 250]). // Tablet
addSize([758, 100], []). // Desktop
build();

Since the sizeConfig is an intersection of sizes I'm not sure how to apply the principles you listed in our usage scenario.

[pboisso]

Are there any consideration for just reading the actual DFP sizeMapping like Amazon HB solution is doing? No need to define sizes anywhere else than in our standard DFP tags, the HB config reads the details from there.

[patrick-mcdougle]

@pboisso The trouble there is that prebid can be used with any ad tagging library, not just googletag.

[mkendall07]

right that is a concern and also the fact that we load DFP and prebid concurrently, so if we were required to read the DFP params we'd need to wait for DFP to load and execute it's queue before we could start any SSP requests.