VAST and Furious – Accelerating your knowledge about VAST

Just like the Fast and Furious franchise revolutionized street race action cinema, VAST has been a game-changer in the world of in-stream video advertising. Whether you’re an advertiser burning rubber to reach your audience or a content publisher building the racetrack of engaging media, VAST is the high-octane fuel that keeps the engines running smoothly.

But let’s pump the brakes for a moment. What makes VAST so pivotal in digital video advertising? How did it evolve from its first version, VAST 1.0, to the powerful tool it is today? Grab your racing gloves as we navigate the twists and turns of VAST’s development, its various versions, and its indispensable role in modern advertising.

What is VAST

The Video Ad Serving Template, better known as VAST, is a universal translator in the complex landscape of video advertising. Established by the IAB in 2008, VAST offers a set of guidelines that facilitate smooth interactions, specifically with ad servers, ensuring that ads are served correctly and effectively.

VAST operates on XML, a versatile coding language, to shuttle essential information to ad servers. Think of it as a mediator that standardizes how ads are managed and displayed, making the entire advertising process more seamless for publishers and advertisers alike.

Among other things, VAST provides details about where an ad should be sourced from, its display timing, duration, and even its format and pricing particulars. This level of comprehensive instruction is beneficial for standard ad serving and server-side ad insertion (SSAI) methods.

History

Life before VAST

Before the introduction of VAST, there was no standardized in-stream advertising protocol for video players, making scalable distribution of ads impossible for ad servers. Advertisers had to ensure their ad server was compatible with each publisher’s unique video player. Ad creative had to be explicitly coded for each targeted proprietary player. If compatibility issues arose, an alternative ad response had to be generated. It necessitated that ad-serving organizations create slightly different ad responses for every publisher or video player they targeted, a process that was both costly and difficult to scale.

VAST 1.0 – The Dawn of Standardization (2008)

VAST 1.0, the first iteration of the Interactive Advertising Bureau’s (IAB) Video Ad Serving Template, emerged in 2008 as a groundbreaking step towards standardizing in-stream video advertising. It employed an XML schema that enabled a universal protocol readable by various video players, regardless of their technical infrastructure. It provided guidelines on how a video player should fetch and display ads.

This first standard was particularly significant for ad delivery, making it more streamlined for advertisers and content publishers. Advertisers could use a single ad response format for the first time across multiple video players.

On the technical front, VAST 1.0 was limited to supporting linear ads in single media file formats such as MOV, MP4, and 3GP. Functionality-wise, it allowed users to play, stop, and pause video ads. Additionally, VAST 1.0 incorporated basic event tracking features, allowing advertisers to collect elementary data on audience engagement.

VAST 2.0 – More Features, More Flexibility (2010)

Unlike VAST 1.0, which only supported linear ads and single media file formats, VAST 2.0 introduced in 2010 support for non-linear ads and multiple media files (Flash and Javascript), allowing advertisers greater flexibility in the types of content they could deliver. It also added key features like companion ads, which could run alongside the video or overlay it.

Furthermore, VAST 2.0 completed tracking capabilities to provide more nuanced data on how audiences interact with ads.

These improvements offered advertisers and publishers richer functionalities and paved the way for more interactive and engaging ad experiences for viewers.

As Google was stating at that time (quote from the IAB PR): “By standardizing ad serving on VAST, we can open the floodgates of agency media spend and allow publishers to maximize their yield per video view” said Ari Paparo, Group Product Manager, Advertiser Products of Google.

VAST 3.0 – Advancements in Monetization (2012)

One of the significant advancements brought by VAST3.0 in 2012 was the introduction of ad pods.

An ad pod is a pool of video ads served back-to-back within a single ad break during video content playback. It’s like a commercial break you would see on traditional television but for online video content. They can vary in length and may contain different ads from various advertisers, such as skippable and non-skippable ads. The idea was to create a more seamless and less disruptive viewing experience. Instead of scattering individual ads throughout the video content, the ads are grouped in an ad pod, allowing the actual content to play for longer uninterrupted periods.

The ads within an ad pod are usually arranged in a specific sequence, and the entire pod is typically treated as a single unit for inventory purposes. Ad pods are particularly popular in long-form content, like movies or TV episodes, where mimicking the traditional TV experience is often desirable.

Ad pods was the real innovation of VAST3 with the “sequence” attribute. Indeed, ads in a pod are differentiated by the sequence attribute for an <Ad>, which indicates which ad plays first, second, and so on. Ad pods are played in numerical order if the player supports them, and all commercials in the pod should be played to the best of the player’s ability.

Ad Pods still have repercussions today for new deployments, an example being in France with the implementation of the “TV Segmentee” which reuses that number to trigger Linear Ad Replacement.

VAST 3.0 also significantly expanded its event-tracking capabilities. Besides basic metrics like starts, stops, and completions, this version introduced quartile tracking, which measures how much of the ad a viewer has watched at several points throughout the ad playback (e.g., quartiles 25%, 50%, 75%, 100%). This granularity in tracking metrics allowed advertisers to gain deeper insights into viewer engagement and ad effectiveness, subsequently informing more nuanced marketing strategies.

One notable inclusion was compliance with Online Behavioral Advertising (OBA) guidelines. VAST 3.0 supports the display of in-ad privacy notices, providing viewers with essential information on how their data is being used, a critical component in the age of data privacy concerns.

Another one is the introduction of enhanced error reporting capabilities. This feature is invaluable for advertisers and publishers as it offers specific details when an ad fails to run as intended. These error reports help quickly diagnose issues related to compatibility, server problems, or other technical glitches, making the advertising process more transparent and efficient.

Finally, the last addition was skippable ads, a feature that was supposed to improve user experience by giving viewers more control and enabling advertisers to gather data on viewer preferences. Nevertheless, this feature has yet to be successful outside of the Youtube sphere. Indeed, in the Traditional TV ecosystem, Skippable Ads have yet to have the popularity reached in UGC platforms.

VAST 4.0 – Meeting Modern Needs (2016)

With the rise of high-quality video content, advertisers demanded better ad quality and delivery. VAST 4.0 addressed many of the complexities and limitations of earlier versions while introducing sophisticated features tailored to modern advertising needs. Please note that VAST 4.0 is still under deployment and not highly generalized.

One of the most considerable enhancements is separating media files from the VAST document, allowing for more versatile and streamlined ad delivery. This facilitates using mezzanine and high-quality source video files that can be transcoded and optimized for various platforms, thus ensuring a higher-quality user experience. The objective here is to find an alternative to the VPAID API, which faced some unpopularity in the web world (Some claim that a single VPAID ad that displays a single video at a time generates thousands of HTTP requests), and move to OMID and SIMID APIs to handle proper Verification and Interactivity.

Two other features are noticeable:

• <UniversalAdId> as a key to access the “ClearanceStatus” of the creative, which is required on TV Sets.
• Standard MACROs in the VAST request to allow third parties to get more dimensions to analyze and then decide upon

The version also focuses on improved measurement and verification capabilities. VAST 4.0 introduced the concept of Ad Verification, allowing third-party verification services to monitor the viewability and performance of ads better. It also added more detailed error reporting, enabling a more thorough diagnosis when things go wrong, thereby streamlining the troubleshooting process.

Furthermore, VAST 4.0 also brought a commitment to greater transparency and user privacy, aligning with industry best practices. It supports categories for ads, allowing publishers more control over the types of ads displayed, and it also includes features aimed at better compliance with regulations such as GDPR.

Initiated in 2014 as a specialized version of VAST 3.0 to handle audio advertisements, DAAST (Digital Audio Ad Serving Template) is presently being folded back into VAST 4.0.

While it was possible before, this version brings the official introduction of server-side ad insertion (SSAI) support.

VAST 5.0 and Beyond (2018-??)

VAST 5.0 has yet to be released, but it is planned to be version 4.3 with JSON support.

To summarize

Getting into more details

How does VAST is used in CSAI and SSAI?

Video Ad Serving Template (VAST) plays a crucial role in both Client-Side Ad Insertion (CSAI) and Server-Side Ad Insertion (SSAI), two dominant techniques in the realm of video advertising. However, how VAST is utilized differs significantly between these two approaches.

Client-Side Ad Insertion (CSAI)

In CSAI, the video player is responsible for pulling and inserting ads into the video stream. When the viewer hits play on a video, the client-side player fetches a VAST tag from the ad server. This VAST tag, typically in XML format, contains the metadata about the ad, such as where to find the ad media, how long the ad should play, what clickable actions should be available, etc. The video player interprets this VAST tag, requests the specific ad content, and plays it back at the appropriate time (e.g., pre-roll, mid-roll, post-roll).

Server-Side Ad Insertion (SSAI)

SSAI, on the other hand, offloads the task of ad fetching and insertion to the server. In this model, the video content and ads are stitched together into a continuous stream before being delivered to the viewer. Here, the VAST tags are interpreted server-side, and the ads specified in those tags are fetched and inserted directly into the content stream. This pre-stitched stream is then sent to the video player, making it appear that the entire video—including ads—is a single piece of content. SSAI offers a more seamless viewer experience as it mitigates issues like buffering and is less prone to ad blocking.

In that diagram, your devoted broadpeak.io service is the “ad-stitching service,” preparing the ads via transcoding and packaging.

VAST ad requests to the ad server

The methods for making ad requests to the ad server differ depending on the kind of inventory involved.

• In the case of programmatic advertising slots, the industry standard for these requests is OpenRTB, which may also include a VAST response within the OpenRTB reply.
• On the other hand, there is currently no established standard for ad requests for non-programmatic situations. Instead, these are governed by custom agreements between publishers and ad servers. Such requests usually take the form of an HTTP GET request, accompanied by additional information in the URL’s path or as key=value query parameters. This supplementary data often blends platform-specific parameters with universally relevant information, such as device IDs, contextual elements like domain or app ID, and the video’s placement within the content.

Don’t forget that Ad Servers need to be able to receive tracking of impressions and errors from the server or the media player.

Dissecting a VAST answer

Here you have an example of a 3.0 VAST answer:

<VAST version="3.0">

  <Ad id="12345">

    <InLine>

      <AdSystem>Sample Ad Server</AdSystem>

      <AdTitle>Sample Ad</AdTitle>

      <Description>Sample ad description.</Description>

      <Creatives>

        <Creative>

          <Linear>

            <Duration>00:00:30</Duration>

            <MediaFiles>

              <MediaFile type="video/mp4" width="640" height="360">

                <![CDATA[http://example.com/path/to/mediafile.mp4]]>

              </MediaFile>

            </MediaFiles>

          </Linear>

        </Creative>

      </Creatives>

      <Impression>

        <![CDATA[http://example.com/path/to/track/impression]]>

      </Impression>

      <TrackingEvents>

        <Tracking event="start">

          <![CDATA[http://example.com/path/to/track/start]]>

        </Tracking>

        <Tracking event="complete">

          <![CDATA[http://example.com/path/to/track/complete]]>

        </Tracking>

      </TrackingEvents>

      <ClickThrough>

        <![CDATA[http://example.com/path/to/click/through]]>

      </ClickThrough>

    </InLine>

  </Ad>

</VAST>

Here is a description of the different lines:

• <VAST version="3.0">: Indicates the version of the VAST standard being used, essential for compatibility.
• <Ad id="12345">: Provides a unique identifier for the ad, valid for tracking and analytics.
• <InLine>: Tells the server the ad details are provided directly in this XML instead of being linked from somewhere else.
• <AdSystem>Sample Ad Server</AdSystem>: Identifies which ad server manages this ad, essential for troubleshooting and analytics.
• <Duration>00:00:30</Duration>: Specifies how long the ad will run, a critical piece of information for publishers and viewers.
• <MediaFile type="video/mp4" width="640" height="360">: Describes the media file to be played, including its format (e.g., MP4) and dimensions. This is the actual content the user will see.
• <Impression>: Specifies the URL to ping when the ad is viewed, which is crucial for tracking ad impressions.
• <Tracking event="start"> and <Tracking event="complete">: These are event trackers essential for understanding user interaction with the ad. The “start” event is triggered when the ad starts playing, and the “complete” event is triggered when it finishes.
• <ClickThrough>: Specifies the URL to which the user will be routed if they click on the ad, which is critical for increasing user engagement and tracking click-through rates.

VAST tracking

VAST tracking uses individual tracking elements corresponding to specific events like video start or completion. Each element points to a server-side resource, traditionally a 1×1 pixel image, but sometimes a script or document. These resources are called upon to measure specific video events.

The publisher makes these requests when such video events occur during playback. It is especially crucial in server-side ad insertion (SSAI) cases, where timing and client-side information must be carefully managed. Even with SSAI, Client or Server Side Ad Tracking is possible.

Accurate tracking is vital for billing, campaign effectiveness, and market analysis, among other business needs. While the publisher is responsible for initiating these tracking requests, handling the response is not mandatory. Of course, good tracking practices are essential for the ongoing success of digital video and audio advertising.

In the future, tracking will likely be associated with attention metrics, which promise to give brands a deeper perspective on advertising impact.

What are some typical frustrations with VAST, and how can they be avoided?

VAST is unavoidable in delivering video ads, but it comes with challenges.

• Timeouts:

One of the most frequent frustrations with VAST is the occurrence of timeouts. Timeouts arise when the ad server takes excessive time to respond, which could result in the loss of an ad play opportunity. For example, a user is watching a series of short videos. If a timeout occurs during an ad request, they might experience an awkward pause or delay between videos, disrupting their viewing experience. Monitoring server response times and setting reasonable timeout thresholds is essential to avoid this.

• Empty VAST:

Another common issue is the empty VAST response. It happens when the ad server returns a VAST tag but lacks ads. Imagine an advertiser booked a prime ad slot during a live event, but no ad is played due to an empty VAST response. An empty VAST represents a lost revenue opportunity. To circumvent this, always ensure that your ad inventory is correctly filled and regularly validate the VAST responses for content. Utilizing fallback ads can also be an effective strategy, ensuring that even if the primary ad doesn’t load, another ad will take its place. Please note that this error can be expected in some cases.

• Multiple Redirects:

The issue of multiple redirects is particularly vexing. It arises when an ad request is passed from one server to another in a series of redirects. It typically happens in a Programmatic scenario when the ad server redirects the VAST request to a different SSP. It can be problematic. Think of it like a parcel being passed between multiple postal services before reaching its destination. With each additional step, there’s an increased chance of delay or even a lost parcel.

Similarly, with excessive redirects, there’s a risk the ad won’t play at all. To address this, try to minimize the reliance on chained redirects. Work closely with partners to ensure that direct integrations are in place, reducing the need for multiple hand-offs.

• Error Codes:

Encountering error codes without comprehensive explanations is another challenge. These codes can sometimes be cryptic, leaving developers and ad operations teams scrambling to determine the cause of the issue. For instance, receiving an “Error 303” without proper documentation can be frustrating and time-consuming to troubleshoot. It’s crucial to have a precise error-handling mechanism that provides explicit details on each error code. This can be supported by maintaining updated documentation that elucidates the meaning of each error and potential solutions.

Please find below the VAST error codes and their description – if you face them and are stuck, reach out if you are looking for ways to resolve them!

What is next for VAST?

While the IAB is still working on the following versions of VAST, here are some ideas of possible topics of interest for possible evolutions:

• VAST and Accessibility: In an era where inclusivity and accessibility have become paramount, there’s an increasing emphasis on how VAST standards can better cater to users with disabilities. Current VAST implementations allow accessibility, such as providing captions or audio descriptions. However, there remains a vast expanse of potential improvements. As technology progresses, we hope to see VAST standards incorporating more advanced features like voice commands, tactile feedback for the visually impaired, or even integrations with assistive devices to make ads universally accessible.
• VAST and the Future of VR/AR: Virtual and Augmented Reality platforms are not mere trends; they’re shaping up to be the future of digital consumption. The need for evolving VAST standards becomes evident as these platforms gain traction. Advertisers will soon need to consider ads in 3D spaces, immersive environments, or interactive AR overlays. The successive iterations of VAST might well incorporate specifications for spatial audio, 3D ad placements, or interactive holograms, offering unprecedented engagement with audiences.
• VAST and User Experience: Efficiency in ad delivery has been a significant focus, but it’s high time we also prioritize the enjoyability and relevance of these ads. With AI and machine learning developments, the future of VAST could see advertisements that are not only targeted but also contextually aware. Imagine watching a travel documentary and being served an ad that’s not just for a holiday package but one tailored to your past interests, current mood, and even the weather outside. The convergence of VAST with predictive analytics could redefine what personalized advertising truly means.

Conclusion

From its inception in 2008 to its ongoing evolution, VAST has undeniably shaped the world of digital video advertising. VAST’s journey underscores the industry’s commitment to adaptability, user experience, and progress as technologies and viewer habits change.

The future promises a more inclusive, immersive, and intuitive ad experience, focusing on attention and engagement. Embracing these opportunities will ensure that VAST remains at the forefront of digital advertising innovation, catering to advertisers and users in the dynamic digital age.

Banner photo from Pixabay: https://www.pexels.com/photo/action-asphalt-back-light-cars-434450/

Mathias Guille

https://linkedin.com/in/mathiasguille

Mathias Guille is the Vice President Cloud Platform at Broadpeak. He leads the strategic development of Broadpeak’s cloud platform, including the building of the company’s infrastructure in the cloud and in public datacenters, the design of Broadpeak’s platform on top of the infrastructure and the shaping of the company’s applications to accommodate SaaS offerings.