What is OpenRTB 2.6 and how does it change the game for CTV?
OpenRTB is the lingua franca or the common language of ad tech. It’s a protocol that defines how media owners, buyers, exchanges, and intermediaries communicate with each other.
Index worked with the IAB Tech Lab to develop the latest version, OpenRTB 2.6, which includes several notable updates to account for the intricacies of TV. It was released in early 2022. Moving the industry to version 2.6 will be instrumental in scaling programmatic ads in CTV.
While OpenRTB 2.6 introduces many new features, today we’re going to focus on the ones that solve some of today’s most common CTV challenges:
- Support for ad pods and pod bidding
- Adoption of new taxonomies
- Richer signaling for video
- More helpful bid responses
Support for ad pods and pod bidding
Ad pods, or groups of multiple ads that run one after another, are akin to traditional linear TV ad breaks. Previous versions of OpenRTB lacked a standardised approach to signaling podded supply.
Version 2.6 introduces new features that finally allow us to bring pod bidding to CTV. These new features facilitate the monetisation and construction of ad pods for media owners, and enable the targeting and measurement capabilities that buyers need.
This is a critical and exciting update, because it makes it easier to replicate the TV ad break experience in CTV, which requires maintaining competitive separation and avoiding duplication within the same break.
OpenRTB 2.6 introduces and defines three types of flexible ad pods: structured, dynamic, and hybrid. This allows media owners to construct ad pods with a varied number of ad slots and ad slot lengths to meet their specific monetisation and viewer experience needs.
Pod bidding allows buyers to bid on a specific ad slot within a pod when buying programmatically. Traditionally, different ad breaks within a show, or even the different positions within an ad break, command different prices based on how engaged the viewer may be. This hadn’t been possible to replicate in CTV.
Now, media owners can indicate the position of a given ad pod within a show or movie, and the position of an ad slot within a pod, so buyers can target their bid responses.
Version 2.6 also provides the ability to define CPM floors per second rather than a static floor. For example, if a media owner requests a 50¢ CPM per second floor, that equates to a $15 floor for a 30-second ad and a $30 floor for a 60-second ad. This is the first time we’ve had a concept of dynamic floors in OpenRTB.
Adoption of new taxonomies
OpenRTB 2.6 allows media owners and buyers to use domain-specific taxonomies in their bid requests and responses.
In previous versions, we used the content category taxonomy for three things:
- To describe the category for a site or app
- To describe a specific section or page within a site or app
- To express banned creative categories
Originally designed for web, this was limiting as it didn’t enable unique descriptors for ads, content, and audiences.
OpenRTB 2.6 has moved to a domain-specific taxonomy, which means we now have separate taxonomies for each.
- To express blocked advertiser categories, you’d use the ad products taxonomy.
- To express the category related to a particular page, publisher, or streaming app, you’d use the content taxonomy.
- To describe audiences in first-party data or other types of consumer data, you’d use the audience taxonomy.
Media owners and buyers can also agree on custom taxonomies in addition to using the standard ones that the IAB provides.
Richer signaling for audio and video
OpenRTB 2.6 added support for richer signaling in two areas: one to indicate the network and channel for a piece of content and one to better set expectations for SSAI, or server-side ad insertion.
An example of a network is A&E Networks, and the channels that they have available through their various streaming platforms and syndication partners are History Channel, Lifetime, and Vice. Indicating the network and channel provides additional context and allows media owners to be more descriptive and transparent about the source of the supply, and better clarify CTV inventory relationships for buyers.
SSAI technology is used to deliver CTV video streams as it provides a seamless viewer experience with no interruptions between content and ad breaks. However, different SSAI implementations handle measurement and billing notifications in different ways.
Richer signaling for SSAI allows media owners to indicate to buyers whether their ads will be stitched into the content stream on the client side or the server side. And furthermore, whether impression notifications and other beaconing are going to originate from the client side or server side.
This signal not only indicates the quality of the viewer experience, but it’s also useful for anti-fraud purposes. Ad tech supply chain participants can follow inventory quality best practices and monitor for IP addresses, user agents, and digital cryptographic signatures (like ads.cert 2.0 or Roku’s watermark).
These signals can be used together to validate that devices, their apps, and players are operating as expected and appear to be authentic. OpenRTB 2.6 even provides guidance on how to use these signals in a new section called, “Counting Billable Events and Tracked Ads.”
More helpful bid responses
Prior to OpenRTB 2.6, exchanges and media owners had to inspect the contents of the buyer’s ad markup field to determine what kind of creative was returned, and, if applicable, the duration of it.
This is particularly challenging for multi-format requests, where a seller could request that a buyer return either a banner or a video or a native bid response.
Buyers can now indicate the particular type of creative—banner, video, audio, or native—as well as the duration of video and audio creatives. Media owners can more easily construct ad pods without having to parse the markup for each creative.
Paving the way for CTV ads of the future
CTV growth has been stunted by a lack of industry-wide standards and programmatic tools designed with the nuances of TV in mind. OpenRTB 2.6 corrects this, and creates standardisation around a host of new capabilities that will pave the path for CTV ads of the future.
It’s imperative that everyone in the industry takes the leap and adopts OpenRTB 2.6 so that we can all speak a common language and realise the full potential of programmatic CTV.