Before jumping into technical details, let’s define two entities which closely interact: ad servers and video players. Ad servers are computer servers that store constantly updated advertisements used in online marketing. They have the purpose to deliver to websites different requested ads, selected by complex algorithms. On the other side, websites use a video player to play these ads together with related video content.
VAST is an XML schema that encapsulate ads information. It describes an expected behavior for the video player that chooses to support and implement this formatted ad response. VAST actually provides a common protocol which helps ad servers to use a single VAST response to communicate with multiple video players. This response contains the complete instructions which video player needs to correctly display and track an ad and also to communicate with it (in the case of VPAID).
The VAST response may contain one or more of the following type of ads:
Linear Ads – are frequently served in video formats such as mp4, wmv or flv files. Any time a linear ad is served, the video content is interrupted, video ad is played and the content will be resumed after the completion of the ad. Besides a video format, this type of ad may be represented by static images that play for a specified amount of time. Depending on the timeline position of the ad, it can be classified as pre-roll (an ad that is played before content starts), mid-roll (will be recognized as a break during the content video) or post-roll (that will start immediately after the content ends).
NonLinear Ads – are displayed on top of the video content, without interrupting it’s playhead. Also named Overlays, this type of ads usually contain images or text and are covering the top or bottom fifth of the player area for about 10-20 seconds.
CompanionAds – are served outside of video player area and always come together with a linear or nonlinear ad, but never alone. They can be used as a way to keep an ad visible in the page after the video ad has ended.
When talking about VAST, we have to understand that VAST does not “do” anything. It only presents a mechanism for transferring logical data from one system to another. Ad servers just transmit a list of expected functionality when sending a VAST. Video players that are compliant with this protocol should be able to parse and interpret the information received. It does not offer an interface for communication with executable ads (such as VPAID). It has no restriction about the timeline moment (pre-roll, mid-roll, post-roll) when the video player should decide to request, parse and play the VAST response.
A VAST-compliant ad server must be able to respond to the player request with a XML schema that respects VAST specification. It must also be able to receive and track all the requests associated with events that result in VAST interpretation of video player
A VAST-compliant video player must be able to correctly manipulate the instructions received in VAST XML schema:
– it has to correctly display and render ad assets
– to take in consideration that may confront with a chain of VAST responses, called wrappers and concatenate the information. This type of response contains instructions that conform to specification and also a url to a new VAST XML, that may be also a wrapper. This chain is ended when an inline ad is found.
– it has to respond to user interaction and send back to the ad server required tracking information received (including rendering, progress, user interaction)
In conclusion, any VAST format compliant ad server or video player, has to make sure that covers the following chapters:
– Inline (directly and fully served VAST schema) or Wrapper Ads (used by multiple ad-serving vendors, which are chained together and contribute with information to the final VAST schema)
– Supply (for ad servers) and tracking (for video players) the events that describe the life and interaction of the ad
– Error reporting
– Industry Icons
The latest version of VAST is 3.0. It brings a new set of characteristics that considerably improves the ad experience and their monitoring:
– In a Nonlienar Wrapper ad, the resources to assets are no longer required. This brings a clear difference between Wrapper Nonlinear Ads and Inline Nonlinear Ads: for wrapper nonlinear ads, only tracking section is relevant.
– A huge difference that third version of VAST introduces is the support for a multiple ads playlist, officially called AdPod. Before the release of VAST 3.0, only a single-ad VAST schema was considered. Now, the guidelines implies two more cases. The figure bellow presented by IAB VAST3.0 specs shows three cases of structures permitted in VAST 3.0. The first case, describes a single-ad VAST schema, also supported by VAST 1.0 or VAST 2.0 compliance. The second case is an AdPod that will tell the video players to sequentially play all the ads. The last case is a combination of both. Such a VAST 3.0 schema gives the following instruction: first try to play the ads that are grouped in the Ad Pod. If something is going wrong when trying to display it, you have another choice! Look inside Ad Buffet! An Ad Buffet is a list of ads that are not required to play sequentially. There are presented as a list of alternatives from which a player should choose one if an ad pod cannot be rendered.
– Another great feature that VAST 3.0 comes with is the support of Skippable Linear Creatives. This creates a better user experience, instructing video players that they should let users skip the ad after a precise amount of time has passed.
– Displaying of ads involves a big circuit between multiple systems. Also there are a lot of reason why sometimes a VAST schema may not touch it’s expectation. This is why VAST 3.0 added a list of error codes that video players should use to differently track error reasons (parsing errors, invalid VAST schema, ad assets not found, loading timeout etc).
– Besides all the events that already existed, a list of new events that register the life of the ad was introduced (acceptInvitationLinear, closeLinear, skip, progress).
A general VAST XML schema structure, with its required elements, that describes an inline ad, will look as it follows:
<VAST> <Ad> <Inline> <AdSystem>The name of the ad server serving the VAST inline response</AdSystem> <AdName>The name of the ad</AdName> <Impression>A URI that video player should request to track the display of the first frame of the ad </Impression> <Creatives>A container for one or more creatives <Creative> A file that is part of VAST ad. May be provided as a Linear, NonLinear, or Companion ad <Linear> <Duration>The duration of the Linear ad </Duration> <TrackingEvents> A list of tracking elements, formed by pairs of (event, associated URI)</TrackingEvents> <MediaFiles> A container with MediaFile elements, that contain various information about the type and display of the ad, and also the URI to the actual asset that player needs to load</MediaFiles> </Linear > </Creative> <Creative> <NonLinearAds> <TrackingEvents> Same as above, applied to NonLinear ad </TrackingEvents> <NonLinear> The parent for resources to load the nonlinear ad asset </NonLinear> </NonLinearAds> </Creative> <Creative> <CompanionAds> <Companion>The parent for resources to load the companion ads and for tracking elements. <Companion> </CompanionAds> </Creative> </Creatives> </Inline> </Ad> <VAST>
This structure is partially shared also by the Wrapper Ads, requiring VASTAdTagURI node, but making optional the presence of Creatives node:
<VAST> <Ad> <Wrapper> <AdSystem> The name of the ad server serving the VAST wrapper response</AdsSystem> <Impression>A URI to a tracking resource that will be requested when inline ad is displayed </Impression> <VASTAdTagURI>A URI that redirects the video player to the next VAST response. It may be also a wrapper. This redirect will continue while a VAST inline response is found. </VASTAdTagURI> </Wrapper> </Ad> </VAST>