VPAID and VAST: standards for Video Advertising Technology

Christopher Reid Ad Ops, Adtech, Trends

The effects of implementing the Video Player Ad-Serving Interface Definition (VPAID) standard have sparked several discussions online (Reddit, Hacker News) among dissatisfied users. There have even been in-depth breakdowns of the closely related Video Ad Serving Template (VAST) standard, digging into the potentially excessive amounts of data consumed on some mobile sites using these technologies. The consensus seems to be that the misuse of technologies like VPAID or VAST drive the adoption of ad blockers, and contribute to a general distrust of web advertising.


From the IAB: (VAST)... provides a common ad response format for video players that enables video ads to be served across all compliant video players. The purpose of VAST is to define a standard to ensure the successful delivery of any ad tags to a site's video player. The objective is to monetize video content effectively and ensure that both the ad and the video are displayed correctly across a variety of sites.

The adoption of VAST means that video ads can be presented in a uniform fashion, so that video ads can be easily served to compliant video players without further development or processing.

The issue with VAST is that its use can result in excessive amounts of data being transferred during the course of an article being read. From the breakdown mentioned above: in 4 minutes I got 32Mb of payload across 1,405 calls ” on a page displaying primarily text. VAST accomplishes such amazing feats of data delivery by loading, and reloading numerous scripts from various ad tech vendors, each script responsible for responding with additional data, or images, or trackers.

UPDATE: as mentioned by Aden Forshaw in the comments on the LinkedIn post, MRAID tags can be a large contributor to the VAST problems. In his words: It's the MRAID tags used by companies arbitraging display to video that are the issue.


VPAID is meant to facilitate the interaction between ads and video content via a single standard. This means that it can be combined with VAST in order to build out a complete video and ad serving technology stack. Where VPAID differs from VAST is that its primary purpose is to allow ad interaction on top of a video ad unit. So, if a publisher chooses to show an ad within a video player prior to the video playing, they might use VPAID to display an ad that would allow the site visitor to click, or select options within the ad, without affecting the delivery of the video.

The problem pointed out in the critiques of VPAID is that executable ads are required to make the interactive elements possible. The executable nature of these ads use active interaction logic to track users (and also track passive interactions like hovering over an ad) and trigger video playback in response. While this can be very helpful if used correctly ” after all, metrics, and feedback are a huge part of the advertising business ” there are many opportunities for executable ad technology to be twisted so that the user experience of publishers' sites are compromised.

For example, a VPAID unit can programmatically summon multiple VAST units in search of an ad buyer. VAST-compliant ads (that are being requested by the VPAID unit) are simultaneously looking for their own separate VPAID instances as part of their own ad-serving process. The constant data calls to and from the site can spiral out in a daisy-chain effect where each successive ad call spawns more requests, hurting the end user experience as a result.

Now that the abuses of VAST and VPAID have largely been culled from the ecosystem ” mostly due to the discussions pointed out above, and general bad press for the ad tech industry surrounding these discussions ” it is actually extremely difficult to find current examples of the daisy-chain effects in action.

Previous examples of VAST, called out for their poor performance, made over 1400 requests, resulting in 32 megabytes (MB) of data transferred ” for a single web page. To see what would transpire over the course of a typical VAST ad, compare the network requests made for an example unit:

VAST network calls
One example of a VAST unit results in 215 separate requests over the course of 70 seconds. It transferred 1 MB of data during that time.

Digging into what this VAST unit is doing, there are a couple of things to note:

  • The unit makes 215 requests and transfers one megabyte of data. A large reduction over the previously mentioned example of abuse.
  • It makes separate calls for each successive action required to serve the ad. The video is provided in small pieces that are called separately as the entire length of the video is played.
  • Trackers can be called for each interaction with the video, and can be set for metrics such as viewing time, user hover events, and click events.
  • All requests and data transferred as shown above are for only this ad unit. It does not take into account the requests or data required for the webpage to load, or for other ads on the page to render in addition to this VAST unit.
  • The granularity of the data provided by the VAST unit allows for a much more precise image of what the performance of that unit is, and what optimizations could be made for similar ads in the future.

VPAID and VAST are not inherently terrible technologies. They have the potential to provide value by presenting ads as both engaging and desirable. But, like most standards, they can be abused. It's worth exploring them to understand both their benefits and drawbacks, and build an understanding of the consequences of abusing these standards. Knowing what to expect from these implementations can drive a positive experience, both for individual cases and for the industry as a whole.

Tolerance vs usefulness graph
An illustration of the relationship between usefulness and tolerance. Tolerance for advertising hits a limit, regardless of how useful the website might be.

People will easily tolerate tasteful advertising in return for something that they value, like news, forums, editorials, blogs, etc. However, tolerance for advertising quickly degrades when it gets to the point at which user attention, privacy, and goodwill is no longer respected. It is at this point that ad blockers and a general migration away from sites that misuse ads become more prevalent and normal.

Part of what Sortable does is work with publishers to improve revenue without sacrificing user experience, so that publishers don't need to resort to poor implementations of these types of technologies in an attempt to extract more revenue from their sites. By promoting best practices and maximizing the value of the advertising space that a publisher already has available, we're working on making ads suck less.

Would you like to learn more about Sortable?

Book a demo to learn our our solutions and ad ops experts can help.

Request a Demo