There was an unexpected error authorizing you. Please try again.

OpenRTB 2.6 is ready for Implementation

OpenRTB 2.6 is the latest update to the industry’s standard communication protocol.  The recent additions to OpenRTB 2.6 are focused on connected TV and have been developed by IAB Tech Lab working closely with those involved in CTV auctions to design new specifications that allow publishers to present their inventory more accurately and give buyers the flexibility to respond to bids in a way that will maximize their chances of winning the auction.

In this post, I aim to help readers understand the most impactful features of 2.6, and what makes them so essential for CTV auctions.

Let’s Talk Pod Bidding

For CTV, podded bidding is the keystone feature of the OpenRTB 2.6 release.  To understand why this is so important, think of the traditional TV experience; where a commercial break will show somewhere between 3-5 ads before returning to the scheduled content.  Those breaks have competitive separation, limited showings of the same brand, and the same ad rarely plays twice within the same break.  When CTV first emerged, none of these things were happening within the commercial breaks—this was frustrating to both users and advertisers. The reason this occured, was because there wasn’t the concept of a podded request/response.  CTV ad auctions followed the same mechanics that had been used since the dawn of programmatic buying, where one request was issued for one ad slot and the highest bid filled the slot.  

Over time, supply partners began to offer their inventory as a podded request, with multiple impression objects within the impression array of the video object. This was a great first step because it allowed buyers to de-duplicate their demand before sending it back and publishers were able to de-duplicate their demand sources before showing an ad break to their users. However, one major gap with this solution, which OpenRTB 2.6 helps to resolve, is that this was still slot-based targeting—demand partners were only able to fill the pod with the slots (individual ads) that were sent to them (ex. 3 slots with a min duration of 15 and a max duration of 30) as opposed to seeing the full pod time available.

​​Example of individual slots for purchase:

With OpenRTB 2.6, the publisher is now able to send the pod duration, or the total length of the commercial break, to the buyers and they can choose to fill it in a way that makes the most sense to them.  As an example, if there were a commercial break with a total length of 120 seconds, and a set minimum duration of 15s per ad and a maximum duration of 30 seconds, a buyer could send back four 30 second ads, eight 15 second ads, or any combination of the two. This allows buyers to maximize their response based on the CPM per second.

Example of pod length given and buyer chooses the number of slots and lengths to fill:

This brings me to another pivotal feature of 2.6: CPM per second floors.  Unlike display advertising, video ads are sold with time being a major variable.  Just as ads of different durations should have different bid CPMs, they should also have different floors—passing a floor of $15 doesn’t mean the same thing for a 15 second ad as it does for a 45 second ad.  The new ‘mincpmpersec’ parameter will allow buyers to signal what their floor rate is for every second of air time. With this parameter, a $1 floor would translate to $15 for a 15 second ad and $45 for a 45 second ad.

I’m really looking forward to these updates to podded bidding and how they will allow publishers to more accurately convey their inventory while also giving buyers more flexibility in their bid responses. Overall, these features will have a positive impact on the overall yield for publishers and on the user experience.

More Context for CTV 

Contextual information is becoming more important every year due to the increasing uncertainty and regulation on traditional consumer and device identifiers. Brands want to make sure that the content they’re serving ads next to is safe and suitable to their values

Several different content fields are communicated via extensions in OpenRTB 2.5 and in OpenRTB 2.6, IAB Tech Lab have promoted ‘Content Channel’ and ‘Content Network’, two of the most commonly used content extensions, to the official spec.  

In CTV, having the channel and network information available at the time of bid request is very valuable to buyers, this is because the existence of Virtual Multichannel Video Programming Distributors (vMVPDs) can make it appear to buyers that all of the inventory is the same, even though users are watching different content on different channels. By passing the actual channel that the user is watching along with the network that owns the channel, bid requests in OpenRTB 2.6 will have the necessary information for buyers to make the best decision for their brand.

To make this CTV-focused release of OpenRTB come to life, the IAB Tech Lab worked with leaders in the industry to solve the biggest problems that connected television auctions are experiencing today.  At Publica, we’re really excited to support this new spec and we will be fully compliant by the end of April, 2022.  However, we can’t do this alone so we’re reaching out to our partners across both supply and demand to make sure that market adoption can happen as soon as possible.  If you plan to scale CTV this year we hope that you will join us by planning for a swift integration of OpenRTB 2.6.

About the Author

James Wilhite
VP of Product at Publica (an IAS company)