Connected TV (CTV) growth is booming with ad spend expected to reach $21.2 billion this year, according to the IAB. Yet programmatic technology is still falling short in enabling an optimal ad break that meets the expectations of media owners, buyers, and viewers.
In fact, Watching That estimates about 15% of programmatic CTV inventory goes unfilled—resulting in a loss of more than a billion dollars.
CTV relies on ad podding to group individual ads together in one commercial break. Ad pods need to manage duplication, competitive separation, latency or buffering, and frequency capping—all key to replicating the quality, lean-back broadcast TV viewing experience in CTV.
Many programmatic tools and standards were established for web and display, and they simply weren’t designed to support the needs of media owners and buyers in CTV.
For example, the OpenRTB 2.5 protocol developed by the IAB Tech Lab has been widely adopted in the world of programmatic and is by many measures a very effective standard. However, it was published in 2016 before the rise of programmatically sold video ads in CTV and other over-the-top (OTT) environments.
The industry figured out some rudimentary ways to trade video ad pods using OpenRTB 2.5, but it led to sub-optimal viewer experiences and may have stunted the growth of programmatic CTV.
Fast forward to 2022. The IAB Tech Lab published OpenRTB 2.6 this spring with the aim of solving these podding challenges in CTV. We’re extremely excited about the new features in OpenRTB 2.6, and we’re proud to have contributed to its release.
So how does OpenRTB 2.6 improve CTV ad pods, and why should the whole industry start adopting it?
OpenRTB 2.6 was designed specifically with the nuances of CTV and ad podding in mind. It introduces a standardised approach to signalling the availability of podded supply in CTV and other OTT video—something our industry has lacked for years.
Here are three ways OpenRTB 2.6 fixes the shortcomings of OpenRTB 2.5 and helps recreate TV-like ad experiences for media owners, buyers, and viewers.
1. Duplicate ads
With the controlled delivery and largely manual ad selection in broadcast TV, viewers almost never see repeated or duplicate ads. Programmatic technology has been limited in replicating that experience in CTV, frustrating marketers, content creators, and viewers alike.
Using OpenRTB 2.5, media owners have two ways to send bid requests for podded impression opportunities: several uncorrelated bid requests or one multi-impression bid request.
There are several problems with these approaches. The primary issue with uncorrelated bid requests is that recipients typically can’t treat them as requests within one contiguous ad break, or pod. So buyers might return the same creative multiple times, leaving media owners and supply platforms to throw out duplicate bids.
Media owners can send these uncorrelated bid requests serially, signalling advertiser exclusions for bids they’ve already received. While this reduces duplicate ads, it increases latency and the need for long tmax values (the OpenRTB parameter that tells a buyer how long they have to return a bid before the response times out).
Multi-impression bid requests are an improvement, but many buyers don’t support them. Additionally, there’s no standard defined to distinguish a video ad pod from several individual video impressions within one request, so some buyers may still return multiple instances of the same creative.
OpenRTB 2.6 takes aim at duplicate ads by clearly delineating ad pods from multi-impression video requests, allowing media owners to dictate a clear structure to those ad pods. This gives buyers all the information they need to send back well-informed bids without duplicates or competitive clashes.
2. Ad pod geometry
Media owners each have various ad monetisation needs. Some prefer to capture as much revenue as possible out of ad breaks with a fixed length; others prefer to show the fewest ads possible while still meeting their monetisation goals. Some are flexible with the duration of ad pods; others require precise ad durations to avoid dead air during livestream broadcast transmissions.
OpenRTB 2.5 can’t account for these preferences as it only allows media owners to provide minimum and maximum ad durations for each position in a pod, and a static CPM bid floor.
OpenRTB 2.6 introduces the concept of structured, dynamic, and hybrid pods, along with a number of additional fields that allow media owners to express the “geometry” of the ad pod that they want to fill.
For example, they can ask buyers to fill ad pods of a given duration with a capped number of creatives using the poddur and maxseq fields in the bid request. Media owners can also specify dynamic bid floors based on CPM per second using the mincpmpersec field. Or they can use the rqddurs array to specify a precise allowable duration for each ad position.
3. Ad pod and slot positions
In broadcast TV, different ad breaks within a show, or even the different positions within an ad break, command different prices. OpenRTB 2.5 has no standard way to delineate between multiple pods or positions, and media owners and buyers typically treat bids simply as a collection of creatives for media owners to arrange at their discretion.
OpenRTB 2.6 introduces podseq, which media owners can use in the bid request to indicate whether a given pod is the first, last, or in the middle of a program. The slotinpod field indicates the same positions within an ad pod. Media owners can even assign a podid to each pod, so that multiple pods can be sold with a single bid request.
On the flip side, buyers can choose which pods to bid on and use the slotinpod field in their bid responses to target specific positions within those pods.
It’s time to support and adopt OpenRTB 2.6
OpenRTB 2.6 is a major step forward in the capabilities it affords media owners, buyers, and ad tech providers. It begins to redefine the standards for CTV and opens a rich marketplace that will help TV realise the true value of programmatic advertising. And, it ultimately enables a better viewer experience.
We’ve already begun to implement OpenRTB 2.6 at Index. We recommend media owners and buyers join us in supporting it as well, as we believe OpenRTB 2.6 will soon become table stakes.
If you’re looking to better understand OpenRTB 2.6, how to use it, or how to interpret it, please don’t hesitate to contact our team. When you’re ready to take advantage of these new features, we’ll be here to support you.
