Mastering the OpenRTB Imp Object: Banner, Video, and Native Multi-Format Bid Requests in Prebid 11.x

Section 3.2.4 of the IAB Tech Lab OpenRTB 2.6 specification allows a single impression object (imp) to encapsulate banner, video, and native sub-objects simultaneously, instructing downstream buyers that a single DOM container can render any of those creative formats. Despite this protocol-level capability, many publisher wrapper deployments still partition page inventory into rigid, single-format ad units or fire separate parallel auctions for display and outstream video against the same physical slot. That legacy architecture inflates outbound query-per-second (QPS) volume, dilutes historical slot performance metrics across multiple tag IDs, and forces supply path optimization (SPO) algorithms at major demand-side platforms (DSPs) to throttle redundant bid requests.

Consolidating format eligibility into a unified, multi-format imp payload changes the clearing dynamics of client-side and server-side header bidding. Rather than predetermining whether an in-article placement should monetize as a $1.80 standard display banner, a $2.60 native card, or a $6.50 outstream video unit, a properly structured multi-format request exposes all three impression specifications in a single HTTP transaction. Display, native, and video bidding models then compete directly within the same auction timeout curve, allowing the highest net eCPM across all format budgets to win the slot.

With the release of Prebid.js 11.x, multi-format impression assembly and response validation have matured into strict, specification-driven pipelines. Through deep ortb2Imp object merging, bidder-level first-party data overrides, and automated media type integrity checks at the auction core, engineering teams can construct high-density multi-format auctions that integrate cleanly with Google Ad Manager (GAM 360) and Prebid Server without risking creative rendering failures.

How Multi-Format Imp Objects Increase Slot Competition

When a publisher restricts a high-viewability 300x250 or 336x280 viewport container to imp.banner, the auction is structurally isolated from video and native campaign budgets. Even if a brand buyer is actively targeting that exact user cohort with an outstream VAST 4.3 creative or an OpenRTB Dynamic Native Ads 1.2 package at three times the display clearing price, a banner-only imp specification forces the DSP bid router to drop those campaigns during initial format filtering. Constructing a multi-format impression object removes that artificial wall, creating cross-format price tension that raises floor elasticity and elevates marginal clearing prices.

From an infrastructure standpoint, packaging banner, video, and native inside a single imp object preserves Supply Path Optimization hygiene. Firing three separate single-format imp objects for one physical DOM node multiplies QPS by a factor of three, increasing browser main-thread serialization overhead on the client and inflating network egress costs across Prebid Server clusters. Worse, DSPs evaluating three separate impression IDs for the same page view frequently classify the traffic as duplicative request spamming and apply automated QPS shaping. When those three format specifications are unified under a single imp.id and shared Global Placement ID (gpId), tier-1 DSPs connected through our OpenRTB infrastructure evaluate the impression once, score all eligible format candidates internally, and return their highest-yielding creative without penalizing the supply path.

Maintaining a single placement identity also concentrates historical viewability, click-through rate (CTR), and video completion rate (VCR) signals onto one canonical slot identifier. Machine learning pacing models on the buy side rely on impression density associated with a consistent gpId to predict clearing probabilities and adjust bid shading curves. While browser-based wrappers handle multi-format DOM injection through JavaScript renderers, engineering teams building parallel cross-format competition in mobile environments must coordinate SDK view hierarchies carefully; our in-app bidding guide covers how native and interstitial containers manage similar multi-format mediation workflows on iOS and Android.

Combining banner, video (Outstream), and native Inside a Single adUnit.mediaTypes Object

In Prebid.js 11.x, the client-side representation of an OpenRTB multi-format impression is governed by the adUnit configuration schema. As detailed in the official Prebid.js AdUnit Reference, multi-format ad units define banner, video, and/or native objects inside adUnit.mediaTypes, and support adUnit.ortb2Imp (plus bidder-specific adUnit.bids[].ortb2Imp overrides) and custom renderers. When an auction initiates, the Prebid ortbConverter module inspects each key inside adUnit.mediaTypes and populates the corresponding imp.banner, imp.video, and imp.native branches in the outbound OpenRTB 2.6 request.

Each format branch inside mediaTypes requires precise parameter declarations to prevent downstream DSP rejections:

1. The banner branch: Requires a sizes array of two-integer arrays (such as [[300, 250], [336, 280]]), which ortbConverter translates into imp.banner.format objects containing w and h attributes. If the slot supports flexible responsive sizing or high-impact skins, publishers can append pos (ad position, such as 1 for above the fold) so DSP viewability predictors score the display opportunity accurately.
2. The video (Outstream) branch: Because a multi-format slot does not host a pre-existing video player on page load, the video configuration must set context: 'outstream'. To satisfy OpenRTB 2.6 video compliance, the object should explicitly declare plcmt: 4 (No Content / Standalone video placement), placement: 3 (In-Article, for backward compatibility with OpenRTB 2.5 DSP parsers), playerSize: [[640, 360]], supported mimes (['video/mp4', 'video/webm']), and VAST 4.x protocols ([2, 3, 5, 6, 7, 8, 11, 12, 13, 14]). Crucially, because SSPs returning pure VAST XML rely on the publisher to instantiate a video player when an outstream bid wins, the video object (or top-level adUnit) must include a backup renderer configuration containing a player script URL and a render callback function.
3. The native branch: Modern Prebid 11.x implementations define native requirements using the OpenRTB Dynamic Native Ads 1.2 specification nested under mediaTypes.native.ortb. This object specifies the assets array (including mandatory title, main img with type: 3, icon with type: 1, and data elements such as sponsored with type: 1 and cta with type: 12), allowing DSPs to assemble structured JSON creative payloads that inherit the host page's CSS typography.

const multiFormatAdUnit = {
  code: 'div-gpt-ad-inarticle-01',
  ortb2Imp: {
    ext: {
      gpid: '/1234567/editorial/in-article-slot-1',
      data: {
        pbadslot: '/1234567/editorial/in-article-slot-1'
      }
    }
  },
  mediaTypes: {
    banner: {
      sizes: [[300, 250], [336, 280]],
      pos: 1
    },
    video: {
      context: 'outstream',
      playerSize: [[640, 360]],
      mimes: ['video/mp4', 'video/webm'],
      protocols: [2, 3, 5, 6, 7, 8, 11, 12, 13, 14],
      playbackmethod: [2, 6],
      placement: 3,
      plcmt: 4,
      minduration: 5,
      maxduration: 30,
      api: [2, 7],
      renderer: {
        url: 'https://cdn.skyboosts.com/renderers/outstream-v4.min.js',
        backupOnly: true,
        render: function (bid) {
          bid.renderer.push(() => {
            window.Sky BoostsOutstream.renderAd({
              targetId: bid.adUnitCode,
              vastXml: bid.vastXml,
              vastUrl: bid.vastUrl,
              width: 640,
              height: 360
            });
          });
        }
      }
    },
    native: {
      ortb: {
        ver: '1.2',
        assets: [
          { id: 1, required: 1, title: { len: 90 } },
          { id: 2, required: 1, img: { type: 3, wmin: 300, hmin: 250 } },
          { id: 3, required: 1, data: { type: 1, len: 40 } },
          { id: 4, required: 0, data: { type: 2, len: 140 } }
        ]
      }
    }
  },
  bids: [
    {
      bidder: 'skyboosts',
      params: { placementId: 'sb-multiformat-9941' }
    }
  ]
};

Notice the backupOnly: true property inside mediaTypes.video.renderer. Setting backupOnly: true instructs Prebid.js to prefer a bidder adapter's native outstream renderer if the winning SSP bundles one with its bid response, while guaranteeing that pure VAST XML responses from Prebid Server or direct OpenRTB endpoints still have a deterministic client-side player to execute the creative.

Bidder-Specific First-Party Data Overrides via adUnit.bids[].ortb2Imp

While adUnit.ortb2Imp establishes the canonical impression-level metadata shared across all participating adapters (such as imp.ext.gpid, imp.instl, or slot-level viewability telemetry), enterprise monetization stacks frequently need to scope specific OpenRTB impression attributes to individual demand partners. A publisher may need to pass a private marketplace (PMP) imp.pmp deal array exclusively to one SSP, attach a proprietary imp.ext inventory classification code required by a specific exchange, or override imp.secure and imp.tagid mappings on a per-bidder basis.

Prebid.js 11.x handles this requirement through adUnit.bids[].ortb2Imp. During bid request generation, the wrapper executes a hierarchical deep merge: it starts with the base OpenRTB imp object generated from adUnit.mediaTypes, merges the slot-wide adUnit.ortb2Imp object, and then overlays the bidder-specific adUnit.bids[].ortb2Imp attributes solely for that adapter's auction thread. This architecture prevents data leakage between competing SSPs while eliminating the need to rely on deprecated adapter-specific params properties.

const bidsWithScopedOrtb2Imp = [
  {
    bidder: 'skyboosts',
    params: { placementId: 'sb-multiformat-9941' },
    ortb2Imp: {
      tagid: 'sb-direct-inarticle-01',
      pmp: {
        private_auction: 0,
        deals: [
          {
            id: 'SB-CTV-WEB-DEAL-402',
            bidfloor: 5.50,
            bidfloorcur: 'USD',
            at: 1
          }
        ]
      },
      ext: {
        data: {
          inventory_tier: 'premium_editorial',
          scroll_velocity_bucket: 'low'
        }
      }
    }
  }
];

When the adapter processes bidsWithScopedOrtb2Imp, the resulting OpenRTB 2.6 imp payload retains imp.ext.gpid (/1234567/editorial/in-article-slot-1) inherited from the parent adUnit.ortb2Imp, while injecting the imp.pmp deal object and imp.ext.data.inventory_tier exclusively into the outbound payload for that bidder. Other bidders participating in the same adUnit never see the deal ID or custom extension keys.

How DSPs Choose Which Format to Bid On (and Which Floor Applies)

When a multi-format imp object reaches curated OpenRTB seats, the receiving DSP's bid router must resolve a multi-dimensional optimization problem within a 100ms to 200ms network SLA. Buy-side platforms generally execute one of two evaluation architectures when presented with simultaneous banner, video, and native sub-objects inside a single imp:

• Parallel Internal Auction (Full-Tree Evaluation): Advanced DSPs split the incoming imp across their internal display, video, and native matching engines concurrently. Each engine queries eligible line items, computes expected CTR or VCR given the gpId and user signals, applies internal bid shading, and produces a candidate bid price. The DSP's egress controller then compares the shaded candidates across all three formats and emits a single seatbid.bid object containing the highest-value response, explicitly flagging the chosen format via the OpenRTB 2.6 mtype field (1 for banner, 2 for video, or 4 for native).
• Prioritized Format Waterfall (Compute-Gated Evaluation): To conserve CPU cycles at high QPS, some DSPs evaluate formats sequentially or apply supply-path heuristics. If a buyer's seat is primarily funded by display budgets, or if the DSP's internal pacing model observes that a specific publisher's outstream video floor rarely clears, the bidder may short-circuit imp.video evaluation and only score imp.banner and imp.native.

This buy-side behavior exposes the central yield engineering challenge of multi-format wrappers: floor price arbitrage. In the core OpenRTB 2.6 specification, imp.bidfloor is a single floating-point number at the root of the imp object. If an AdOps team sets a static top-level imp.bidfloor of $4.50 to protect outstream video valuation, every display and native campaign bidding between $1.50 and $4.49 is automatically filtered out, causing severe fill rate loss whenever video demand passes on the impression. Conversely, if the publisher sets imp.bidfloor to $1.20 to accommodate display buyers, sophisticated DSP bid-shading algorithms will detect the low floor and win high-cost outstream video impressions for $1.25.

To prevent format cannibalization, engineering teams must deploy the Prebid Price Floors Module with mediaType dimensionality enabled. By configuring the schema delimiter to evaluate mediaType alongside size (or gptSlot), Prebid.js maintains distinct price thresholds for each format within the same adUnit. When transmitting the bid request to SSPs that support multi-floor OpenRTB extensions (or Prebid Server endpoints that unpack format-level floor rules), each format carries its true reserve price. More importantly, during bid response ingestion on the client, the Price Floors Module inspects the mediaType attribute declared on each returned bid and enforces the exact format-specific floor before the bid is permitted to enter the Google Ad Manager key-value targeting auction. A $2.10 banner bid clears a $1.50 banner floor and competes in GAM, while a $3.80 outstream video bid is rejected if the video floor is set to $4.50.

Enforcing Format Integrity in Prebid 11.0 (rejectInvalidMediaTypes and rejectUnknownMediaTypes)

Prior to Prebid.js 11.0, client-side auction state management suffered from a permissive validation gap inside addBidResponse. If an ad unit was configured purely for banner and native (mediaTypes: { banner: {...}, native: {...} }), a misconfigured bidder adapter or non-compliant SSP endpoint could still return a bid response tagged with mediaType: 'video' (or an arbitrary string like 'display' or undefined). In legacy wrapper versions, if that malformed bid carried the highest CPM, Prebid.js would frequently allow it to win the client-side auction and write hb_pb and hb_adid targeting keys to GPT, resulting in blank creative frames, uncaught renderer exceptions, or unrequested outstream video players injecting into restricted display containers.

Prebid 11.0 eliminates this failure mode at the core auction router. As documented in the Prebid.js 11.0 release notes, in Prebid.js 11.0, bids declaring a mediaType not present in the requested adUnit.mediaTypes are automatically rejected as invalid, governed by auctionOptions.rejectInvalidMediaTypes and auctionOptions.rejectUnknownMediaTypes.

These two boolean properties inside pbjs.setConfig({ auctionOptions }) operate as a two-stage validation gate inside the auction pipeline, and both default to true in Prebid 11.x:

1. rejectUnknownMediaTypes (Stage 1 Schema Validation): Inspects the bid.mediaType string returned by the adapter and verifies that it matches one of the three canonical Prebid format constants ('banner', 'video', or 'native'). If an adapter omits mediaType, passes null, or returns a non-standard string such as 'audio' or 'richmedia', the auction manager immediately rejects the bid before price floor evaluation or currency conversion occurs.
2. rejectInvalidMediaTypes (Stage 2 AdUnit Contract Enforcement): Cross-references the validated bid.mediaType against the exact keys defined on the originating adUnit.mediaTypes object for that specific transaction. If an ad unit requests banner and native, and an adapter responds with mediaType: 'video', rejectInvalidMediaTypes intercepts the mismatch, drops the bid from the eligible pool, and emits a bidRejected event with the rejection reason constant INVALID_MEDIA_TYPE.

pbjs.que.push(function () {
  pbjs.setConfig({
    auctionOptions: {
      rejectUnknownMediaTypes: true,
      rejectInvalidMediaTypes: true
    },
    floors: {
      enforcement: {
        enforceJS: true,
        floorDeals: true
      },
      data: {
        currency: 'USD',
        schema: {
          fields: ['mediaType', 'size']
        },
        values: {
          'banner|300x250': 1.40,
          'banner|336x280': 1.65,
          'native|*': 2.20,
          'video|640x360': 4.75,
          '*|*': 1.10
        }
      }
    }
  });

  pbjs.onEvent('bidRejected', function (bid) {
    if (bid.rejectionReason === 'Cannot fulfill mediaType' || bid.rejectionReason === 'Invalid mediaType') {
      console.warn('[AdOps Telemetry] Format mismatch rejected:', {
        bidder: bid.bidder,
        adUnitCode: bid.adUnitCode,
        returnedMediaType: bid.mediaType,
        cpm: bid.cpm,
        reason: bid.rejectionReason
      });
    }
  });
});

For AdOps and programmatic engineering teams upgrading to Prebid 11.x, enforcing strict multi-format hygiene requires three concrete operational steps. First, audit every placement in the wrapper configuration to ensure that adUnit.mediaTypes explicitly declares all intended formats rather than relying on legacy adapter-level format flags that Prebid 11.0 will now block via rejectInvalidMediaTypes. Second, always pair multi-format adUnit declarations with a mediaType-segmented Price Floors configuration so that lower-cost display and native bids cannot cannibalize outstream video clearing prices. Third, instrument a lightweight listener on the bidRejected event in your client-side analytics adapter to identify and remediate any demand partner returning mismatched mtype payloads before they impact fill rate.