Content Metadata for Programmatic Video Advertising Explained

Advertisers want to know what you are watching. Unsatisfied with the heap of metadata already available in programmatic bid requests, buyers are becoming emboldened to ask publishers to share more content metadata — information that describes the shows or movies users watch.

Should publishers inform buyers about the video content their users watch or consider passing more information than they do today? Are publishers allowed to provide detailed data about user content consumption? And what even is content metadata, and how is it passed to buyers?

What is content metadata?

Many values in a typical ORTB bid request represent table stakes for advertisers to purchase a publisher's inventory. Typically, the value of publisher inventory rapidly declines with each signal they choose to omit from bid requests to DSPs.

The capabilities of DSPs and advertisers diminish if publishers do not share a domain/ bundle ID, user agent, and some identifier (IFA, IP address, etc). Advertisers and DSPs use these signals to perform necessary functions that power programmatic purchases like app/site targeting, fraud detection, frequency capping, and geolocation.

But even if publishers pass all the baseline signals required to purchase programmatic video inventory effectively, advertisers always want more, and their insatiable desire for user information has turned their gaze upon content metadata. Content metadata is the collection of values describing the content an advertisement runs alongside.

Advertisers and their buying platforms transacting on OTT inventory are looking for all the video-specific signals outlined within the content object of the OpenRTB specification, which includes:

• Title

• Series

• Genre

• Content Rating

• Category

• Length

• Producer

• Production Quality

• Livestream (yes/no)

• Language

• Network

• Channel

Configuring Content Metadata

A publisher can configure their SSP to include these content attributes within bid requests sent to DSPs. DSPs read these values to understand the content that potential ads will run alongside.

Many SSPs do not support all of the above attributes, and configuring them varies by platform. SSPs adopt each ORTB field based on industry acceptance and publisher feedback. For example, the network and channel attributes are brand new as of ORTB 2.6 and may take time to gain enough adoption from the buy side to warrant any SSP to include as a feature for its publishers.

As long as SSPs pass a content object filled with fields defined from the ORTB spec, a DSP shouldn't break, but they may choose to ignore unsupported fields.

Here is an example of how a content object is formatted:

"content": {
"id": "1234567",
"series": "That Funny Show", 
"season": "4",
"episode": 27, 
"title": "The Funny Episode",
"cat": [ "IAB2-2"],
"contentrating": "tv-ma",
"len": "1440",
"prodq":1,
"genere":"comedy",
} 

SSPs include this object in the complete OpenRTB bid request sent from a publisher's SSP to a buyer's DSP. The above example describes an episode from a fictional TV show called "The Funny Show" that's 24 minutes long (1,440 seconds), is professionally produced (prod = 1), and is a comedy.

Publishers populate these values by either:

1. Passing content signals in VAST ad requests

2. Piping the metadata from their CMS (content management system) into their ad server

SSPs will define specific parameters publishers can use to pass information in VAST ad requests. Check out this article on VAST to learn more about how this process works. An ad request could carry content metadata information, for example:

http://adtechexplained.com/vast/1234?page_url=examplepublisher.com&contentTitle=The_Ad_Tech_Show&contentGenre=comedy&contentRating=TVMA

The above VAST request tells the SSP that ads will serve alongside "The Ad Tech Show," everybody's favorite TV-MA-rated ad tech comedy show. An SSP will use this metadata to populate the content object of outgoing bid requests to DSPs.

It's also worth noting that an SSP or ad server can use this same method to pass content metadata to a secondary SSP. Publishers can plug VAST tags from a secondary SSP into their primary SSP or ad server and pass content information along using macros.

Macros are special values an ad platform defines that publishers insert into a VAST tag to provide information about the request. SSPs dynamically swap macro values with information based on any incoming ad request.

An example VAST tag populated with content metadata macros could look like the below:

http://secondaryssp.com/vast/5678?page_url={page_url}&contentTitle={content_title}&contentGenre={content_genre]&contentRating={content_rating}

Publishers can traffic this VAST tag in their primary SSP or ad server, and if the same ad request from our first example hits that primary SSP or ad server, the ad platform will propagate the same values passed in the original ad request by replacing the macro values in the brackets.

The final request to the secondary SSP would look like this:

http://secondaryssp.com/vast/5678?page_url=examplepublisher.com&contentTitle=The_Ad_Tech_Show&contentGenre=comedy&contentRating=TVMA

Publishers can also pipe metadata from their CMS (content management system) into their ad server to configure content metadata values.

This process will look different depending on the CMS or ad server. The ad server must have content metadata values associated with every piece of content a publisher wants to describe to a buyer. The ad server will know which metadata to pass based on a content identifier shared in an initial ad request.

A sample VAST request to an ad server would now only need a content identifier rather than keys and values describing the content:

http://adtechexplained.com/vast/1234?page_url=examplepublisher.com&cid=123456

Rather than explicitly passing content metadata, we only include a content identifier (cid=123456) in the ad request to the ad server.

The platform now looks up the content metadata associated with the "123456" content identifier and injects these values into outgoing bid requests to DSPs (if you are using an ad server + SSP combined platform) or dynamically replaces associated macros in VAST tag calls to external SSPs.

Why do buyers want content metadata?

OTT publishers should care about content metadata because buyers increasingly ask for or even require it. But why do buyers want content metadata anyway?

There are multiple answers to this question, so let's start with the simple solution and then move on to more advanced reasons.

Controlling Ad Placement

The simple answer is they want to control which content their marketing messages are running next to. Advertisers power ad placement and decide where their ads run by including and excluding specific content metadata on campaign targeting settings.

An example of an include targeting scenario would be an automaker desiring to run ads for a new sports car alongside a NASCAR or Formula 1 race. There is a reasonable chance that racing fans like fast cars and may be interested in purchasing one.

An exclude targeting scenario would be an airline advertiser NOT wanting to run their ad next to the first episode of LOST — an episode with an opening crash scene that does not evoke a strong desire to board a plane.

DSPs offer tools to allow advertisers to target their video ads using all the same fields a publisher passes in a content object. These tools would live in the targeting section of a DSP UI that buyers configure when setting up an ad campaign.

So in the first scenario, a DSP could inspect the category field in a bid request, and if an automaker targeted the category "Auto Racing," the DSP can choose only to serve ads when content.cat = "IAB17-1," the IAB auto racing category.

A DSP could inspect the "episode" and "series" attributes in the second scenario, looking for content.series = LOST and content.episode = 1, so they know which episode to de-target.

The above two examples are specific, and the second scenario is quite unlikely. It would be very unusual for a human to de-target particular series episodes (especially one nearly twenty years old). But it simply illustrates how a DSP can interpret a content object for such fine-grain control of targeting.

The likely scenario is that DSPs and buyers use content metadata to buy inventory algorithmically.

Content Metadata Input Signals

Buying specific categories, series, or episodes is so old school. Programmatic advertising opened the door for automating processes once reserved for media-buying humans but are now outsourced to machines.

Advertisers have a few options if they want to purchase premium CTV inventory. They can choose to only work with whoever they consider premium (or let their agency figure that out) or rely on DSP technology to weed out the lower-quality riff-raff.

DSPs can use the content metadata publishers send to score inventory based on the quality of content signals they provide. By distilling an amalgamation of content information into a neatly packaged number, DSPs can provide an easier way for buyers to target "quality" CTV inventory. Buyers can then set score thresholds for publishers to clear targeting filters and access advertising spend.

Additionally, buyers can use log-level data provided by DSPs to analyze if specific common content metadata values are present in inventory registering higher KPIs. For example, if patterns emerge where users convert at an elevated rate on any inventory carrying a "comedy" genre, an advertiser would want to spend more on that specific genre across all publishers.

Buyers can use content metadata as an entirely separate set of input signals outside the standard values on every programmatic bid request to drive their buying decisions — in an age where data is king, buyers and their technology partners can use any extra piece of metadata provided to give them an edge to optimize their spending.

The drawbacks of content metadata for publishers

The benefits of content metadata may be readily apparent for buyers, but it's not so cut and dry for publishers. Publishers must contend with the realities of privacy law and possible conflicts with sales strategies.

VPPA

Before sharing information about what users are watching, publishers must consider The Video Privacy Protection Act (VPPA), passed in 1988 after a Washington Post reporter published the leaked video rental history of supreme court nominee Robert Bork during his Supreme Court confirmation hearings.

Despite being a reaction to the revelation of Bork's analog rental history, plaintiffs have attempted to apply the law to modern-day digital streaming video. Digital publishers like Cartoon Network and Hulu have had to defend themselves on VPPA-related cases because the companies allegedly shared content metadata alongside personally identifiable information like device IDs and cookies without user permission.

Publishers must carefully consider the VPPA before spraying content metadata alongside any identifier that could be linked back to an individual, such as device ID, IP Address, cookies, PPIDs, or universal identifiers, lest they become the next target of privacy litigation.

Conflicting Sales Strategies

Publishers with robust sales teams may want to minimize the content metadata shared in bid requests to carefully control the targeting available to buyers to maintain established sales strategies.

Publishers may package their inventory into programmatic deals in particular ways, and giving an advertiser a vector to "cherry pick" only the best inventory may leave the rest of their supply unpurchased on a dusty shelf.

Maybe a publisher has a hit show that every advertiser wants to run alongside — if a publisher shared this series name in bid requests, then that show might see an outsized amount of interest from buyers and leave them with supply constraints. Older and less desirable series could stay unsold while the hit new show faces a dearth of availability.

Publishers could employ less heavy-handed tactics, such as dynamic pricing adjustments, to combat these issues. Some video SSPs provide tools that allow publishers to adjust the price of particular sets of inventory based on the presence of specific inventory attributes.

For example, if Netflix chose to pass content.series in OpenRTB bid requests, they could protect the supply of "Stranger Things" by implementing a price rule to add $10 to their already astronomically high $55 CPMs anytime their SSP detected this metadata value. The SSP would look for that inventory attribute on an incoming VAST ad request (series=Stranger_Things), and then their SSP would increase the CPM in bid requests to DSPs to $65.

Publishers can accomplish the same by crafting deals based on content attributes. Netflix could create a higher-priced "Stranger Things" deal by targeting the series and excluding it from all other deals. But this task is much more laborious and backward-thinking when more advanced tools are available to adapt to different pricing scenarios in real time.

The Case for Content Metadata

Despite the potential drawbacks publishers may face by sharing content metadata with buyers, publishers may eventually have no choice but to include it.

Agencies are consolidating their power to demonstrate value for advertisers, and one move they could employ is to force publishers to give up content metadata under the threat of withheld spending.

The reality is that premium publishers or publishers with large sales teams and a penchant for selling the "old school" upfront way are competing against lower quality or digital-first publishers with more to gain by including content metadata.

Upstart video publishers or vMVPDs with endless inventory may include content metadata to give themselves a leg up on their older siblings who don't want to share their content metadata toys. Buyers algorithmically purchasing inventory may care less about the perceived "premium" nature of inventory and would prefer to optimize for outcomes with content metadata as crucial input signals.

Not all video publishers are ready to reveal their content metadata hand yet, due to privacy concerns or conflicts with their established sales strategy — but there are ways to reap the benefits of content metadata without going all in. Publishers could pass signals like genre or rating that throw advertisers a little bone for optimizations but don't leak any data about the show or series a user is watching.

Publishers can also charge higher rates for any inventory that includes content metadata by creating separate programmatic deals that include content metadata or by dynamically raising prices in real time based on the presence of specific content metadata.

Wise publishers can employ these tactics to protect their pricing and possibly realize net revenue gains if advertisers and their agencies force their hand — but it is understandable to be wary of the implications of providing more metadata. Like a stray cat pawing at your back door, once you feed an advertiser a piece of content metadata, they may only come back asking for more next time.

Subscribe to the Ad Tech Explained Newsletter

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

Photo by Rachit Tank on Unsplash