Welcome Back OpenRTB 2.X

The newest version of the 2.x series of OpenRTB specification is closing it’s public comment soon, make sure to take a look!

We’ve all heard that Connected TV (CTV) is the new frontier in digital advertising. And that the monumental shift of linear television advertising budgets to CTV means that there is also a need for investment in technical standards to support CTV-specific buying behaviors.

Enter OpenRTB 2.6

The features added to OpenRTB 2.6 were designed to help facilitate automation of spend in CTV through flexibility in buying and selling behavior, additional description of the video content, and faster speed to market. OpenRTB 2.6 was released for Public Comment in November 2021, we’ve given it an extended public comment period due to the holidays, but the window for comments is coming to a close. I’m hoping to highlight the key new features of the 2.6 version in an effort to get you all excited for problems this solves, and provide a last chance to give us feedback on better ways to accomplish the goals for the enhancements.

While the primary additions to the standard are in support of buying and selling of CTV inventory, as the first 2.x release in 2 years, 2.6 also aims to do some cleanup within the specification itself. We’ve done this by moving the ‘2.x List’’ references to point to the AdCOM 1.0 specification, and upgrading some very well adopted extensions to the mainline specification. Checkout the summaries below for more information and provide us your feedback.

Pod Bidding – see section 7.6

This may be a new term to some, an ad pod describes an ad break, or collection of ad slots, similar to the type you’d see in a TV viewing experience or hear during a radio program. It typically contains one or more in-stream ads that play out consecutively within a stream of video or audio content. With pod bidding, a seller can offer up information on the type of pod. Is it fully structured where there are a fixed number of ad slots within a break, each with a fixed length requirement? Or is it more flexible, where the total length of the break (pod) is given, but the buyers can determine how many ad slots of various lengths they are able to fill it with. Or is it some combination of the two? Sellers having the ability to list inventory for multiple ads in one bid request, and buyers having the flexibility to fill the pods with their available campaigns, while understanding the bounds of the pod means we’ll have higher fill rates and happy buyers and sellers.

Channel and Network Objects – see sections 3.2.21 and 3.2.22

Business relationships and content distribution in the world of CTV are complex subjects. That doesn’t stop buyers from wanting to target specific shows by specific networks on specific channels or platforms. It means we have to find ways to be able to supply that information when available. The network and channel objects are much needed additions to OpenRTB that allow for additional descriptive attributes on the content object specific, they provide flexibility to not just define the content, but also the network and channel where the buyer can expect the content to be shown. We can expect that buyers will be able to better target their CTV buys with this information.

AdCOM 1.0

OpenRTB 2.5 essentially included all of the required enumeration values within the specification itself. This meant that updating something like Creative Subtypes or DOOH Venue Types actually required a full version update. We’ve corrected that problem by pointing all enumerated lists to AdCOM 1.0, which has a much more streamlined release process. This means if something is missing from a list, or a new Enumeration is created, it can be identified and corroborated by the Programmatic Supply Chain Working Group and updated on a monthly or quarterly basis instead of annual. Overall this will help with faster time to market and speedy adoption of new or updated list values that can be readily used in your OpenRTB 2.6 implementation with only minor changes.

Promoting Extensions

In our industry, new features are needed all the time, and can’t always wait for an annual release cycle. We use the concept of extensions (a playground, if you will, for new OpenRTB features) to prove these features out.

Some very successful extensions you may have heard of, GDPR TCF consent string, US Privacy String, Supply Chain Object and EIDs. With how widely these have been adopted, we wanted to promote them to the mainline specification. Overtime we expect to be able to offer faster promotion of well adopted extensions, so that they are more officially standardized within the specification itself.

We are incredibly excited to get these changes out into the market for industry adoption and look forward to the efficiencies gained especially in CTV inventory buying and selling. This specification is in public comment until February 7th. If you have thoughts, suggestions or questions please send an email to support@iabtechlab.com with your feedback. IAB Tech Lab members may also be interested in participating in the Programmatic Supply Chain Working Group where these proposals are developed and discussed.