Video Advertising Overview


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.

Unlike banner ads that may contain javascript that executes the code of the ad, VAST itself does not do anything. The player fetches the components of the ad, as specified in the VAST ad tag, and the player subsequently issues the appropriate tracking and other pixels as the ad is played - ultimately does the job of rendering the ad components. In a sense, the web browser is to a banner ad what the player is to a video ad. VAST represents an effort to standardize video ad components between ad players – so the same video ad could be executed by all players. Similarly, VAST is an effort to standardize video ad servers such that they all speak the same language to the players. In the RTB or adserving context, the player will often be provided with a URL from which it will fetch a VAST ad tag that it subsequently renders.

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.