Version 2.6 of the OpenRTB (ORTB) specification is part of the API protocol which forms the backbone of the programmatic industry. Developed by the IAB Tech Lab and available since April 2022, it introduced significant changes to the way bid requests are managed—especially in the CTV space.
One of the most powerful features of OpenRTB 2.6 for CTV is support for dynamic pod bidding, which solves long-running issues faced by video buyers and sellers. In addition, new fields added to the specification open the door to advance contextual targeting options and pave the way for better CTV addressability in the future.
Since its inception in November 2010 by The Real-Time Bidding (RTB) Project (formerly known as the OpenRTB Consortium), the OpenRTB protocol has become the industry standard for buying and selling media programmatically.
Over the years, the specification has been updated periodically to bring new functionality to reflect the changing programmatic landscape. ORTB 2.6 was the first new update since December 2016.
There is something of an elephant in the room, however, in the shape of OpenRTB 3.0, which has been ready to implement as part of the OpenMedia specification since 2018. The delay in the adoption of ORTB 3.0—and the reason why ORTB 2.6 exists at all—is that the majority of the programmatic industry still relies on the 2.X spec, probably because the move to 3.0 requires significant technical work on the implementation side. But the hope is that 2.6 is a step towards mass industry adoption for the 3.0 standard.
So, with OpenRTB 2.6, the focus is squarely on CTV auctions, addressing certain functionality which wasn’t previously available through either OpenRTB or its video-centric cousin, VAST (Video Ad Serving Template).
The full 91-page specification for ORTB 2.6 is available if you have some time to kill, but if you just want the highlights, we’ve got you covered.
The idea of Ad Pods is nothing new for CTV—we’ve all experienced a bundle of ads served during breaks in video content.
But with ORTB 2.6, the goal is to solve long-running issues which occur due to the nature of CTV auctions taking place via traditional programmatic mechanics. In the past, ad slots were filled individually, even within a Structured Ad Pod, so the demand side didn’t have visibility of the entire pod runtime. This led to issues with ad duplication and a lack of competitive separation.
With OpenRTB 2.6 and the concept of Dynamic Ad Pods, bid requests sent by the publisher can now include the full commercial break duration, giving demand partners the opportunity to respond with multiple ads of differing lengths which best match their CPM goals. They can also include a minimum and maximum length for each ad. So, for example, a 90-second commercial break can now be filled by three 30-second ads, six 15-second ads, or any combination of ad durations within the set limits.
One big factor which sets CTV apart from traditional display advertising is the matter of time.
Video ads of different lengths naturally command different CPMs, so ORTB 2.6 introduces a similar concept for bid floors. Using the new mincpmpersec field, publishers can set their floor rate for each individual second of airtime within a Dynamic Ad Pod, making it easier to accurately price and value their CTV inventory.
There is an existing bidfloor field which publishers can use, but this applies to the entire ad slot, making monetization less precise. With the new by-the-second approach to bid floors in ORTB 2.6, buyers have much more flexibility in how they bid – and publishers can tap into the true value of their CTV supply.
Ask anyone who’s active in the CTV space and they’ll tell you that one of the biggest challenges with the format is addressability. While display advertising is facing its own problems with identity, the CTV boom is demanding solutions of its own—and OpenRTB 2.6 offers a step towards an addressable future.
CTV pipes often rely on Virtual Multichannel Video Programming Distributors (vMVPDs), meaning that it’s very difficult for media buyers to pin down exactly where a bid request is coming from, because they all come from the same source. This has led to concerns about brand safety as well as targeting effectiveness.
OpenRTB 2.6 aims to ease these issues with the addition of two contextual fields to the official specification: Content Channel and Content Network. Publishers who choose to include these fields in their bid requests give buyers the chance to better understand the type of—or at least the context of—the content their target audience is consuming, and thus deliver better, more relevant, ads.
If you need guidance on updating your ad tech stack for OpenRTB 2.6, or if you’re new to BidSwitch and looking for new ways to maximize your revenue, just get in touch with the BidSwitch team today.