Video ad serving is very different from static ads. It’s important to understand the nuances of how video ads work, including VAST, VPAID, players and the other pieces of the video ecosystem.
Video on publisher sites is played by players. To be a modern player, there are a few requirements, including their ability to handle streaming data through different connection types and speeds, buffer content – potentially received out of order from the server, resize smoothly across different devices, and execute and deliver video ad tags. There are two varieties of video ad tags – VAST and VPAID, which are discussed below. Some players include Ooyala, JW Player, Video.js and FreeWheel.
VAST stands for Video Ad Serving Template. It is a specification from the IAB, much like the OpenRTB is a specification. VAST defines a standardized protocol for video ads, including the URL of the ad content from and other attributes that are part of the advertisement, such as tracking parameters, whether the ad is skippable, the length of the ad, the clickthrough URL of the ad, etc. The last version of VAST (4.0), importantly added standardization for viewability tracking. VAST tags often contain multiple versions of the same ad, with the correct version being selected by the player based on format, dimension, bit rate and more.
VPAID stands for Video Player Ad Serving Definition. This is another specification from the IAB that focuses on interactions between ad units and video player focused on enabling rich interactive in-stream ad experience. It allows for additional code that can be run within video players for things like overlays. It is effectively VAST with interactive functionality. One of the main advantages of VPAID is that it allows advertisers to collect rich amounts of interaction data (only view and viewability tracking pixels can be delivered with VAST). It also specifies the interaction channels between companion ad units and the video player.
The general protocol for an ad is that the player, at some point during the playback of the content (before, during, or after), receives a cue to fetch the advertisement. The player can fetch a VAST or VPAID ad tag from the ad server and execute it accordingly. This describes a standard client-side environment through all devices. With the increasing prevalence of ad blocking, however, ad calls may be blocked at the client. This has led to server-side stitching – meaning the ad is integrated seamlessly into the stream of the video in a way that makes it indistinguishable from the content itself, meaning the client cannot block it. When ad stitching is used, only VAST ads can be used, as VPAID requires execution on the client that renders this flow impossible. Server-side stitching requires that the content be delivered through an ad-stitching service that also processes the content. The service receives the VAST ad tag and, through a series of server-side steps, extracts the content and injects it into the byte stream of the content. The stitching server will also send tracking information on behalf of the player to the ad server used by the ad question.