The IAB today announced the approval and publication of VAST 2.0, the new version of the Video Ad Serving Template meant to create standards and liquidity for video ad serving. VAST 2.0 is a big step forward from 1.0 in terms of clarity of implementation and purpose and fixes many issues that people were having implementing the first version.
I was heavily involved in the drafting of VAST so I thought I would comment on some of the changes and the rationale. But let me be clear, this document was drafted by a large group of technology vendors and publishers and was a great group effort among people who normally consider themselves rivals or competitors.
Why VAST?
Let’s start at the beginning. Banner ads are generally served by snippets of HTML that write out either script or Iframes containing script. One script can write out another script, and so on and so on, with the end result being an image or Flash file to show on the page. Although technically unsophisticated, this chaining of scripts works fine for the most part, and allows any numbers of vendors to work together fairly simply by exchanging tags and cutting-and-pasting those tags into each others’ servers. To engineers from outside the advertising industry this sounds like a cluster, but to us, it’s home.
This system breaks down radically inside a Flash or Silverlight video player. These environments expect well-formatted XML describing the ads to be shown and have custom layers of code to interpret and display the ads described in the XML. Every video player is different, and most players have been built to work with one ad serving system. For example, Yahoo’s video player is built to work with Yahoo’s ad server.
As a result of this proliferation of XML customizations, there is very little interoperability in the video world. If you wanted to start a new video ad network, you would need to write and document code for playing your ads, send that code to publishers, have those publishers rewrite their video players around your code (unlikely!), and then service the publishers when something went wrong. As an advertiser, you would be unable to run video ads across publishers since every tag would have to be customized for every publisher on your media plan.
VAST is supposed to solve this problem by having a common reference XML and XSD that every video player can support. It requires work from the publishers and players, but only once, not every time they want to support another tag.
Getting to 2.0
OK, the intro is running long. Time to get to the meat.
The IAB published VAST 1.0 in the Summer of 2008. Quite a few publishers and technology vendors built support for VAST, but feedback came in that there were some confusing issues with the 1.0 specification, especially for complex multi-unit video formats. For example, there were multiple ways to execute an ad that contained a pre-roll video followed by an overlay from the same advertiser. There was also some cruft in the specification that didn’t really make sense to the engineers building out support.
The VAST working group at the IAB went through many of the issues being described and made a hard decision. VAST 2.0 would not be backwards compatible with VAST 1.0. We made this decision based on the fact that a) notwithstanding the number of companies that built support so far, very few VAST ads are actually running to date; b) the changes were really necessary; c) the effort to upgrade from 1.0 to 2.0 was not deemed that significant.
The group started developing 2.0 this Summer, thinking it would be published within a month or so, then more and more issues kept arising and roughly four months later, we’ve got something out the door. From conversations I’ve had with many leading publishers and tech vendors I’d expect the first VAST 2.0 ads to run in Q1 2010, with a very quick ramp-up in industry volume thereafter.
VAST 1.0 vs 2.0
I want to quickly summarize the differences between VAST 1.0 and 2.0 in this post. The IAB has published both a clean and a redlined doc explaining the differences in detail, and I will try to write a couple of more articles on this subject as well to clarify the thinking.
Creatives: The biggest source of confusion with VAST 1.0 was what to do with multi-part creatives. The standard could technically be used with two-part creatives, but any more than two would break the schema or make implementation ambiguous. In VAST 2.0 we introduced the element that wraps any number of Linear, Non-Linear, or Companions in a sequence so that you can more easily represent complex ad types from a single advertiser.
Tracking Multiple Elements: Along with the support for multiple Creatives, we identified the need to track these separately. It was vitally important for the standard to not create ambiguity around the importance of tracking a single impression for each VAST Ad, since impressions are the “currency” of online advertising and are used for billing and forecasting in most advertising billing systems. However, there are many parties in the video space creating hybrid pricing models where tracking videos, overlays, and companions separately is a part of doing business. To accomplish this we added a new tracking element for “creativeView” that can be used as a pseudo-impression for each Creative within a VAST Ad.
Companions: There was a good deal of consternation and confusion among engineers trying to implement VAST 1.0 companions. In 1.0 the companions each had a resourceType which could be Iframe, HTML, Script, etc. then the companion itself could be a URL or HTML. So what are you supposed to do with an Iframe of type HTML? How is that different from an Iframe of type URL? These complexities have been smoothed out and now resources are broken down into iframeResource, scriptResource , etc.
Non-Video Video Ads: What if you want to serve an image into the “video” part of an ad? In VAST 1.0 there were at least two ways to do it, none of them satisfying. In VAST 2.0 we clearly allow image or SWF MIME-types in the Linear portion of the response, and the apiFramework option can be used to execute interactive non-video linear ads.
Next Steps
Hopefully VAST 2.0 will be compatible with the business needs of the vast (hah) majority of entities currently doing business in the video ads arena. The next step is to get moving on implementation. There will be bumps in the road towards industry-wide adoption and interoperability, but this is clearly to be expected given the complexity of the business needs. But I’m confident that in 2010 we’ll see a majority of video ads served using VAST and that the resulting reduced cost and increased liquidity will help video advertising achieve it’s full potential.
Feel free to reach out on twitter or by email if you have questions or comments about VAST 2.0.