OpenRTB 2.6 Explained: What Publishers Need to Know About Ad Podding

A live stream cannot absorb a gap. If a 28-second creative plays in a slot budgeted for 30, the viewer watches two seconds of black, and in linear television that dead air is a scheduling failure, not a cosmetic one. OpenRTB 2.6 exists in large part because of this failure mode: its ad pod fields give the buy side a structured way to bid on an entire commercial break, with exact durations where exactness is the whole point.

The IAB Tech Lab opened public comment on OpenRTB 2.6 on December 9, 2021, ran a 60-day window to February 7, 2022, and shipped the final specification in April 2022 with additions and updates to over 35 sections. The flagship feature enables buying of Connected TV inventory through structured, dynamic, and hybrid ad pods. For publishers and the agencies advising them, the revision lands in three operational places: how you build bid requests, how you price a break instead of a single slot, and what your SSAI path must handle at delivery time.

What 2.6 changed besides the pods

Three changes in the 2.5 to 2.6 delta touch every request you send, pods aside. The spec promoted the gdpr and consent attributes into the core protocol, so privacy signaling that previously traveled in extension objects now sits in first-class fields and no longer depends on vendor-specific conventions. It moved the enumerated lists to AdCOM 1.0, which means creative attribute codes, placement types, and connection types now live in a companion document. It also added six new objects: Network, Channel, SupplyChain, SupplyChainNode, EIDs, and UIDs.

Each addition carries a concrete sell-side consequence. SupplyChain and SupplyChainNode let buyers verify every reseller between your content and the bid, so a stale sellers.json entry surfaces as rejected bids instead of silent revenue loss. Channel describes the content a pod attaches to, which matters to buyers that constrain by category or bundle. EIDs and UIDs give the buy side a standard container for extended and unified identifiers, which trims the number of bespoke extension objects a seat has to parse. The IAB Tech Lab's OpenRTB 2.6 implementation announcement presents pod bidding as the release's headline capability, with the structural changes above as supporting infrastructure.

The AdCOM split has a QA consequence of its own. Pin both documents in your test fixtures, because the spec can revise an enum without touching your code, and a mismatch surfaces as miscategorized creative or a rejected placement, never as a parse error.

Three pod shapes, three request patterns

OpenRTB 2.6 defines pod bidding in three forms, and the distinction matters at the request level: each form decides who fixes the number of ads, who fixes their durations, and how many bid requests the break generates.

Structured pods pre-define the number of slots, their position and durations. A broadcast-style break planned as two 30-second slots and one 15-second slot is structured, and the sell side issues one bid request per slot, each carrying the pod's identity, the slot's position, and the duration allowed at that position. Buyers compete per slot the way they compete for a single ad today, and the break keeps its planned shape regardless of who wins. Linear simulcasts and any inventory sold against a fixed break plan fit this form.

Dynamic pods leave the number of ads and their durations indeterminate under two constraints: a total duration, poddur, and a maximum ad count, maxseq. The buyer declares the duration it wants, and the exchange assembles the pod from winning bids until the duration or the count runs out. The break then flexes with demand: more short spots when short creatives pay best per second, fewer long placements when long-form creative earns more. VOD and other non-live contexts fit this form, because the player can absorb a break of variable length.

Hybrid pods contain both components: fixed slots plus a dynamic remainder priced under the duration left over. A break with a guaranteed 30-second lead slot followed by an auction-filled tail is the standard hybrid case. In practice the fixed part behaves like a structured pod and the remainder behaves like a dynamic one, which means your integration has to support both request patterns before you sell a single hybrid.

All three forms travel the same request fields. What changes is which side commits first: the seller commits before the auction in a structured pod, the buyer commits with a declared duration in a dynamic pod, and a hybrid splits the commitment between them.

The seven pod fields, and two naming traps

OpenRTB 2.6 added seven fields to the Video and Audio objects for pod bidding support. Their definitions are normative in the OpenRTB 2.6 specification, which also carries the full 2.5 to 2.6 change log, so treat that document as the tiebreaker whenever this article and your internal documentation disagree.

• poddur: the pod's duration in seconds. In a dynamic pod, every declared duration has to fit inside this number.
• maxseq: the maximum number of ads the pod can carry. In a dynamic pod this is the count ceiling under poddur.
• podid: the identifier that ties separate slot requests back to the same pod. Structured pods depend on it, and four per-slot requests without it are just four unrelated impressions.
• podseq: the pod's position in the sequence of pods for the content. First break and last break price differently, and podseq is how the buyer knows which one it is bidding on.
• mincpmpersec: a per-second floor for bids within the pod. A buyer that wants 40 seconds must clear forty times the per-second value, which turns duration from a free resource into a priced one.
• slotinpod: the position within the pod this request targets, the field that makes structured pods addressable slot by slot.
• rqddurs: the list of acceptable durations, precise to the second, and mutually exclusive with maxduration. maxduration says nothing longer than, rqddurs says only these, and it targets live TV, where a creative that does not fill its slot exactly creates dead air.

Two traps cost teams days because nothing errors. The field is poddur, not podduration: a wrapper that guessed the longer name drops the duration constraint silently, and the buyer reads the request as a plain single-slot video impression. There is also no adpod field in the Video object, so any integration document that references one describes something that does not exist in 2.6. Assert on exact field names in QA, because the only symptom of either mistake is a break that behaves like ordinary pre-roll.

The auction math changes per second

A structured pod auction is familiar territory: per-slot competition, per-slot floors, ranking by expected value. A dynamic pod auction is not, because the buyer declares its own duration and the unit of competition becomes the second. Your floor structure has to follow that shift.

Take a pod with a poddur of 120 seconds and a maxseq of 4. One buyer bids 20.00 for a 60-second placement, a second bids 12.00 for 30 seconds, and a third bids 9.00 for 15 seconds. Total bid size puts the first buyer on top. Value per second reorders the field: 0.33 per second for the 60-second bid, 0.40 for the 30-second bid, 0.60 for the 15-second bid. If mincpmpersec sits at 0.35, the 60-second bid fails the floor even though it carries the largest total, and the pod assembles from the 30-second spot, the 15-second spot, and whichever further bids clear the remaining 75 seconds and the remaining two slots.

Three consequences follow for floor policy. A per-slot reserve inherited from single-slot video misprices dynamic pods, because a 15-second winner and a 60-second winner pay for different quantities of the same break. mincpmpersec scales with duration, which matches how buyers value CTV attention, so treat it as the primary reserve on dynamic pods. Pod revenue is also a sum, so a run of short high-rate spots can out-earn one long placement, and you should compare total pod revenue across configurations before fixing policy. The same first-price dynamics apply at pod level as anywhere else, including the bid shading buyers apply against your reserve, and we cover first-price auctions and bid shading, together with expected-value ranking and reserve price mechanics, in detail on our programmatic page.

Before podding changes any floor, capture a baseline on identical content and hours with single-slot requests over a fixed window. Pod experiments judged against an unmeasured baseline produce noise, because break composition itself changes what buyers bid. Track clearing value per second alongside spot CPM, since buyers shade against a per-second floor in proportion to the duration they declare.

Live inventory changes the calculus again. With rqddurs you trade buyer flexibility for zero dead air: the buyer must return one of the exact durations your stream can stitch, or not bid at all. Weigh the unsold risk against the operational cost of two black seconds in a live feed before choosing between rqddurs and maxduration per channel.

Where podding already runs

Ad Manager app inventory

Google Ad Manager is launching ad podding as an optimization to increase competition and revenue for mobile app inventory, and Ad Manager enables it by default where High Engagement Ads are active. Two cautions follow from the scope of that announcement. First, it covers mobile app inventory specifically, not CTV, so do not read it as pod support for your Connected TV line items. Second, because the optimization is on by default, app publishers should audit podded breaks now, before a change in fill or break shape shows up in reporting and reads as a demand problem.

Long-form OTT through Prebid and Ad Manager

Prebid supports long-form OTT ad pods delivered through Google Ad Manager, using the adpod media type. One auction covers the whole pod and hands back bids per slot, and each slot then delivers through your Ad Manager video line items. The pattern matters for teams that already run Prebid for video, because the auction layer stays the same and only the media type and delivery mapping change. Prebid documents the full configuration and delivery path in its long-form OTT tutorial, and that tutorial is the right starting point for adding pod support to an existing setup.

Our side of the pipe

We sit on all three sides of this market, as an ad network, an SSP and an agency in one company, so we see pod traffic from request construction through to payout. At OnlyMedia, we integrate OpenRTB 2.6 seats and Prebid for header and server-side demand. Video runs VAST 2.6 to 4.3, client side or stitched server side as SSAI, delivered through XML or JS tags, and the range matters for pods specifically: a pod response carries multiple creatives, the stitcher sequences them against the cue point, and delivery paths that assume one creative per response need attention before pod demand reaches them. Our video advertising stack covers in-stream and out-stream formats, SSAI, pod orchestration and CTV, and our API documentation carries the field-level request and response examples for OpenRTB and VAST integration.

We work with thousands of publishers, each above one million monthly pageviews. Our demand network pairs pod-capable buyers with that publisher base, and we pay Net 30 on a CPM basis, so pod revenue settles per slot the auction produced, with no sliding terms after the fact.

A pre-flight checklist before your first pod

Pod bidding fails quietly, so the work happens before the first pod goes live. Run the items below in order, because each depends on the one before it.

Agencies advising publishers should add one contractual step to this list. Put three things in writing with the SSAI vendor before rollout: support for multi-creative pod responses, exact duration matching under rqddurs, and error behavior when a mid-pod creative fails. Stitching failures surface as viewer complaints rather than bid errors, so the contract should name who watches the stitch.

• Version fallback: confirm what your seat does when a buyer negotiates down to 2.5 and the pod fields drop out of the request. Decide in writing whether a 2.5 buyer receives pod context at all, or competes on flat impressions.
• Field assertions: validate poddur, maxseq, podid, podseq, mincpmpersec, slotinpod and rqddurs exactly as spelled, and reject any adapter or wrapper that emits podduration or adpod.
• Stitcher load tests: replay multi-creative VAST responses at both ends of the supported range, 2.6 and 4.3, then verify sequencing, offset timing, and behavior when the second creative errors mid-pod.
• Duration policy per channel: assign rqddurs where dead air is unacceptable and maxduration where flexibility earns more, and define the fill behavior when no bid matches the requested durations.
• Floors in pairs: split test a per-slot reserve against a mincpmpersec reserve on identical content, and judge by total pod revenue, not by spot CPM.
• Reporting keys: carry podid and podseq into reporting, otherwise the first break and the third become indistinguishable and neither can be priced properly.
• App defaults: check where High Engagement Ads are active so the default podding matches what your app reporting expects.

Two durable moves

Adoption of pod formats is a buy-side decision, and every pod field sits on the request side. A publisher cannot force a buyer into pods, but a publisher can be ready the day one asks. The durable work is unglamorous: spell the seven fields exactly as the spec spells them, and make your SSAI path prove it can sequence a multi-creative response under load. Do both, and the commercial break becomes a unit you price deliberately, rather than a set of slots sold separately and stitched together by accident.