OpenRTB 2.6 arrived in March 2022, six years after OpenRTB 2.5, and most of its changes target video and connected TV. The revision replaced ambiguous numeric video placement codes with named types, added a family of fields for ad pods, clarified device type definitions, and introduced the structured user agent object. Each of those changes maps to a concrete monetization effect: fewer misclassified impressions, better mid-roll packaging, and cleaner device targeting for CTV inventory. This article covers what changed in the protocol, why each change matters for video and CTV revenue, and the questions to put to your demand partners before you rely on it. For the protocol fundamentals, our OpenRTB guide walks through the request and response objects field by field.
What OpenRTB 2.6 changed overall
The IAB Tech Lab scoped 2.6 as a focused revision rather than a rewrite. The official OpenRTB 2.6 document defines the complete change set, and the short version reads like this: a new video placement taxonomy, ad pod fields on the Video object, the DOOH object for digital out-of-home inventory, the structured user agent under device.sua, the device.ext.atts field for iOS App Tracking Transparency status, and revised device type definitions. The OpenRTB 2.6 specification hub now also carries the v2.6-202309 maintenance release, which added Global Privacy Platform signal support on top of the base spec.
Two structural facts matter for planning. First, 2.6 coexists with 2.5 rather than replacing it: a large share of programmatic video still transacts on 2.5, and Prebid and Prebid Server both handle the two versions, so adoption is a partner-by-partner decision rather than a cutover. Second, the changes concentrate on video and device signaling, which means CTV publishers gain the most from moving partners onto 2.6, while display publishers see little difference. That asymmetry explains why CTV teams should treat 2.6 support as a procurement criterion, not a technical footnote.
A third point deserves attention before the detail. Every field discussed below only produces revenue when both sides of the transaction implement it. A publisher who sends poddur and rqddurs to an exchange that ignores them sells the same pod the old way, with the same underfilled break time. The sections below therefore pair each feature with the partner question that verifies real support.
Named video placement types replace ambiguous codes
Under 2.5, the video.placement field accepted three integer values: 1 for in-stream, 2 for in-banner, and 3 for out-stream. The definitions left room for interpretation, and buyers filtered on those integers. A CTV pre-roll described as in-stream by one supply path and out-stream by another produced inconsistent bids for the identical impression. In-banner video carried the worst reputation of the three because it rendered inside display slots with weak viewability and frequently autoplayed muted, so buyers either discounted it or blocked it outright.
OpenRTB 2.6 replaces that taxonomy with five named placement types, and Google's OpenRTB 2.6 changes guide for Authorized Buyers lists the updated video placement types per the new definitions:
- Instream (1): the video plays before, during, or after video content, and the player is the primary focus of the page or screen.
- Accompcontent (2): accompanying content, the successor to in-banner, where the video plays alongside non-video content in a secondary player.
- Outstream (3): the video plays outside a video content stream, the typical case for in-feed and in-article placements.
- Interstitial (4): full-screen placements between content, common during app transitions.
- No Content / Standalone (5): the video is the only content on the page, such as a standalone video page.
The renaming does more than tidy the spec. Buyers pay materially different CPMs for instream and outstream because instream carries higher completion rates and stronger attention metrics, and CTV pre-roll and mid-roll sit firmly in the instream category. When a supply path mislabels a CTV mid-roll as outstream, buyers who filter for instream never see the impression, and the bids that do arrive price it as low-attention inventory. Correct classification widens the eligible buyer pool for exactly the same ad slot.
The deprecation of in-banner also matters. Under 2.5, a publisher could label a small muted player in a sidebar as in-banner video and collect video CPMs for what behaved like display. Under 2.6 that same slot maps to accompanying content, and buyers can price it accordingly. Publishers who built volume on in-banner placements should expect those impressions to reprice, while publishers with genuine instream inventory gain from the cleaner separation.
Ad podding fields change how CTV breaks are sold
A pod is a group of ads sold into a single break. Before 2.6, OpenRTB described one impression at a time, and pods existed only inside VAST wrappers and proprietary extensions. The exchange auctioned each slot independently with no knowledge of total break duration, the sequence, or the other winners. The result: a 90-second break could fill with three 15-second ads and leave 45 seconds of dead air, or two buyers could win consecutive slots from the same advertiser and run back to back.
OpenRTB 2.6 adds five fields to the Video object that fix this:
- video.podid identifies the pod.
- video.podseq gives the sequence position of the ad within the pod.
- video.poddur states the total duration of the pod.
- video.rqddurs lists the requested creative durations a buyer may bid with.
- video.maxseq caps the number of ads in the pod.
Together these fields enable duration matching at the break level. A CTV break commonly runs two to four spots, and with rqddurs the exchange can request 15-second and 30-second creatives to compose a 60-second pod with no wasted seconds. Buyers can also bid with sequence awareness, which supports competitive separation, where two direct competitors avoid adjacent positions, and sponsorship packages, where one advertiser takes an entire break. The fields interoperate with VAST, so the creative delivery side of the transaction keeps working with existing ad servers and stitching infrastructure.
Server-side ad insertion sharpens the stakes. With SSAI, the stitching server composes the final stream, and the pod fields tell the buy side exactly what composition it bids into. Without them, the buyer prices each slot blind and hedges downward. With them, the buyer knows the pod duration, its position, and the requested durations, and can bid closer to the true value of the placement. For publishers, that mechanism typically shows up as higher CPMs on mid-roll inventory and fewer breaks that return partially unfilled.
Device types and structured user agents sharpen CTV targeting
OpenRTB 2.6 revised the device type definitions to draw clear boundaries between type 3 (Connected TV), type 6 (Connected Device), and type 7 (Set Top Box). Under loose 2.5 practice, a streaming stick app, an operator box, and a smart TV app could all arrive as generic television traffic. The clarified definitions let buyers distinguish smart TV inventory from operator set-top inventory, and the two price differently because they behave differently in completion rates, targeting options, and measurement.
The structured user agent object, device.sua, addresses a problem specific to non-web environments. CTV apps send user agent strings that ignore web conventions: the string may name a firmware build, an OEM fork of a browser engine, or nothing recognizable at all. The sua object breaks the client into structured fields: brand, model, and version for the browser or app, plus os and osver for the platform. Buyers use that model-level data for device targeting, frequency capping, and creative compatibility checks. For a CTV publisher, accurate model data means an ad built for a specific TV platform actually renders, which reduces error rates and the bid shading that follows them.
The device.ext.atts field carries the iOS App Tracking Transparency status, which matters for publishers who run phone and tablet apps alongside their CTV properties. When the buy side knows the ATT state, it can route identifiers and attribution accordingly instead of applying a blanket discount to all iOS traffic. None of these signals raise CPMs on their own. They raise CPMs by removing the uncertainty that buyers otherwise price into every bid.
Privacy and supply chain signals in the 2.6 ecosystem
The v2.6-202309 maintenance release added Global Privacy Platform support to the spec, which consolidates consent signaling across regulatory regimes into one field. GPP coexists with TCF strings in Europe, and on the web, Global Privacy Control signals browser-level opt-outs that publishers must honor. For CTV specifically, the consent surface is the app rather than the browser, so publishers need partners who read GPP correctly in app and OTT contexts, not only on the open web.
The transparency stack carries forward unchanged. ads.txt and app-ads.txt authorize the sellers allowed to transact a publisher's inventory, with app-ads.txt doing the job for CTV apps. sellers.json and the SupplyChain object expose the chain of resellers between the publisher and the buyer, and 2.6 inherits both from 2.5. A CTV publisher should verify three things on this stack: that the app-ads.txt file lists every authorized path, that each partner's sellers.json entry names the correct relationship, and that the SupplyChain object arrives intact on every bid request. Buyers increasingly enforce supply path transparency, and broken chains suppress bids even when the inventory itself performs well.
What to ask demand partners about OpenRTB 2.6
Version support varies widely across exchanges and supply-side platforms, so the burden of verification sits with the publisher. Six questions cover the practical surface:
- Which OpenRTB version do you transact on for video and CTV, 2.5 or 2.6, and when does your roadmap complete the migration?
- How do you map our placement types, and do you distinguish instream from accompanying content correctly on our inventory?
- Do you support pod-level bidding with podid, podseq, poddur, rqddurs, and maxseq, and can you demonstrate a filled pod from our test inventory?
- Do you send device.sua and the correct device type for our smart TV, set-top, and connected device apps?
- Do you support GPP and pass the SupplyChain object on every request?
- Which VAST versions do you accept for CTV creatives, and how does that interact with our server-side insertion setup?
Treat the answers as evidence, not assertions. A partner that supports pod fields will show you a sample bid request with poddur populated. A partner that supports the new placement taxonomy will describe its mapping table without hesitation. A partner that answers with general language about innovation and modernization supports none of it, and your CTV inventory will transact at 2.5 prices through that path until it does.
How WireAds applies 2.6 to CTV monetization
We run an SSP and an ad network on CPM terms, and we pay Net 30. We combine Prebid, OpenRTB, Google MCM, Google AdX demand, and direct deals from global and local brand agencies into a single auction, so the highest bid wins each impression rather than any single demand source setting the price. We apply strict filtering to keep low quality and unwanted ads away from premium inventory, which matters most on television screens where a bad creative damages the viewing experience far more than a bad banner does.
We work globally, in every country where Google monetization operates, across web, app, and CTV/OTT. On the CTV side, we treat the 2.6 features in this article as operational requirements rather than future plans: correct placement classification, pod-aware mid-roll selling, accurate device signaling, and intact supply chain objects on every request. You can read more about our CTV and OTT monetization approach, and our CTV ad formats reference covers the creative shapes we transact, from standard pre-roll and mid-roll pods to interstitial placements.
The practical takeaway for any publisher is simple. OpenRTB 2.6 changed the vocabulary of video and CTV transactions, and vocabulary determines which buyers see your inventory and how they price it. Audit your current partners against the six questions above, fix the placement mappings first, then push podding support for mid-roll inventory. Those two steps capture most of the value the revision offers, and both cost negotiation rather than engineering.
