The IAB Tech Lab published OpenRTB 2.6 this spring, a notable update to the OpenRTB protocol designed to improve how connected TV (CTV) inventory is transacted.
For a little over a year, IAB Tech Lab worked with Index Exchange and several other leaders in the industry to develop industry standards that would solve today’s most common CTV challenges. The result is OpenRTB 2.6, and it’s a huge step forward for digital advertising. The spec accounts for the intricacies of TV within a programmatic environment, and will be instrumental in scaling CTV.
We encourage all media owners, buyers, and technology providers to adopt OpenRTB 2.6. Here are the 10 new features we’re most excited about.
1. Support for ad podding
For years, our industry has lacked a standardised approach to signalling the availability of podded supply in CTV and other over-the-top (OTT) video. Ad pods, which are groups of multiple ads that run one after another, are akin to traditional linear TV ad breaks and are commonly used in CTV. However, there hasn’t been a clear and easy way to replicate the TV ad break experience in CTV, which requires maintaining competitive separation and avoiding duplication within an ad pod.
OpenRTB 2.6 introduces features that allow buyers to target their bid responses to various positions within an ad pod, and allow media owners to set a CPM per second bid floor (as opposed to a static floor).
Media owners and buyers can better replicate the TV ad experiences consumers are accustomed to, while benefiting from the targeting and measurement capabilities that only programmatic can offer.
2. Implementation guidance for flexible ad podding
OpenRTB 2.6 also introduces the concepts of structured, dynamic, and hybrid ad pods to flexibly meet the needs of a number of different video and audio use cases.
- Structured pods: fixed number of ads, all with specific lengths
- Dynamic pods: fixed duration for the ad break with flexibility in the number and length of ad slots
- Hybrid pods: combination of structured and dynamic pod features
OpenRTB 2.6 documentation provides realistic examples of CTV bid requests and responses to demonstrate each of these scenarios and how to use the new fields. This implementation guidance will go a long way in creating a standardised approach to CTV and OTT monetisation by ensuring that media owners and buyers interpret the spec consistently.
3. Implementation guidance for impression counting
While OpenRTB provides a rich set of capabilities for bid requests and responses, it hasn’t taken a strong position on how buyers and sellers should treat billing notifications. Without a standardised approach, media buyers (often with guidance from the MRC) tend to set the terms for when to count impressions as delivered and billable. This has led to fragmentation in the way impressions are signalled and counted.
OpenRTB 2.6 offers best practices for how media owners should indicate billable events to DSPs, SSPs, and media buyers in both client-side and server-side beaconing scenarios. It also includes guidance from other IAB Tech Lab standards, including VAST 4.X and ads.cert, to improve resilience against fraud and bad actors. This guidance standardises expectations and will lead to better interoperability and fewer impression discrepancies between media owners and buyers.
4. Adoption of new taxonomies
In previous OpenRTB versions, media owners and buyers used the IAB’s Content Category Taxonomy in a number of places (for example, in providing the category for a site or app, for a specific section or page within that site or app, or for banned creative categories). Originally designed for the web, this taxonomy was limiting as it didn’t enable unique descriptors for content, ads, and audiences.
OpenRTB 2.6 enhances this categorisation with the new cattax field that clarifies which taxonomy is used in bid requests and responses. Media owners and buyers can agree on custom taxonomies, or use the ones IAB Tech Lab has provided:
- Ad Product Taxonomy
- Audience Taxonomy
- Content Taxonomy
5. Richer metadata for CTV
There are new objects to represent the concept of network (for example, a content licensor or owner like A+E Networks) and channel (such as The HISTORY Channel and Lifetime) in bid requests, which help clarify CTV inventory relationships. This additional context helps buyers understand the content in which they’re placing their ads so they can ensure it’s the best fit for their brand.
6. Support for Structured User-Agent information
Chromium-based browsers (including Google Chrome and Microsoft Edge) are beginning to freeze User-Agent strings to prevent device fingerprinting and improve consumer privacy. Browsers are instead replacing the legacy User-Agent with a new set of HTTP headers and Javascript APIs to provide User-Agent Client Hints.
As a result, RTB buyers can’t rely on the legacy User-Agent string to target device-level information, including device make, model, and operating system. OpenRTB 2.6 introduces the sua (Structured User-Agent) field within the Device object to allow media owners to transmit device-level information derived from these new User-Agent Client Hints to buyers.
7. Better expectation setting for SSAI
Server-side ad insertion (SSAI) technology is commonly used to deliver CTV 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 (known as beacons) in diverging ways.
OpenRTB 2.6 introduces a new ssai field within the Imp object that allows a media owner to notify SSPs and DSPs whether creative asset stitching and beaconing happen from the client-side or server-side.
This signal not only indicates the quality of the viewer experience, but also potential fraud. For example, if a media owner indicates that beacons should originate from the client, SSPs and DSPs should be skeptical of billing notifications originating from a server, or datacenter IP.
8. Support for rewarded ads
Media owners and buyers used to rely on a number of non-standardised extensions to signal rewarded ad opportunities, in which consumers engage with an ad in exchange for a reward such as in-game currency. The OpenRTB 2.6 spec introduces a standardised way to acknowledge that any type of impression opportunity may be a rewarded experience by adding the rwdd field to the Imp object.
9. More helpful video and audio bid responses
In previous versions of OpenRTB, media owners had to inspect the contents of the ad markup (adm) field to determine the creative type in a bid response. This was particularly challenging for multi-format requests, which could be eligible for banner, video, or native bid responses. For video or audio creatives, media owners also had to parse that markup (a VAST document, which was often a Wrapper to another VAST) to determine the duration of the creative.
The Bid object in OpenRTB 2.6 contains two new fields that help buyers remove all of that inference work for media owners, allowing new creatives to serve more quickly:
- dur: indicates the duration of the video or audio creative in a buyer’s bid
- mtype: indicates the type of creative (banner, video, audio, native) in a buyer’s bid
10. Lists now reference AdCOM 1.0
All of the enumerations (lists) for attributes in OpenRTB 2.6 objects now point to the AdCOM 1.0 GitHub. One of the problems with 2.5 was that updating out-of-date lists required publishing an entirely new version of the spec. Using the AdCOM GitHub for lists means that the ad tech community can add or amend values over time, regardless of whether or not the OpenRTB spec is updated.
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 the CTV ads of the future.
Now that the standards are defined, it’s time for the market to support and adopt them as soon as possible.
What impact has the OpenRTB 2.6 spec had on the streaming TV landscape since its release in 2022? Read our most recent update to learn more.
