What Are VAST, VPAID, SIMID, OM, VMAP, and MRAID?

Have you ever watched a video online and seen a banner ad displayed on top of the video? Or watched a video and seen an ad appear halfway through? How about a rich media ad take over the screen when using a mobile app?

All of these situations are examples of video ad-serving protocols known as VAST, VPAID, VMAP, and MRAID.

Video advertising is one of the fastest-growing areas of online advertising, with digital-video advertising expected to experience double-digit growth every year through 2020.

However, as more advertisers explore the online video advertising space, and publishers open up their inventory to video ads, the confusion around how videos are served and played grows, but the methods used to serve video ads are different than those used for serving traditional display ads, and this difference is often a cause for confusion among advertisers and publishers.

In this post, we’ll take a look at four important terms used in online video ad serving — VAST, VPAID, VMAP, MRAID — explain what they all mean, how they work, and outline their benefits and features.

What is Video Ad Serving Template (VAST)?

Video ad-serving template (VAST) is an XML schema developed by the Interactive Advertising Bureau (IAB) that allows in-stream video ads (i.e. ads are displayed in the video player, like the ones found on YouTube videos) to be served from video ad servers and played in video players across a number of websites (publishers) and on numerous devices (e.g. desktop, mobile, tablet, etc.).

VAST was adopted as an industry standard to address the compatibility issue between video ad servers and video players located on websites.

Prior to VAST, if an advertiser wanted to display a video ad on a publisher’s website, they would have to make sure their video ad-serving protocol was compatible with the publisher’s video ad player, and if it wasn’t, the advertiser (or rather, the video ad-serving platform) would have to create a different response so that it was compatible with that particular video player.

As you can imagine, this type of situation was quite cumbersome and time-consuming.

The introduction of VAST allowed video ad servers and video players to “speak the same language” through the use of a common protocol. This brought about efficiency to the video ad-serving process, but more importantly, it added scale for both advertisers and publishers.

Apart from making video ad serving more efficient and scalable, VAST is also responsible for communicating a number of key functions and relaying important pieces of information to the video player, such as:

• Which video ad to display to the user
• Where the video ad should be placed
• How long it should run for
• Whether the user is able to skip the video ad
• What the destination URL should be

VAST was introduced in 2008 and has since undergone a number of upgrades to improve the overall ad-serving process and collect more data.

Here’s a look at how VAST has changed over the years:

VAST 1.0 (now depreciated) supported single media files — mainly MP4, 3GP, and MOV file formats — was only designed for linear ads, and provided basic event tracking.

VAST 2.0 included support for new media formats (Flash and JavaScript), allowed for both linear (e.g. pre-roll) and non-linear (e.g. overlays) companion ads to be served, and included quartile and player event tracking.

Despite the fact that newer versions (3.0 and 4.0) are available, most publishers are still using VAST 2.0, with the reasons for low adoption rates of the newer versions varying.

VAST 3.0, released in July 2012, supports five ad formats: linear, non-linear, skippable linear ads, linear ads with companion ads, and a sequenced group of ads known as ad pods.

VAST 3.0 also complies with Online Behavioral Advertising (OBA) by displaying in-ad privacy notices, provides error reports to show advertisers specific details when ads don’t run properly, and tracks more events.

VAST 4.0, released in January 2016, is the latest version of VAST and comprises of a number of new key features and upgrades (see page 6 & 7 of this document from the IAB), including:

• Ad verification and viewability execution
• Ad categories
• Universal ad IDs
• Support for mezzanine files
• Server-side support for ad stitching (used as a way to prevent the ad from being blocked by ad blockers)

While VAST has gone a long way in helping advertisers serve video ads and publishers enhance their monetization opportunities, video ads served through the VAST protocol lacked interaction capabilities.

To address the growing need for more interaction components and interaction reports in video ads, the IAB and its member companies created a new standard, and another acronym, known as VPAID.

What is Video Player Ad Interface Definition (VPAID)

Video Player Ad Interface Definition (VPAID) is a piece of code that enables video ad units and video players to interact with one another.

Compared to VAST, VPAID allows advertisers to serve rich, interactive ads to users and collect data about how users interact with their video ads.

Here is an example of VPAID in action:

The ad allows the user to interact with the video by clicking on different tabs to view more information and engage with different elements.

Other interactive examples found in video ads include expandable elements that allow users to fill in a subscription form, complete a survey, or even play a game.

Even though VPAID can be used independently, it is often embedded into VAST.

The reason for this is advertisers are able to utilize the best of both worlds — the compatibility aspects and logic from VAST (e.g. event tracking, loading videos, etc.) and the interactive and reporting features from VPAID that can be added using JavaScript in a VPAID container. As such, many refer to VPAID as VAST ad tags.

VPAID supports all kinds of media files and scripts, including HTML5 and JavaScript.

How a Video Ad Flows With VPAID

The diagram above provides a simplified example of how a video ad unit and video player interact together using VPAID. Source: The IAB.

Here’s what’s happening in the diagram above:

1. Call: The video player sends an ad call to the video ad server.
2. Response: The video ad server sends back a VAST XML, which contains a VPAID-compliant executable ad unit.
3. Ongoing Communication: While the video ad is being served and displayed to the user, the video player and the video ad unit are in constant communication, with the video player receiving properties for the ad unit and the ad unit sending events to the video player.
4. Tracking Impressions and Activities: The ad unit and the video player can send information, such as impression and activity data, to their respective ad servers.

Currently, there are two versions of VPAID available: VPAID 1.0 and VPAID 2.0.

A Successor to VPAID

At the end of 2017 IAB announced a replacement for VPAID was in the pipeline. The IAB’s recent post reveals that VPAID, although loved for its flexibility and innovation, brings with it limited transparency and trust issues.

Publishers are generally reluctant to relinquish control over video playback and user experience to VPAID. And because wrappers are used with it, publishers don’t always know where the ads are coming from.

Amit Shetty, IAB’s Senior Director for Product, Video & Audio, in a comprehensive post about the future of VPAID published in November 2017, said the IAB was working on the successor to VPAID, which is almost 10 years old.

The existing VAST 4.0 (detailed paragraph above) will just be used to deliver ads using a single tag to render ad units, seamlessly across all platforms. It will also allow pre-caching of video assets with minimized latency.

Shetty revealed that the IAB was working on two specs on top of VAST 4.0, which will be responsible for measurement and verification, as well as supporting interactive creatives within video ads.

These two specs are SIMID and OM.

SIMID

Previously known under the working name VPAID-i, Secure Interactive Media Interface Definition (SIMID) is one of the successors to VPAID. As of April 23, 2019, the specification is open for public comment. 

According to the IAB Technology Laboratory, SIMID’s main purpose is to support interactive capabilities in video and audio ads, as well as increase transparency and security.

SIMID has been a long overdue upgrade. Until now, publishers have been relying on the outdated VPAID specification for verification and other use cases, whereas VPAID was originally intended only for interactive ads. 

Attempting to make VPAID do things outside its intended scope of purpose gave rise to trust and transparency issues, and problems with creative freedom. SIMID is intended to resolve all of that. 

SIMID gives control of ad playback to the player itself. In this way, it gives publishers greater control of the user experience.

Also, when used together with OMID (Open Measurement Interface Definition) and VAST (Video Ad Serving Template), SIMID gives creatives more freedom in terms of interactivity, and facilitate better integration with ad verification vendors. 

SIMID informs publishers of the sources of components of their ads. The net result is better consumer experience and more trust and transparency in the industry, specifically between digital media and marketing stakeholders.

Open Measurement (OM) SDK and OMID API

The IAB Tech Lab’s Open Measurement (OM) spec is the second successor to VPAID and provides measurement and verification capabilities in video ads. 

The open measurement (OM) software development kit (SDK) enables open-source, third-party viewability and verification measurement for ads served to mobile app environments. 

A single SDK enabling third-party ad measurement and verification has been much needed in the industry and will now facilitate the work of integration partners (app publishers and ad SDK developers) as well as measurement providers. 

With OM SDK, viewability and verification information will be accessed without the need for multiple service providers’ SDKs.

IAB Tech Lab’s OM SDK consists of two components compatible with third-party javascript tags capable of collecting and interpreting signals from the OMID API (compatible with multiple platforms: iOS, Android, Web browser and others).

• OM SDK Native Libraries: iOS, Android etc. specific libraries responsible for collecting and publishing OMID signals to measure viewability and determine other data about the ad rendering and display to support viewable impression definition as defined by MRC
• OM SDK JS: Javascript libraries for communication with OMID API which a Measurement Provider can use to listen to the signals provided by the OM SDK.

For measurement and verification of video ads in web browsers, publishers and AdTech vendors can use the open measurement interface definition (OMID) application programming interface (API), which can be listed in the <AdVerifications> element of VAST 4.1 tags.   

The IAB Tech Lab has also created a service allowing to validate compliance and successful integration of the OM SDK, helping to make sure the implementation will be compatible with all Measurement Provider tags. Click here for the complete compliance guide.

The Benefits?

The goal behind the transition is to simplify things for vendors and offer a solution that is more reliable. The official IAB document says SIMID and OM will offer:

• More control for publishers. Latency issues and code will be improved. And no more “black box mystery code” (i.e. using wrappers) with full access to the pages. Publishers will be able to choose to just support verification or interactivity, or both.
• A better user experience as video ads served via SIMID can be pre-cached and fatal script errors from the video creative won’t impact the video player or publisher’s website, as is the case with VPAID.
• Simplified access to measurement and viewability data.
• An approach to interactivity, measurement, and verification that works seamlessly for all platforms, as well as across mobile and web.
• Clarity and simplicity concerning what technology or standards need to be used for specific cases.

What is Video Multiple Ad Playlist (VMAP)?

Have you ever watched a long video online and seen video ads appear throughout different intervals? That’s an example of Video Multiple Ad Playlist, or VMAP for short.

VMAP (current version 1.0.1) allows content owners (i.e. the people making the videos) to describe the structure for ad inventory insertion if they don’t control the video player themselves, as is the case with YouTube for example.

Even though VAST 3.0 contains ad pods which allow ad slots to be inserted into videos, it doesn’t allow content owners to define the ad breaks or the timing of the ad breaks.

With VMAP, video content creators can define the following:

• Ad breaks within their content
• Timing for each break
• How many breaks are available
• How many are allowed in each break

VMAP was designed to be used in conjunction with VAST and is well-suited for video content creators who have no control over the video player, but want to control the ad experience within the videos.

VAST, VPAID, and VMAP all make up the IAB’s Digital Video Suite (or V-Suite).

What is Mobile Rich Media Ad Interface Definitions (MRAID)?

Mobile Rich Media Ad Interface Definitions (MRAID) is an official application programming interface (API) that’s used to display rich-media ads in mobile apps.

Rich-media creators can use MRAID’s standardized set of commands, which are designed to work with HTML5 and JavaScript (JS) to execute a range of functions, such as expanding the ad, resizing it, and gaining access to some mobile device functionality.

As mobile devices run on different operating systems, and as apps are built using different languages, MRAID eliminates the need to create different rich media ads for all the different mobile devices and apps.

MRAID essentially allows advertisers to display their rich media video ads across all mobile devices in all kinds of apps.

However, just because an ad in a mobile app is a rich media ad, it doesn’t necessarily mean it’s been served via the MRAID protocol.

Creative providers often create their own framework, and sometimes instead of moving to MRAID, they just provide a wrapper.

Additional reading:

What is VAST & VPAID and Why is it Important for Video Advertising – MobileAds

The IAB’s Digital Video Suite – IAB

WTF is VAST? – Digiday