OpenRTB 2.6 (Open Real-Time Bidding)

OpenRTB — short for Open Real-Time Bidding — is the industry-standard protocol that lets programmatic advertising systems talk to each other. When a publisher's ad space becomes available and is auctioned in real time, the supply-side platform sends a structured bid request describing the impression, and demand-side platforms reply with bid responses. OpenRTB defines the exact format of those messages, so that thousands of buyers and sellers built by different companies can transact automatically in the fraction of a second before a page loads. It is maintained by the IAB Tech Lab, the technical standards body for digital advertising. OpenRTB 2.6 is a specific version of that specification, released in 2022, that extends the previous widely used version, 2.5. Because the protocol is a shared language, a version is essentially an agreed update to the vocabulary every participant uses.

OpenRTB 2.6's headline addition is native support for connected-TV advertising through structured ad pods. An ad pod is a commercial break containing several ad slots, the way a television break holds multiple spots — something the earlier protocol handled awkwardly because it was designed around single web impressions. Version 2.6 introduced ways to describe pods as structured (a fixed number of ads of set lengths), dynamic (a fixed break duration the exchange fills flexibly), or hybrid, so connected-TV inventory could be bought cleanly at auction. Alongside the pods, 2.6 added or refined several other capabilities: objects to describe the network and channel of CTV inventory, guidance on signaling billable events, easier handling of the taxonomies that describe context, and support for the structured User-Agent information browsers now provide as they phase out the old User-Agent string for privacy. Together these updates modernized the protocol for streaming video and a changing privacy landscape.

It helps to separate three things people run together: real-time bidding as a concept, OpenRTB as the protocol that implements it, and 2.6 as one version of that protocol. Real-time bidding is the general practice of auctioning each ad impression individually, in real time, as a page or stream loads. OpenRTB is the specific, open specification — governed by the IAB Tech Lab — that standardizes the messages that make those auctions work across different vendors. A version number like 2.6 identifies a particular revision of that specification. So saying a system supports OpenRTB 2.6 means it speaks that revision of the shared language, including its newer fields; it is a statement about protocol compatibility, not a different way of bidding. The auction mechanics are broadly the same as under 2.5; what changes is what the messages can express.

The difference between 2.6 and 2.5 is mostly about what inventory and signals the protocol can describe, not a reinvention of how auctions run. Version 2.5 was for years the workhorse of programmatic, but it predated the surge in connected-TV buying and the browser privacy shifts that followed, so it lacked clean ways to represent CTV ad pods and the structured User-Agent data replacing the legacy string. Version 2.6 filled those gaps, adding the pod structures, CTV description objects, billable-event guidance, and taxonomy and User-Agent handling described above, while remaining recognizably the same protocol. Adoption of a new version is gradual, because every participant — exchanges, supply-side platforms, demand-side platforms — must implement the changes for them to be useful end to end, which is why 2.5 and 2.6 coexist in the ecosystem for a long transition rather than one replacing the other overnight.

For most marketers, the practical relevance of OpenRTB 2.6 is indirect but real: it is the plumbing beneath the connected-TV and video buying that has grown so quickly. Knowing that 2.6 added structured ad pods explains why CTV inventory can now be transacted programmatically with the kind of control television buyers expect, and knowing it improved User-Agent handling explains part of how the ecosystem is adapting to browser privacy changes. If you work closer to the technology — at a publisher, an exchange, or a platform — working with 2.6 well means implementing the fields your inventory actually uses (the pod structures for CTV, the taxonomy signals for context), coordinating with partners so both sides of the auction understand the same version, and treating adoption as a gradual migration rather than a switch. The value of a protocol is only realized when both ends speak it.

The failures around a protocol version are mostly about misunderstanding what it is. Treating OpenRTB 2.6 support as a marketing badge, without implementing the specific features that matter for your inventory, delivers none of the benefit. Assuming a new version instantly changes auction outcomes confuses a richer message format with a different bidding logic — 2.6 lets the messages say more, it does not by itself change who wins. Expecting the whole ecosystem to move in lockstep ignores the reality that adoption is uneven and versions coexist for years. And, for non-technical marketers, over-indexing on the version number rather than on outcomes misses the point: OpenRTB 2.6 matters because of what it enabled — cleaner programmatic CTV and better privacy handling — not as a spec to memorize. The discipline is to understand it as the standardized, evolving language of programmatic auctions and to care about the capabilities it unlocks.

OpenRTB is the IAB Tech Lab's real-time-bidding protocol, and version 2.6, released in 2022, added connected-TV ad pods among other features.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where openrtb 2.6 (open real-time bidding) is a core concern: