OpenRTB 2.6, Pod Bidding, and CTV Context

The IAB Tech Lab finalized OpenRTB 2.6, and the specification contains new additions that will enhance programmatic connected TV buying. The additions focus on two areas that any company working with programmatic CTV has grappled with at one point or another: ad pods and context.

Programmatic advertising (mostly) works because all the companies that partner to buy, sell, and deliver ads speak the same language by agreeing to follow specifications like OpenRTB. But ORTB and its video ad creative delivery sibling, VAST, do not cover all use cases. SSPs, DSPs, ad servers, and even SSAI vendors have to come up with and agree on additions to the specifications if they want to add new features not supported in official versions.

It is much easier to agree on a version of ORTB or VAST than to go back and forth to figure out each integration partner's particular way of handling custom changes to a bid request, bid response, or VAST response.

ORTB 2.6 addresses a few scenarios that would have previously required custom development to accomplish.

Pod Bidding

The IAB Tech Lab has included multiple new fields to assist with the ad pod bidding process. Pod bidding is the term they've assigned to a collection of new fields that enhance buying ad pods. I won't explain each new field but instead review two of the most important new features. But first, let's take a look at some existing problems with ad pods.

Ad pod problems

Even if you are unfamiliar with ad pods, I can almost guarantee that you have experienced them. These are the commercial breaks of multiple ads in between digital video content. When a user reaches an ad pod, an ad player will display how many ads are in the pod and which ad they are currently viewing (ex. 2 of 5).

Ad pods can serve as a stage to display some embarrassing hiccups of programmatic advertising. They may appear simple to the end-user, but these little devils can cause quite a stir because the industry has not developed concrete standards to deal with them. The two main issues are ad duplication and lack of competitive separation.

Ad duplication means the same ad runs in a single ad pod. Duplicate ads can create a poor user experience and negatively impact brand perception.

Competitive separation is the idea that an advertiser's ad will not deliver in the same ad pod as a competitor in the same industry. An example is a Ford F-150 ad running in the same pod as a Chevrolet Silverado ad.

An SSP can signal multiple slots of a single pod by including multiple video impression objects. By signaling that multiple slots are available in the same pod, SSPs allow DSPs to apply competitive separation and de-duplication logic on their side before returning a bid response.

But SSPs also sometimes allow multiple DSPs to bid on slots in a single ad pod. SSPs could allow multiple DSPs to fill an ad pod either because the SSP wants to maximize their coverage or because a single DSP couldn't fill an entire pod or did not understand the best way to fill the ad pod.

It is up to the SSP to apply competitive separation if multiple DSPs participate in an ad pod. SSPs can apply rules to de-duplicate ads or enforce competitive separation by observing the adomain (advertiser domain, like ford.com) and cat (IAB category) fields in a bid response.

If a single DSP buys an entire ad pod, they can perform ad de-duplication and competitive separation on their side. But they are missing one crucial piece of metadata to properly buy a whole ad pod — the exact ad pod duration.

Dynamic Pods

One of the new fields in ORTB 2.6 is called poddur, and it communicates to a DSP the length of an ad pod. SSPs will only send the poddur field in a bid request if they are facilitating a "dynamic" ad pod. Dynamic ad pods are more flexible than a "structured" ad pod which predefines the exact number of ads and their acceptable duration.

Dynamic pods provide the length of a pod and allow a DSP to fill an entire ad pod in the most optimal way while considering delivery and pricing.

For example, if a seller communicates a pod duration of 60 seconds, a DSP can decide to include two 15-second ads and one 30-second ad for a total pod length of 60 seconds. Before pod bidding (and without custom ORTB fields), an SSP could only communicate how many slots are available and provide a minimum and maximum duration.

But let's say they indicated that four slots are available and set a minimum duration of 15 seconds and a maximum duration of 30 seconds for the same ad request of a 60-second ad pod. If a DSP returned four 30-second ads, an SSP would have to drop two of their ads. The DSP would have no way of knowing that an SSP would drop their third and fourth ads because the entire pod is only one minute long, and their ads totaled two minutes.

With dynamic pods, DSPs can ensure they only return the correct total duration of ads. Understanding pod duration could:

• Lessen the chance for other demand sources to snipe spots in a pod if an SSP drops one of their longer ads

• Allow a single DSP to control the entire pod and all the de-duplication and competitive separation rules

• Empower a single DSP to fill a pod in the best way they decide

ORTB 2.6 also introduces another new field that can open the door for more precise pricing optimization when used in conjunction with dynamic pods.

Per-second Price Floors

The mincpmpersec field is another new addition under the pod bidding umbrella of enhancements that allows sellers to set a floor rate for each second an ad runs. So, for example, a $2 value would signal that the floor price is $30 for a 15-second ad and $60 for a 30-second ad.

The mincpmpersec field gives publishers the capability to price out every second of air time. This field helps buyers and sellers establish a more precise bid floor. The existing bidfloor field can only communicate a single floor price for a given ad slot, but that slot could accept ads of varying lengths.

A per-second price floor allows buyers to decide how to fill dynamic pods in the most efficient way possible and makes sure sellers receive the best bang for their buck. Sellers don't want to set the same floor price for a 15, 30, or even 60-second ad. Now buyers will know exactly how much sellers will expect for each second of air time.

The poddur and mincpmpersec fields give publishers, advertisers, and their ad tech providers much more flexibility in buying video ad pods. Pod bidding also introduces the concept of hybrid ad pods that allow the mixing of standard and dynamic sections. So some programmatic participants may choose various ways to employ these new features.

CTV Context

Contextual targeting has made a strong comeback on the web with the impending loss of cookies, but context can also play a crucial role in CTV ad buying.

ORTB has had an entire content object available for publishers to communicate things like show title, genre, and series (ex. The Office). Buyers can use these contextual signals to decide how to bid in real-time or for reporting and forecasting. But ORTB doesn't contain all the context fields that everyone desires, and there is a severe lack of contextual value standardization.

CTV context problems

Context has always presented a challenge on CTV due to a lack of contextual standardization. Programmatic CTV advertising platforms don't always follow the same rules around expected contextual value format or use the same predefined lists of expected values for things like genre.

Publishers can ask for video ads from their SSP by making an ad request to a VAST URL, and they often use custom parameters tacked on to VAST request URLs to indicate contextual information. (If you need to brush up on VAST, check out this article).

Although, a glaring issue with VAST is that most ad platforms only follow a standard for their VAST response but not for a VAST ad request. The lack of request standardization means that the parameters appended to ad requests vary from platform to platform and the values passed in those custom parameters often lack any standardization.

If Ad Tech Explained had a CTV app, an example VAST request with contextual information could look something like this:

From this request, you could ascertain the following contextual information:

• Show Title = Adventures in Ad Tech

• Channel = ATE

• Network = Ad Tech Explained

• Genre = Education

I would only know to append parameters like genre or show_title to my VAST request by discussing with my SSP technical support team or reading documentation. These are not standard IAB fields, and they will vary from platform to platform.

So either the SSP provides guidance on what to pass, or I include whatever I want, and it's the SSP's job to clean it up. If my SSP wants to communicate context in an outgoing bid request, they can map what I pass in the custom VAST parameters to existing ORTB fields or use custom extensions in ORTB to communicate the values.

Is education even a genre? Who knows! Should I include dashes in my show titles and series names? Maybe! Is there a standardized list of acceptable channels? Nope!

It is up to the programmatic partners (SSP, DSP, Publisher) to determine what contextual values they should pass in ORTB bid requests and what fields SSPs should set those values. They must agree on a format or if they even want those values at all.

ORTB 2.6 does not fix this lack of value standardization, but it does introduce two possibly valuable fields that make sure to include a vector to link their values to a standard format expectation.

Channel & Network

A considerable chunk of CTV inventory originates from Virtual Multichannel Video Programming Distributors (vMVPDs) like Pluto.tv or SlingTV, digital apps that mimic the cable TV experience with specific TV channels and a guide.

The same content can flow through different channels on a vMVPD, and buyers may be interested in understanding which channels the content appears on before making a buying decision.

The only way to accomplish this before ORTB 2.6 is to customize a bid request to include channel and network information. An SSP would have to tell a DSP to look out for these custom fields so they can make bid decisions or build reporting based on them. But ORTB 2.6 now supports a channel and network object to communicate this information.

I can watch Seinfeld reruns on Comedy Central and my local Fox affiliate. So if I watch Seinfeld, a vMVPD can communicate to a buyer that it appeared on either Comedy Central or Fox using the channel object.

They can also populate the network field to communicate what entity owns the channel. So if an ad request originated from the Comedy Central channel, the network would be Viacom. If the ad request originated from the KDVR (Denver's Fox affiliate) channel, the network would be Fox.

Although the ORTB 2.6 spec does not introduce any standardized value list for channel or network names, it supports a domain field on the channel and network objects to help everyone pinpoint what each channel and network name represents.

So, for example, if a publisher passed "CMDY" as a channel name, you may not know what that means, but they would also include a domain name in the channel object with a value of "cc.com" (Comedy Central's domain). Now everybody knows we are talking about Comedy Central.

Now that the IAB Tech Lab finalized ORTB 2.6, it is up to platforms to decide whether or not to adopt the new additions. The addition of pod bidding and channel/network fields offer solid incremental additions but will require an allocation of development resources for any platform to adopt. Now ad tech partners and their clients will decide if ORTB 2.6 provides enough value to warrant the upgrade.

Subscribe to the Ad Tech Explained Newsletter

Ad Tech Explained provides explainers, insights, and analysis on the latest trends in advertising technology.