The IAB’s public release of VAST 4.0 on Jan 21st raised many questions from agencies about the significance of this release. VAST (Video Ad Serving Template) is the standard delivery mechanism for video ads across numerous platforms, as well as one of the IAB’s most widely adopted standards. Chances are, if you’re seeing a video ad on an IP-connected device across desktop, mobile, and connected TV there’s a high probability that it was delivered using VAST.
What Is VAST?
Viewed simply, VAST is no more than an XML (aka structured text) package for delivering the video asset along with other information needed for advertising – primarily the tracking pixels used to measure standard video metrics (impressions/views, quartiles, completions) by the viewing audience.
VAST To Date
While VAST 1.0 was somewhat of a misfire, VAST 2.0 successfully met the general requirements for ad delivery, and is still the most widely adopted version of this standard. VAST 3.0 introduced support for multiple ads in an “Ad Pod’ which is more friendly to the multiple ads shown in a typical TV commercial break. Some additional useful features include support for skip, privacy compliance icons (from Truste, Evidon, etc.), and VAST error codes and other amendments.
The primary focus of VAST 4.0 has been to address server-side ad insertion, also known as stream-stitching, which publishers use to pull the video asset out of the VAST file on the server and combine it into a single stream with the video content. This has a few benefits for the publisher: it eliminates ad-specific latency, simplifies the process of delivering ads to multiple devices (which only have to receive a video stream rather than a device-specific ad unit), and defeats attempts at ad blocking.
However, it also sets the stage for the elimination of VPAID as an ad delivery mechanism, which has implications for the buy side. VPAID (Video Player Ad Interface Definition) is the agreed-upon language that the player and the ad use to speak to each other. For example, the ad can tell the player when it’s done, so the player can get rid of it and proceed to the content. VPAID was always intended to play this role, but over time, it has increasingly been asked to play a part in ad delivery – making calls to verification parties to potentially block an ad in certain contexts, or sometimes making last-minute decisions to not play the ad for other reasons.
VAST 4.0 calls for separation of the video asset from this VPAID layer, so publishers can get at the video asset without executing an unknown package of VPAID code, and specifies separate calls for verification and interactivity. While this is better from a publisher perspective, the separation of the verification code from the video makes it more difficult for verification and viewability vendors to do their jobs as specific verification calls now need to be tied back to specific impression calls, and verification calls could potentially be executed from somewhere other than where the video plays.
While VAST 4.0 makes some good moves that propel the industry towards a better cross-screen video standard (by reducing the demands on the publisher and the device) and helps open the door to some exciting new possibilities, like interactive over live content, it remains to be seen whether it goes quite far enough to win adoption beyond a few large publishers. For now, at least, VPAID continues to be the in-market standard for enabling viewability, verification and interactivity. VAST 4.0 is the first promising step away from the old model, but future versions of VPAID (next up for revision) and maybe VAST will have to bring us all the way to a new one before the whole market will shift in its favor.
This article originally appeared in Adotas on February 19, 2016.