VAST3.0 specification

VAST3.0 Video AD Delivery specificationPosted on February 15, 2014

1. Terminology

With the development of the video advertising industry, some terminology has been widely adopted. The following defines some of the terms associated with video ad serving in this document:

• Ad pod (ad pod): Ad Pod is a series of linear ads (Linear ads) that play back and forth, like multiple TV spots, that belong to a commercial pause break.
• Companion AD (Companion AD): Typically a page's display banner ad (banner) or rich media ad that appears outside of the video player . Accompanying ads may continue to stay on the page after the relevant In-stream ads have ended. An accompanying ad can also be a skin that is embedded in the design of the video experience.
• Click (clickthrough): When the user clicks on the ad creative, the URL opens the page.
• Inline ad: A Vast ad response that contains all the information needed to display a video ad . Vast's in-line ads receive a response without having to call other ad servers that are needed.
• in-stream AD (In-stream AD): Any ad that appears in the video player , whether it's an image overlay or a linear video ad, such as an ad that plays in a 30-second ad position.
• Linear Advertising (Linear AD): Ads (pre-roll) appear before a program is played on a TV ad (Mid-roll), or an ad (Post-roll) appears after the program has finished playing. Linear ads can be video, rich media, or still image ads. With APIs or other technologies, linear advertising can become interactive , and ad time can be extended when a user has interactive behavior.
• Primaryad: Video campaigns include in-stream ads (In-stream AD) plus one or more accompanying ads (Companionads), in-stream ads (in-stream Ad) section is known as the primary ad . In this master companion relationship, the primary ad must always be displayed (that is, in-stream ad must be displayed ).
• Non-linear AD (nonlinear AD): is a in-stream ad that is displayed simultaneously with video content playback. non-linear ads typically cover one-fifth of the bottom or top of a video player , which can be text, images, or interactive ads. Using APIs or other techniques, a video player can allow user-initiated interactions to pause the playback of content. Non-linear ads can only appear at a point between the start and end of the content video (mid-roll position), and if there is no interaction, the ad generally disappears after 10-20 seconds .
• Overlay Ads (Overlay AD): Display images or text on video content, similar to non-linear ads, often referred to as simple "non-linear advertising", while non-linear ads may also include the form of nonoverlapping formats, It does not overwrite the delivery of any video content within the video player .
• Primary AD Server (Primary AD servers): The first ad server for a video player to request ad content. The primary ad server is typically a publisher's ad server.
• level two Ad Server (secondary ad servers): Receive redirected VASTfrom the primary AD Server (primary ad servers)(packaging ads, VAST redirect After the response , the player calls the ad Server again . Secondary AD servers may include AD proxies or ad network servers . In addition, level two ad servers can redirect video players to a third Ad server, and third-level ad servers can be redirected to level fourth, and so on. Ultimately, the Ad Server must provide a vast response that includes all the creative elements that need to display the ad.
• vamg (video ad measurement guidelines): A guide to measuring videos, which defines a set of events that should be tracked when a video ad is played .
• VAST (serving template): video ad serving templates, which describe the XML structure of the video ad response . Vast enables ad responses to be used from any AD server.
• VAST Redirect (VAST redirect): One VAST ad response points to another VAST response (sometimes referred to as a downstream VAST response).
• VAST tag (VAST tag): Returns the URI that contains the VAST response when called.
• videoad: any ad that appears in the video. The video experience may include formats such as banner videos (In-banner video), text-to-video (In-text video), streaming videos (in-stream). VAST is only available in video streams where video players are used to manage video experiences that are independent of any other content. For example, the video in the ad banner is considered rich media , which is not part of the vast guidelines.
• Video player : for managing the video experience video playback environment. Video players are provided by the online video platform (OVP) vendor or can be customized by publisher.
• VMAP (video Multi ads Playlist): A multi-ad playlist of videos that describes the XML format of the video ad playlist that is delivered to the player from the ad server.
• VPAID (video player ad Interface definition): Visual player AD Interface definition, which defines a communication protocol between an ad and a video player.
• Wrapper (packaging): in the context of vast, a wrapper is a response that provides the video player with a URIthat invokes a two-time vast response. A secondary response may be another wrapper or a vast inline (inline) response.

2. Comprehensive summary

The IAB's video ad delivery template (vast:video ad serving Templat) specification is a common XML schema that is used to serve ads in digital video players , It also describes the expected video playback behavior when VAST is executed (formatted AD response). VAST3.0 has opened the in-stream digital video advertising market , reducing costly technical barriers and encouraging advertisers to spend more on video advertising.

as online video content publishing has become more prevalent, video publishers have sought to monetize content in streaming (in-stream) Media Video ads . Previously vast, in the video player's streaming (in-stream) Advertising Protocol and advertising service provider's ads could not be achieved in large-scale release above the common denominator . to provide advertising services to multiple publishers using different proprietary video players, advertisers have to provide slightly different ad responses for each publisher/video player. This method is expensive and not easy to scale.

vast provides a common protocol that enables ad servers to use a single AD response format in multiple Publishers/video players . In 2008, the IAB introduced the first version of the T-video advertising market vast, which has been widely adopted throughout the industry. 2009 added allows for additional features and clearer features. Today, with the in-stream digital video advertising marketplace (in‐stream-Advertisingmarket) becoming more complex, More features and functionality are required to support the presentation and response of the insert in-stream media AD (In‐stream AD).

VAST3.0 offers more features, more features and better reporting while keeping backwards compatible VAST2.0 to ensure a smooth transition across the industry. VAST3.0 provides additional details in the format of the ad response and the expected behavior of the video player .

In VAST3.0, video players have the ability to claim the ad formats they support . Here are 5 formats to choose from: linear ads, non-linear ads, skip linear ads, accompany linear ads, and ad pods (a sequence group of ads). both linear and ad pods that can be skipped are the new formats available in this release. Some video players, in accordance with their publishing business model, choose to support only certain vast ad formats. In VAST3.0, a player can support what kind of vast ad format speculation is eliminated.

Video content publishers should upgrade their video players based on their supported ad formats to suit the VAST 3.0 response . These video players should also adhere to the expected behavior defined by vast. In addition, the ad-service organization should ensure that its vast 3.0 ad response is formatted and complies with the specifications listed in this document.

Vast will be updated with the progress of streaming video ads (in-stream video advertising progresses) and the new ad formats become more widely adopted.

3. IAB Video Guide

The dramatic rise in video advertising spending has been accompanied by an incredibly growing network of videos. To drive this work, the IAB's digital video board brings together publishers, agents and suppliers to create video advertising specifications to build a common communication framework between AD servers and video players. Six sets of IAB guidelines have been developed to help improve video advertising:

• AD measurement Guidelines for videos (video ad measurement Guidelines vamg): An overview of how events should be tracked.

• video ad serving template VAST: Enables a common structure for video ad responses sent from the ad server to the player.

• The ad interface definition for the video player ad Interface VPAID: The communication protocol established between the ad and the video.

• Video Multi ads Playlist VMAP: enables video ad playlists to be sent from the ad's server to the video player.

• guidelines and best Practices for digital video ad formats guidelines and good practices: video ads should stick to the best advertising experience .

• Digital Video In-stream ad Metrics definitions: defines a measure of the industry's proven effectiveness in measuring video advertising .

Explains the relationship between these guidelines and the video ad delivery process.

3. Updates in VAST 3.0

Vast has been widely used in the same industry, but in the industry to meet the needs of the adaptation has certain limitations. The VAST3.0 update is designed to provide support for emerging video ads, and companies can choose the support method while remaining compliant with the VAST3.0 guidelines.

• Nonlinear packaging Changes (nonlinear Wrapper change): Non-linear resource files do not require a wrapper vast response. VAST3.0 clarifies the differences between embedded nonlinear ideas and packaging non-linear ideas. Only trace elements and wrapper nonlinearity are correlated.

• compatible formats (Compliance Formats): The vast supports five different ad formats. Publishers do not need to support all five models in accordance with VAST3.0. In VAST3.0 video content publishers can declare support for one or more vast ad formats while maintaining minimal compliance guidelines.

• support AD pod (ad Pods): using the <Ad> element on the sequence attribute, you can format multiple ads for vast response groups.

• support for linear skipped ads: Viewers can skip an optional ad serving mode, and publishers and advertisers can play all the way through negotiated billing on an ad basis.

• support in Advertising privacy Notice: When multiple ad servers are participating in video ads, display the ad's privacy statement and Support Online behavioral advertising (OBA) self-regulation to cast to difficulties. Best practice guidelines for VAST3.0 stocks are handled in the advertising privacy statement.

• Better Error Reporting: An improved error code list that makes the video player report more specific details when the ad is not correct. Over time, the resulting troubleshooting data can help improve video advertising technology.

• More Tracking Events: Some tracking events and attributes have been added to the running ads to provide more details and support for new ad formats, such as skipping ads.

The VAST3.0 is designed to receive and play VAST2.0 and higher-format responses. This means:

1. New VAST3.0 players will continue to render VAST2.0 ads, and also support the future vast version fully backwards compatible as much as possible.

2, understand VAST2.0 video player, can display VAST3.0 ads, if they relax their mode and version check and the unknown attributes or elements will not fail.

3. VAST2.0 packaging can point to VAST3.0 response and VAST3.0 Wrapper can point to VAST2.0 response.

4. VAST1.0 is obsolete, which means it is no longer supported in the IAB.

VAST3.0 This document has been overhauled with the expanded interpretation model features and expectations. Implementing a specific Ad server or video player implementation ticket has been added to help call the technical and expected important details.

4, VAST general overview

Online advertising uses a browser to display ads, and tracking ad behavior can use HTML to send data between many networks and servers. However, in video ads, the video player is not a browser and may not be able to use HTML. Video player is built on a variety of different technologies, each of which uses its own technology examples.

If an ad service provider wants to advertise in the player, they must develop an ad tag that is based on the player they want to run to display the ad. However, when multiple servers may be required as part of the process of providing advertising services, it is necessary to provide specific ad display information each, which can complicate ad delivery.

Vast is a video ad serving template that provides a unified way of advertising data transfer from AD servers to video players, independent of any technology. Use Xml,vast video ad serving, similar to HTML based ad serving on your browser.

just as HTML enables Web browsers to display any Web server's Web site, vast enables video players to display ads from any video ad server.

Vast supports video ads to any video player that can request and analyze XML documents . vast is not a device, a platform, which means it works in a number of video players, including the following:

• Web video Player
• In Mobile optimized web video player
• Video player in mobile app
• Internet-connected TV video player
• Video playback through IPTV or other set-top box environments

5. How VAST Works

Although vast was originally designed to promote the ad response of a standard video ad, it has come to include how the video player should handle the response. The latest version of vast provides guidance on how to display and track video players.

In general, vast's ad delivery involves the player requesting a video ad, showing vast's response, and sending tracking information about the ad exposure and other events to the server. This can be done directly between the video player and an ad server (usually released), or between a video player and multiple ad servers.

When the ad is delivered directly from the publisher's system to the video player, the vast ad delivery process is as follows:

• VAST requests (VAST request): The video player gives the ad Server a VAST response.

• vast inline response (AST inline Response): The ad Server responds to a vast inline response that contains all of the media files and traces needed to display and track the ad's URI.

• Trace Uri pinged (Tracking URIs pinged): A video player needs to track the resources, from the follow-up of events related to the ads in the URIs and other information.

In the scenario just described, only one ad server is involved. However, regular ad servers are booked directly. When multiple ad servers become part of the video ad delivery process, the benefits of vast become more pronounced.

Describes the process when a level two Ad server participates in AD serving:

• VAST requests (VAST request): A video player sends a request to the primary AD Server (primary ad Server).

• VAST Redirect (VAST Redirect): During the event, The Advertiser (possibly an organization or network) sends a VAST wrapper response to determine the resources of the level two ad server. The following example provides an excerpt of a broad package response:

• VAST requests (VAST request): After parsing the VAST response, the video player sends a request to level two ad server, this request uses a URI that is provided in the second part of the two-level VAST response.

• VAST Inline response (VAST inline Response): Level Two AD server sends a broad response that contains all the

The necessary details of the information to be displayed. The following example shows an overview of the vast element
For inline responses:
<VAST><Ad><InLine>
...
</InLine></Ad> </vast>

• Trace Uri pinged (Tracking URIs pinged): Once the ad for a particular event is triggered, each ad server receives a trace of the URI provided.

In the above scenario, two ad servers are involved. This situation typically occurs when one or more of the vendor's ad servers become part of this process, and both parties want to receive all the tracking information.

This ad-serving situation can easily expand over two ad servers. Secondary ad servers can respond to another ad server pointing to a vast wrapper. Eventually, however, the last Ad server in the chain must respond to a vast inline response .

VAST3.0 specification