By Amit Shetty
Over the last few months we have been asked a number of questions about the use of various video ad tech standards. We have seen a number of changes in the space like diminishing browser support for Flash, as well as major growth in mobile and Over-the-Top (OTT) video platforms. These factors have resulted in a number of new challenges in the delivery of video advertising. I am listing out a number of these technical challenges, especially around interactivity and verification. I will also provide a window into the direction the Digital Video Technical Working Group is headed in order to solve these issues.
“Fear and Loathing” in video advertising
Video ad revenue has been explosive growth over the last couple couple of years, so it is easy to forget that just nine years ago video was a relatively fledgling format, struggling with proprietary implementations, IAB and its members crafted the Digital Video Ad Serving Template (VAST) and Video Player Ad Interface Definitions (VPAID) specifications in order to serve video ads in a standardized, scalable manner. Nine year on, growth and innovation have led to these standards (especially VPAID) getting coopted for uses they originally weren’t intended for. This is why at the IAB Tech Lab we have been making some significant moves to simplify and clean up the digital video standards landscape.
First, let’s go through a quick rundown of some of the questions I get asked:
On verification:
- Is VPAID (Video Player Ad Interface Definition) the right answer for verification?
- Can’t I just use VAST (Video Ad Serving Template) instead of VPAID for verification?
- Should I use VPAID on mobile for verification? Should I use MRAID (Mobile Rich Media Ad Interface Definitions)?
- How do we do verification on SSAI (Server-Side Ad Insertion)?
- As a verification vendor, why do I have to handle interactivity?
- As a publisher, why should I implement all of VPAID to support viewability?
On interactivity:
- Can’t I just use VAST for interactive ads?
- Should I use VPAID on mobile or MRAID? Do I handle mobile in-app differently from mobile web?
- How do we do interactivity on SSAI?
- How do I solve the VPAID wrapper issues like latency or mixing of Flash / JavaScript ad units?
- How can I pre-cache assets for a VPAID ad?
Clearly a big part of the problem is a question of trust and access. Publishers (rightly) worry about allowing unknown/broken code on their pages. They worry about broken UX because of unknown code, inability to pre-cache, and code making waterfall ad requests. Verification vendors (and advertisers) on the other hand would like to have more access to the publisher page in order to credibly do their job. Both verification vendors and publishers uniformly don’t like how VPAID is required to handle playback control instead of the player. Creatives like to have more flexibility and fewer restrictions on how they build their interactive ads. With all these challenges, we as an industry need to set a clear path for the various use cases.
Current state of digital video advertising standards
The following is my view of the current state of video technical standards. This table covers the three key use cases in video advertising (delivery of video ads, interactivity, and verification) across mobile in-app and browser (desktop and mobile) environments:
This complexity and channel specific implementations are clearly a challenge for someone trying to support video ads across all channels.
Cleaning up the video ad ecosystem (aka the future)
First, a note about VPAID: VPAID is loved for its flexibility and the innovation that has been built on top of it, but, it is also feared – and for good reason. The two big problems with VPAID have been transparency and trust. Publishers are required to hand over playback control to the VPAID ad unit and lose control over the user experience. And when wrappers are added to this mix, publishers also do not know where the ads are coming from.
VAST 4.0 took a major step last year to cover some of these concerns by clearly identifying executable code and the purpose of the executable code (AdVerification and InteractiveCreative nodes). Now we are working on completing that vision in the Digital Video Technical Working Group, by building function specific standards (specific specs for Verification and for Interactivity) and by supporting a player-centric architecture. To that end, the VPAID spec will be retired, and will be replaced by 2 separate specs. Verification will be covered under the Open Measurement (OM) umbrella. The interactive specs do not have a name yet, but for the purpose of this blog post, I will temporarily call it “VPAID-i” (NOTE– since this blog was posted, VPAID-i has been released and named “SIMID”. More details here).
The following represents my view of the future:
- VAST to deliver the ad
- Open Measurement (OM) for verification
- “VPAID-i“ to build immersive interactive experiences and “VAST Interactive Templates” for simple/common interactive experiences (like end cards and simple overlays).
The details:
- Delivery: VAST
-
- In particular, VAST 4 and its separation of media file from all executable code
- Addresses transparency and trust issues. Publishers can identify the purpose of the executable (verification/interactivity) AND the source of the script, to then decide whether they want to run it or not. They can also control the level of access provided to those scripts.
- Addresses latency problems by allowing for pre-caching
- Supports SSAI
- Simplify delivery by allowing a single tag to work across mobile/OTT/desktop.
- In particular, VAST 4 and its separation of media file from all executable code
-
- Verification: Open Measurement
-
- No more VPAID and related problems for publishers and verification vendors.
- Single tag for all platforms (mobile in-app as well as desktop/mobile web)
- On mobile in-app video verification will be done using the Open Measurement SDKs (Software Development Kits).
- On web (desktop and mobile), video verification will be done using the Open Measurement HTML library
- The goal is for both mobile and web (and in the future OTT) to be supported using a single tag, with the corresponding SDK/library picked up automatically. This will be a major step forward in simplifying verification across the board.
- The verification script is delivered via the VAST 4 verification node- so trust is easily established
-
- Interactivity: “VPAID-i” (*to be named) and “VAST Interactive Templates”
- VAST Interactive Templates – for basic interactive experiences like end cards.
- These are not scriptable, and require publisher support to take UI assets and render interactive experiences. I am seeing proposals to standardize some of these extensions so that these are available at scale.
- The big advantage here is that it is something publishers will be more comfortable exposing since they control the UX, and it opens up access to OTT and other platforms where JS might not be available.
- Use “VPAID-i” to build advanced/immersive interactive experiences.
- “VPAID-i” is being worked on with a couple of core architectural goals in mind
- VAST 4 based “player centric” model which gives publishers control over the user experience and what gets run on their pages. They can now be confident that the ad unit will not “take over” the page/app.
- Support for SSAI
- Support all platforms including Mobile and OTT
- It is being built free of constraints to support verification or other unofficial uses of VPAID, which significantly simplifies the requirements.
- “VPAID-i” is being worked on with a couple of core architectural goals in mind
- Single tag for all platforms
- The goal with both “VPAID-i” and the VAST-templates is to allow advertisers to write a single tag for their interactive video ads.
- VAST Interactive Templates – for basic interactive experiences like end cards.
What does all this mean?
The main themes of the direction we are headed in are transparency, trust, and cross-platform support.
-
-
- Publishers get better control of their pages and user experience. Significantly improve latency issues and broken code issues. And no more black box mystery code running with full access on their pages. They can also choose to just support verification or interactivity or both.
- Verification vendors don’t have to worry about implementing unnecessary code (VPAID). They now have a process to be “trusted” vendors who publishers can provide more access to their code.
- Simpler flow for buyers, and better/more access to viewability data.
- A better approach to interactivity that works across all platforms.
- Clarity on what technology / standards to use for which use cases.
-
What should companies be working on right now?
-
-
- Delivery: Move to VAST if you are not there already. Ensure your VPAID is embedded within a VAST tag. Work on supporting VAST 4 ASAP. OM will also work with VAST 3.0/2.0 (using extensions), but it makes sense for your products to start supporting VAST 4 simultaneously since it provides native support for code separation. The separation of media file from interactive and verification code will not only result in better user experience, but will allow you to support OTT devices and SSAI.
- Interactivity: Use VPAID 2.0 (JS) where possible, and MRAID for “outstream” scenarios. In parallel, look at VAST-extensions for simple interactive experiences like end cards. Help us identify your challenges and build “VPAID-i” as well as “VAST Interactive Templates”.
- Verification: Start working on moving to Open Measurement immediately. Look at the mobile SDK that we recently released, and the web video proposal which will be out shortly.
- OTT: The OTT Technical Working Group will be looking into Verification and Interactivity in early 2018. Join us and help us get ready for OTT to scale!
-
Please email us at video@iabtechlab.com if you would like to learn more or if you have any feedback, or would like to discuss other related topics!
ABOUT THE AUTHOR
Amit Shetty
Senior Director, Product, Video & Audio
amit@iabtechlab.com