Tags: VAST VPAID Wrapper Video advertising Ad Tech
“Wrappers” are a very common construct in online video advertising. They allow various tech vendors—often verification companies—to hook into the ad delivery chain to enable measurement, verification, viewability and brand safety among others.
While wrappers have a valuable place in the industry, they come with a ton of challenges because they apply industry standards beyond what they were originally designed for.
What most people don’t realize is that there are different wrapper flavors, each with different capabilities and limitations. We’ll take a detailed look at them, their problems and possible solutions in this series of posts. I would also like to dive deeper into how wrappers caused VPAID to have such a bad reputation with publishers.
At Zentrick, we build and operate large wrapper deployments for many of the major verification companies, processing many billions of impressions on a monthly basis. I think we’re uniquely positioned to clear up some of the mystery around them.
Whether you’re totally new to the industry or a long-time veteran, I promise you’ll learn something new!
There are a handful of standards that play a critical role in video advertising today. Explaining each in detail is out of scope for this series, but understanding how they’re interconnected is definitely going to be helpful.
First, let’s split the ad execution into three stages, each with its own IAB specification:
For the purposes of this article, we’ll focus on the “Serve” and “Execute” stages. More specifically, we’ll reference two IAB specifications:
VAST (Video Ad Serving Template) as a data format used by ad servers to describe all the metadata related to a video ad such as links to the video ad in various file formats, tracking pixels and click through information
VPAID (Video Player Ad Interface Definition) as an API used between video players and video ad creatives so that the latter can run code on the client as part of the ad execution.
If you want to learn more, it can be helpful to read the executive summaries for each of these specifications.
While a simplistic model of an ad’s execution would involve a publisher on the one hand and an advertiser on the other, reality is rarely that simple. Any random ad execution may involve a dozen other parties: a supply-side platform, an exchange, a demand-side platform, one or more verification companies, an ad server, one or more data management platforms, etc.
Each of these parties adds specific value to the ecosystem and often requires their respective platforms to be included in the ad execution to some degree:
A data management platform might want to fire a tracking pixel to identify audiences.
A verification company might want to run code to measure viewability, detect fraud or provide brand safety.
An SSP might want to fire a tracking pixel for every impression, for billing purposes.
The business case for all types of wrappers is the same: to allow an intermediary party to participate in the ad execution. We’ll use the term “intermediary” moving forward to refer to these value-added partners.
Yet different wrapper flavors come with different capabilities and limitations.
Let’s take a look at the various types of wrappers that exist and how they compare to each other. I’m going to base the comparison on three key factors:
Latency. To what extent does it impact the load time and performance of the ad and the user experience.
Reliability. How likely is it to fail, break inventory or cause unexpected results.
After a transaction settles, the video player wants to start executing the winning bid. It needs to know about the creative files and which parties need to get called at which time. All of this information is encoded in the VAST document provided as part of the winning bid.
In its simplest form, the video player requests the VAST document from a video ad server.
This requires the advertiser to set everything up in advance on their ad server and for the ad server to maintain integrations with all vendors that the advertiser may want to add. This can cause a lot of operational overhead, complex integrations and manual workflows.
That’s why the VAST specification includes the concept of a VAST
Wrapper. It allows one VAST document to point to another, which in turn can reference another and so forth. The video player follows this chain of
Wrappers which needs to end in a VAST
InLine response that mentions the actual video files to play back.
The concept of VAST wrappers is very useful for intermediaries like DSPs, SSPs or technology vendors to add simple forms of analytics or measurement in the form of tracking pixels.
Yet there are several major limitations to these VAST wrappers:
Latency. The video player needs to load the wrapper chain as a sequence of HTTP requests. Every wrapper in the chain delays playback of the ad by hundreds of milliseconds on mobile connections.
Reliability. If any of the intermediary VAST requests fail, the player never reaches the media files and ad execution fails altogether, but we’ll see that this will be the case for any type of wrapper.
Unfortunately, simple VAST
Wrappers don’t offer a lot of capabilities. If you want to run any kind of custom logic to track your own custom events, offer an interactive user interface, measure viewability or provide brand safety checks, you need the ability to inject code into the ad.
Traditionally, the industry has solved this problem with what we’ll call “client-side VPAID wrapping”. In this scenario, the intermediary party hosts its own VAST
InLine document that replaces the original VAST
InLine document from the ad server. This intermediary VAST points to a single VPAID creative file, also managed by the intermediary.
Once that VPAID creative is loaded by the video player, it initializes any custom code, loads the original ad server VAST document and executes it, acting as if the intermediary VPAID itself were the video player.
It’s important to note that VPAID was not originally designed with this use case in mind. It’s sole purpose was to standardize interactive video creatives. Ironically VPAID is mostly used for wrapping today, while interactivity remains the exception.
As one would expect, repurposing VPAID like this opens up a can of worms:
InLineVAST supports anything the VAST
Latency. Unfortunately, the video player needs to make one more network round trip to fetch the intermediary VPAID creative file, bringing the total to two network round trips. On mobile, this often means more than a second of additional latency.
Reliability. The biggest problem with this approach is the various ways it breaks in the real world. We’ll cover the issues one by one.
The intermediary VAST is supposed to tell the player about all sorts of metadata. Yet the intermediary doesn’t know any of this unless it was statically configured with it ahead of time.
In practice this means that the intermediary VAST often reports wrong information: claiming the ad is 30 seconds long while it’s actually 15 seconds, dropping companion ads, reporting the wrong aspect ratio, etc.
This problem becomes even worse when the wrapped ad server applies ad rotation, where the metadata could change with every run. In this case the information can’t even be pre-configured in the intermediary VAST.
The intermediary VAST only references the intermediary VPAID creative, nothing else. Even if the ad server VAST hidden behind the intermediary does support regular video files, the video player never gets to see or consider them.
Many platforms like mobile and OTT have very limited to no support for VPAID. Those platforms have no alternative but to fail and forego the impression. While there’s limited information publicly available about the market adoption of VPAID, an analysis by Ian Trider from Centro has shown 90% adoption on desktop and 10% on mobile.
Note that since the intermediary VPAID is never loaded in such case, it also won’t load the ad server VAST and the ad server will not even be notified of this failure.
In a perfect world, the wrapper should still allow non-VPAID players to fall back to regular media files. Although the ad would lose some capabilities, it would at least still work.
From the video player’s perspective, it only sees the tracking pixels defined by the first, intermediary VAST. Any pixels in the ad server VAST are hidden from view by the intermediary VPAID creative, which now needs to take responsibility for tracking these.
If that intermediary VPAID fails or breaks for some reason, the ad server behind it will not receive any information: it will simply observe that its VAST document was requested but no tracking was ever fired.
The problem becomes even worse as more wrappers get involved, where each wrapper is responsible for tracking the pixels of the next link in the chain:
Given that wrappers often map to individual verification vendors, this ironically means that each vendor is responsible for tracking data for their competitor who’s next in the chain. Would you trust your competitors to track your data?
It’s bad practice to have multiple parties responsible for tracking what should be the same information. This is a major source of measurement discrepancies between various measurement vendors, publishers and advertisers.
A better approach would be to make sure that only one party, preferably the video player, is responsible for firing all tracking pixels.
While VAST wrappers can be relatively reliable, VPAID wrappers are not. Vague, inconsistent specifications and hundreds of publisher environments interpreting them differently mean that they need to include a ton of workarounds to work properly across the industry. Therefore it’s not surprising that people are reporting up to 30% of VPAID units fail to run.
But it gets worse. As wrapper chains get longer, they get more brittle. Due to the chained setup, if any one of the intermediary wrappers breaks (either VAST or VPAID), the whole ad execution fails. This is an excessive price to pay for some simple additional tracking and measurement.
A more reliable implementation would isolate each intermediary from each other, and still execute the ad if one of them fails to do their job correctly.
In this post, we looked at the reason why wrappers exist and two specific implementations. We’ve compared these implementations on three fronts: capabilities, latency and reliability. The table below summarizes our qualitative analysis:
|VAST Wrapping||Client-side VPAID Wrapping|
|Standard tracking pixels||✓||✓|
|Custom tracking pixels||✘||✓|
|Brand safety and blocking||✘||✓|
|Additional network round trips||1 per wrapper||2 per wrapper|
|Correct VAST metadata||✓||✘|
|Single source of measurement||✓||✘|
|Code isolation||not applicable||✘|
From this perspective, the situation looks pretty dire: several critical business cases require advanced capabilities, yet the way to realize them comes at a huge cost: significant losses of revenue and bad user experiences.
In the upcoming posts, we’ll explore two advanced technologies we developed at Zentrick to tackle the specific issues introduced by the client-side VPAID wrapper, working towards a “best of both worlds” solution.
We’ll continue to use the same qualitative comparison framework we used here to compare these new approaches with the state of the art, and we’ll present more quantitative data on what improvements can be gained.
In a third and final installment of this series, we’ll look at what comes next: how the new VAST 4.1, OMID and SIVIC specifications tackle some—but not all—of these problems.