If you’re a broadcaster that can replicate the seamless, ad-supported viewing experiences of TV across all of your digital products, you will drive high engagement and more ad inventory. The more screens on which you can accomplish this feat, while successfully avoiding ad blockers, where present, the greater your revenue opportunity. The more scalably you can execute – by avoiding endless native player development –- the lower your cost basis and the quicker you are to profitability.
The enabling technology for this rosy scenario is server-side ad insertion (SSAI) which figures prominently in the Interactive Advertising Bureau (IAB)’s introduction of VAST 4.0.
The Video Ad Serving Template, or “VAST,” specification sets a standard for communication requirements between ad servers and video players. It tells the video player what it is supposed to do when receiving a VAST-formatted ad response from an ad server:
- What video ad should be played
- How that ad should be played
- What should be tracked as the ad is played
The spec hasn’t been updated since 2012, and the main industry trend necessitating this update is SSAI, the technology we use in Brightcove Once and Brightcove Lift. As we covered in the comprehensive whitepaper released yesterday, SSAI is an effective technology for beating ad blockers and executing seamless, monetized, TV-like playback across mobile web and devices – some of which lack client-side capabilities.
The IAB said as much upon releasing VAST 4.0 for public comment – confirming that it “was updated to support in-stream ad delivery in long-form video and in devices that lack the capacity to accommodate client-side tracking.” The comment period is scheduled to close on 12/2.
Scenario Testing with SpotX and the IAB
Given that Brightcove Once is an industry-leading stream-stitching/SSAI solution, it made sense for Brightcove to team up with SpotX and its CTO, Allen Dove, during the comment period, to help prove out the efficacy of the VAST 4.0 spec. We’ll look to cover the scenarios in greater depth in a future post, but here, I’ll hit a few of the highlights of what the spec allows and what it means for Brightcove Once and Lift customers. VAST 4.0 addresses:
- Support for Universal Ad ID: Universal Ad ID ensures that an individual video ad will have a single unique ID across publishers and campaigns which has two big benefits. First, it improves the data collection and reporting pain that agencies and advertisers have when running cross platform campaigns. Second, it prevents a stitching service from thinking that a creative that it has already seen needs to be processed for the first time - which should improve inventory fill rates.
- Conditional ad declarations: Today, an SSAI solution doesn’t know whether the ad returned by the ad server is going to have elements of interactivity (like click to expand functionality). Some ads may not perform as intended in certain endpoints, and rather than trying to deliver an ad and failing, Brightcove Once will see the conditional ad declaration that warns of interactive elements and can (i) avoid a broken user experience while (ii) potentially filling the impression by making additional ad calls for linear video creatives.
- Timeout expirations: Brightcove Once requests ads in advance of delivering them into a mid-roll position in a stream. If there is time out information on the ad, the system makes a determination on whether or not to serve an ad based on the time of the request and the position of the ad relative to the stream. This logic allows customers to maximize their monetization and to prevent ads from being served that would potentially have their impressions thrown out and therefore be unplayable due to an expiration.
- Server-side ad tracking: This part of the spec explains that the ad server should be looking for the IP address as forwarded on by the stitching service to avoid the confusion of seeing the same IP address on each tracking pixel. Brightcove Once already does this today, but this is a helpful clarification in that the IAB is saying the ad servers should be accepting “x-forwarded-for” header values.
- Ad server responses can include the ad mezzanine file: This is good because Once may use the raw mezzanine file to encode a version specific to the needs of certain environments, and this parameter in the spec will explain if that file is available and, if so, where. Having access to a high-quality ad mezzanine file allows Once to condition the ad in the same bitrate and format as the primary video content to ensure seamless, TV-like playback and continuity. However, Once doesn’t require the mezzanine and can pull the highest available rendition of a creative and make it work.
- Error event info: Analytics are key for understanding the technical health of an online video workflow, and this concept requires the player to indicate what problem occurred when an ad didn’t serve. In VAST 4.0, there are three new error explanations that are important for the SSAI scenario: (1) mezzanine required/missing (2) ad still processing/stitching, and (3) conditional ad rejected. The important intel here is that none of these errors are the fault of the ad server. From Brightcove’s perspective, Once will not use error #1 as we will not be restricting or requiring the mezzanine per point 5 above. Once will signal errors #2 and #3 when appropriate to allow customers to view/aggregate these events from the ad server analytics.
Both Allen and CBS Interactive’s Jarred Wilichinsky are members of the IAB’s working group on VAST 4.0, and I had the privilege of moderating a discussion that included the two of them at Streaming Media West this week in LA. With Jarred’s deep understanding of why the spec matters to publishers, and Allen’s insights on how it will play with the ad serving and demand sides of the video advertising equation, they were able to address a lot of the questions in the room during Q&A. To see that discussion please keep an eye on the conference’s website for the video, and in the meantime, enjoy the whitepaper.