Multi-Size Ad Slots vs. Fluid Native Sizes: Yield Analysis Across Desktop and Mobile Breakpoints

An OpenRTB 2.6 bid request carrying a single fixed w and h dimension parameter filters out up to 65% of eligible DSP seat bids compared to a request populated with a multi-size imp.banner.format object array. At the browser level, every ad slot declared in Google Publisher Tag (GPT) and Prebid.js 11.x represents a trade-off between DOM layout predictability and programmatic auction liquidity. Frontend engineering teams frequently prefer single-size placements or fluid native containers ('fluid' in GPT) because they conform cleanly to CSS Grid and Flexbox layouts without inducing unexpected container expansion. Yield and AdOps architects, conversely, configure multi-size slot definitions to force heterogeneous buyer pools into direct first-price competition within the same impression opportunity.

When a publisher restricts a mobile or desktop container to a single fixed creative dimension or an isolated fluid native template, the supply path fragments. Tier-1 DSPs index active campaign line items by creative aspect ratio and pixel dimensions before evaluating audience identity, contextual signals, or floor prices. If an impression request arrives with only a fluid native specification or a single dimension tuple, any DSP campaign lacking an exact asset match terminates evaluation at the pre-targeting layer, reducing bid density and allowing remaining buyers to shade their bids downward.

Maximizing revenue per pageview requires engineering responsive ad slots that aggregate standard IAB fixed dimensions alongside native and outstream video demand without failing Core Web Vitals thresholds. By aligning viewport breakpoint rules across GPT sizeMapping() and Prebid.js 11.x configuration objects, publishers can capture the clearing price premium of multi-size auctions while maintaining strict Cumulative Layout Shift (CLS) containment across desktop, tablet, and mobile viewports.

The Math of Bid Density: Combining 300x250, 336x280, and 300x600

In a first-price programmatic auction, the clearing price of an impression is governed not just by the highest valuation a single buyer assigns to a user, but by the density and variance of competing bids above the floor price. Modern DSP bidding algorithms apply real-time bid shading, estimating the minimum price required to win a specific placement based on historical clearing price distributions. When a slot is restricted to a single size such as 300x250, the competing demand comes from a homogeneous pool of medium rectangle campaigns. Because the buyer composition on a single-size slot remains predictable, DSP shading models quickly converge on the local clearing threshold and compress their submitted bids toward the floor.

Combining 300x250 (Medium Rectangle), 336x280 (Large Rectangle), and 300x600 (Half Page) within a unified ad slot alters this auction distribution by merging three distinct demand curves into a single clearing event:

• 300x250 (MREC) Liquidity Base: Provides the highest fill rate and baseline bid density across both mobile web and desktop viewports, capturing performance, retargeting, and mid-funnel programmatic guaranteed or open-market campaigns.
• 336x280 Incremental Exchange Demand: Captures Google AdX and retail-heavy DSP buyers that specifically target the 25% larger canvas area of the Large Rectangle. Because 336x280 fits inside standard mobile viewports (375px to 430px wide) and desktop sidebars with minimal CSS adjustment, adding it to a 300x250 slot commonly increases eligible bid volume by 18% to 28% with near-zero layout disruption.
• 300x600 High-Impact Brand Demand: Introduces upper-funnel brand awareness budgets that value vertical screen real estate and prolonged viewability duration. While 300x600 has lower raw buyer count than 300x250, its gross CPM bids frequently clear 45% to 90% higher than standard rectangles.

When all three dimensions are passed in the imp.banner.format array of an OpenRTB 2.6 bid request, DSP shading algorithms face cross-format competition. A 300x250 retargeting bidder can no longer shade aggressively toward a low baseline because a 300x600 brand bidder or a 336x280 dynamic product ad in Google AdX may clear the auction at a significantly higher eCPM. Publishers evaluating high-performing banner and MREC formats routinely observe a 22% to 38% lift in overall slot yield when transitioning from single-size 300x250 declarations to combined [[300, 250], [336, 280], [300, 600]] arrays on eligible breakpoints.

Fluid native sizes ('fluid' in GAM) operate on a separate valuation mechanic. Rather than requesting fixed pixel dimensions, a fluid slot instructs Google AdX or native-capable SSPs to return structured JSON asset components (headline, body copy, call-to-action, logo, and a 1.91:1 or 1:1 main image) that the browser styles dynamically to fill 100% of the parent container width. While fluid native units achieve strong click-through rates in feed-based layouts, isolating a slot to 'fluid' alone excludes standard HTML5 display creatives that account for the majority of open-exchange spend. The optimal yield architecture combines 'fluid' with [300, 250] and [336, 280] inside the same GAM slot definition, forcing native asset assemblies to beat the highest-paying multi-size display bid to win the impression. AdOps teams can model the net revenue impact of these fill and CPM shifts across their daily impression volumes.

Slot Configuration	Primary OpenRTB Object	Relative Bid Density	Typical Viewability (MRC)	Average eCPM Index (Baseline = 100)
Fixed Single-Size (300x250 only)	imp.banner (1 format)	Baseline (1.0x)	64% - 70%	100
Pure Fluid Native ('fluid' only)	imp.native	Low-Moderate (0.45x)	68% - 75%	88
Multi-Size Display (300x250, 336x280)	imp.banner (2 formats)	High (1.35x)	65% - 72%	124
Full Multi-Size + Native (300x250, 336x280, 300x600, 'fluid')	imp.banner + imp.native	Maximum (1.75x)	72% - 81%	158

Implementing Responsive Size Mapping in GPT (SizeMappingBuilder) and Prebid

Declaring multi-size arrays globally without viewport filtering breaks page layouts when a 970x250 billboard or 300x600 half-page creative renders inside a 375px mobile screen or a constrained tablet grid. To prevent horizontal overflow and wasted bid requests, responsive size rules must be synchronized between Google Publisher Tag and Prebid.js 11.x. According to Google Publisher Tag's ad sizing documentation, googletag.sizeMapping() automatically orders viewport rules from largest to smallest, evaluating width first and then height, regardless of the sequence in which .addSize() methods are chained in the publisher's JavaScript code.

A common production bug occurs when engineering teams configure googletag.sizeMapping() properly for GAM, but leave the corresponding Prebid.js adUnit.mediaTypes.banner.sizes array unfiltered as a static superset of all desktop and mobile dimensions. If Prebid.js dispatches bid requests containing [[970, 250], [728, 90], [300, 600], [300, 250], [320, 50]] while the user is on a 390px mobile viewport, participating SSP partners will solicit and return desktop-sized bids (970x250 or 728x90). When Prebid passes those winning key-values (hb_size: 970x250) to GAM, GPT rejects the line item because 970x250 is disallowed by the active mobile sizeMapping() rule. The high-CPM header bidding win is discarded, the auction falls back to a lower-yielding remnant line item, and SSP partners penalize the publisher's supply path for low render rates.

To eliminate this discrepancy, the client-side wrapper must evaluate window.innerWidth and window.innerHeight prior to auction initialization, passing the exact same filtered size matrix to both pbjs.addAdUnits() and googletag.sizeMapping().

window.googletag = window.googletag || { cmd: [] };
window.pbjs = window.pbjs || { que: [] };

const BREAKPOINTS = [
  { minWidth: 1024, minHeight: 768, sizes: [[300, 600], [336, 280], [300, 250], 'fluid'] },
  { minWidth: 768,  minHeight: 0,   sizes: [[336, 280], [300, 250], 'fluid'] },
  { minWidth: 320,  minHeight: 0,   sizes: [[336, 280], [300, 250], [320, 100]] },
  { minWidth: 0,    minHeight: 0,   sizes: [] }
];

function getActivePrebidSizes(vw, vh) {
  for (const bp of BREAKPOINTS) {
    if (vw >= bp.minWidth && vh >= bp.minHeight) {
      return bp.sizes.filter(size => Array.isArray(size));
    }
  }
  return [];
}

googletag.cmd.push(function() {
  const sidebarMapping = googletag.sizeMapping();
  BREAKPOINTS.forEach(bp => sidebarMapping.addSize([bp.minWidth, bp.minHeight], bp.sizes));

  googletag.defineSlot('/21700000000/article_sidebar_1', [[300, 250]], 'div-gpt-sidebar-1')
    .defineSizeMapping(sidebarMapping.build())
    .addService(googletag.pubads());

  googletag.pubads().enableSingleRequest();
  googletag.pubads().disableInitialLoad();
  googletag.enableServices();
});

pbjs.que.push(function() {
  const activeBannerSizes = getActivePrebidSizes(window.innerWidth, window.innerHeight);
  if (activeBannerSizes.length === 0) return;

  pbjs.addAdUnits([{
    code: 'div-gpt-sidebar-1',
    mediaTypes: {
      banner: { sizes: activeBannerSizes }
    },
    bids: [
      { bidder: 'skyboosts', params: { placementId: 'sb_994810', publisherId: 'pub_401' } }
    ]
  }]);

  pbjs.requestBids({
    timeout: 1200,
    bidsBackHandler: function() {
      pbjs.setTargetingForGPTAsync(['div-gpt-sidebar-1']);
      googletag.cmd.push(function() {
        googletag.pubads().refresh();
      });
    }
  });
});

Notice how getActivePrebidSizes() strips out the string 'fluid' before constructing mediaTypes.banner.sizes for Prebid.js 11.x, while preserving 'fluid' inside the GPT sizeMapping builder. Standard Prebid banner adapters require integer [w, h] arrays; native demand in Prebid is instead requested via a dedicated mediaTypes.native object schema.

Why GPT Defaults Unstyled Multi-Size Divs to Shortest Height x Widest Width

One of the most damaging layout bugs in multi-size programmatic engineering stems from how Google Publisher Tag handles unstyled container <div> elements during slot initialization. As documented in the official GPT ad sizes guide, if CSS dimensions are not explicitly reserved on a multi-size ad slot <div>, GPT sets the initial container dimensions to the shortest declared height and widest declared width over 1px when googletag.display() is called.

Consider a common mobile web implementation where an AdOps team attaches a unified size array of [[336, 280], [300, 250], [320, 100], [320, 50], [1, 1]] to an in-article slot without applying a CSS min-height to the wrapper element. When googletag.display() executes:

1. GPT ignores [1, 1] because its pre-sizing heuristic only evaluates dimensions strictly greater than 1px.
2. GPT scans the remaining widths (336, 300, 320) and selects the widest value: 336px.
3. GPT scans the remaining heights (280, 250, 100, 50) and selects the shortest value: 50px.
4. GPT injects an inline style reserving a 336px by 50px bounding box in the DOM while the Prebid and GAM auctions execute over the network.

Roughly 400 to 900 milliseconds later, when a 300x250 or 336x280 creative wins the auction and renders into the iframe, the container snaps vertically from 50px to 250px or 280px. Because the user is already scrolling through the article text, this 200px to 230px expansion shifts all subsequent paragraphs downward, triggering a severe Cumulative Layout Shift (CLS) penalty that degrades the domain's Core Web Vitals score and organic search visibility.

The architectural fix requires two strict rules:

• Decouple Horizontal Banners from Rectangular In-Content Slots: Never mix 320x50 or 320x100 sizes into in-article 300x250 / 336x280 slots unless the container is explicitly styled to absorb the height delta. Reserve 320x50 and 320x100 for fixed viewport-bottom anchor units or top-of-page header strips where a 50px or 100px height is expected.
• Enforce CSS Minimum Height Containers: Wrap every multi-size in-article slot in a flexbox outer shell with min-height: 280px; (when 336x280 and 300x250 are eligible) and align-items: center; justify-content: center;. If a 300x250 creative wins inside a 280px reserved container, the 15px top and bottom padding absorbs the difference cleanly with zero DOM reflow.

Why Non-Standard Custom Sizes Suffocate Programmatic Demand

When publishers redesign editorial templates, product designers occasionally specify custom ad container dimensions such as 340x260, 680x180, or 400x300 to align with custom column widths, or rely exclusively on uncalibrated fluid slots to stretch creatives across arbitrary grid tracks. From a programmatic supply path perspective, non-standard pixel dimensions starve the auction before bidding even begins.

In the OpenRTB 2.6 specification, DSP edge routers receive tens of millions of QPS (queries per second) globally. To process this volume within a 100ms network SLA, DSPs do not execute deep machine-learning valuation on every incoming bid request. Instead, requests pass through a lightweight pre-targeting filter that checks basic compatibility tuples: geo-location, device type, supply source ID, and exact w and h integers in the imp.banner.format array. Agency trading desks and brand buyers build HTML5 display bundles exclusively around the IAB Standard Ad Unit Portfolio and legacy high-volume sizes (300x250, 336x280, 728x90, 970x250, 300x600, 160x600, 320x50, 320x100).

If a publisher passes w: 340, h: 260 in an OpenRTB request without including [300, 250] or [336, 280], over 95% of active DSP seats immediately drop the request as No Matching Creative Size. The only demand capable of filling an isolated 340x260 slot consists of server-side auto-resizing native templates that dynamically stretch low-tier remnant assets to fit arbitrary bounding boxes. Consequently, the publisher trades away tier-1 brand and performance competition for aesthetically flush borders, typically suffering a 50% to 75% collapse in slot eCPM.

Integrating our unified monetization platform allows publishers to preserve clean editorial grids without resorting to non-standard ad dimensions. By housing standard [[300, 250], [336, 280]] arrays inside styled CSS card wrappers that match the publication's border-radius, background tint, and typography tokens, engineering teams satisfy visual design requirements while exposing 100% of the inventory to mainstream, brand-safe DSP demand.

Vertical Video (9:16) Outstream Demand in Mobile Web Slots

As advertisers shift creative production toward mobile-first vertical video (9:16 aspect ratio, commonly trafficked at 360x640, 300x533, or 1080x1920), static multi-size display slots on mobile web have become prime real estate for high-CPM outstream video demand. On a 375px to 430px mobile screen, an in-article slot configured for 300x600 alongside 300x250 and 336x280 already occupies the vertical footprint required to render a 9:16 or 4:5 VAST 4.3 video player.

In Prebid.js 11.x and OpenRTB 2.6, configuring an ad unit as multi-format (declaring both mediaTypes.banner and mediaTypes.video with context: 'outstream') enables the slot to solicit VAST video bids and HTML5 display bids simultaneously. Because mobile vertical video campaigns frequently clear at eCPMs between $8.00 and $18.00, allowing outstream video to compete directly against $1.50 to $3.50 mobile display banners significantly elevates blended yield.

{
  "id": "req-mobile-multiformat-8841",
  "imp": [
    {
      "id": "1",
      "tagid": "mobile_in_article_2",
      "banner": {
        "format": [
          { "w": 300, "h": 250 },
          { "w": 336, "h": 280 },
          { "w": 300, "h": 600 }
        ],
        "pos": 1
      },
      "video": {
        "mimes": ["video/mp4", "video/webm"],
        "minduration": 5,
        "maxduration": 30,
        "protocols": [2, 3, 5, 6, 7, 8, 11, 12, 13, 14],
        "w": 300,
        "h": 533,
        "placement": 3,
        "plcmt": 4,
        "linearity": 1,
        "playbackmethod": [6],
        "maxextended": 30
      },
      "bidfloor": 1.25,
      "bidfloorcur": "USD"
    }
  ]
}

In this OpenRTB 2.6 impression object, the slot exposes three high-liquidity display formats (300x250, 336x280, 300x600) alongside an outstream video object (placement: 3, plcmt: 4, playbackmethod: [6] for auto-play sound-off on viewport entry) sized at 300x533 (9:16 aspect ratio). When a video DSP returns a winning VAST 4.3 tag, the outstream renderer instantiates only after the creative payload buffers, preventing blank video player frames from degrading user experience.

To capture the full yield potential of multi-size and multi-format auctions across breakpoints, engineering and AdOps teams should execute a four-step audit across their production templates:

1. Consolidate Rectangular Liquidity: Pair [300, 250] and [336, 280] across all desktop sidebar and mobile in-article placements, and append [300, 600] to below-the-fold mobile slots and sticky desktop rails.
2. Isolate Short Banner Heights: Strip [320, 50] and [320, 100] out of in-article multi-size arrays so GPT never initializes unstyled containers at a collapsed 50px height.
3. Synchronize Prebid and GPT Breakpoints: Filter mediaTypes.banner.sizes dynamically by viewport width before calling pbjs.requestBids() so SSPs only receive sizes that GAM's sizeMapping() permits to render.
4. Combine Fluid and Outstream Demand with Fixed IAB Tuples: Treat 'fluid' native and 9:16 outstream video (300x533) as additive demand layers inside multi-size slots rather than standalone replacements for standard IAB dimensions.