By Pieter Mees, Timothy Olds, Simon Trasler
Possibly one of the most important new features in VAST 4.1 (Digital Video Ad Serving Template) is the specification of how to perform ad requests, which tackles a number of long-standing industry challenges and opens a path to more efficient video advertising. This blog post will explore the background and value proposition of these changes.
Traditionally, VAST has always defined what a video ad response should look like, without going into detail on how to perform the actual ad request. This is in contrast with specifications like OpenRTB (Real-Time Bidding) that explicitly discuss both bid requests and responses. The lack of a proper ad request specification unintentionally created several bottlenecks for the industry to move forward.
- For one, ad servers cannot tell what VAST version the requesting player supports, so they keep sending back VAST 2.0 responses for backwards compatibility. The same backwards-compatibility arguments would have been a threat to the adoption of Open Measurement to replace VPAID.
- A number of new use cases emerged that require standardized server-to-server ad requests, like server-side ad insertion.
- It also creates an information discrepancy between the bidding systems and ad servers. While the seller might include all sorts of information about the inventory in its OpenRTB bid request, there is currently no channel for this information to propagate to ad servers. This results in frustrating situations, for example when one advertiser system bids on non-VPAID inventory, only for the ad server to traffic a VAST tag with a VPAID creative that is incompatible with that inventory.
The only alternative for the industry has been to generate different VAST tags for different scenarios: a VAST 2 tag, a VAST 4 tag, with and without VPAID, one for server-side ad insertion, etc. Ad request signaling has been achieved with custom proprietary ad server macros that could differ from one vendor to the next. As the number of environments grows, this exponentially complicates trafficking workflows and the risk for a tag to end up in a context that it was not designed for.
This has been slowing down the industry as a whole and the launch of a new VAST version, and the introduction of Open Measurement felt like the right time to finally address this. With VAST 4.1, our objective was to move the specification to a point where advertisers can deploy “universal tags”, where a single VAST tag automatically “just works” across all kinds of inventory.
Challenges before VAST 4.1
1. Industry Gridlocked Around VAST Version Upgrades
Today, most video ad serving is still done with VAST 2.0, a standard dating back to 2009. This is despite 3.0 and 4.0 being released in 2015 and 2016 respectively. Adoption of new versions requires both players and servers to add support for it. This is not especially difficult, but neither party has a lot of incentive to make those changes if there is no adoption on the other side. This becomes a chicken-and-egg problem.
To make matters worse, while players can add support for newer versions and wait for a matching VAST document to come in, ad servers do not have that luxury. When a VAST request comes in, the ad server does not know whether the player supports these newer versions, so the safest, most compatible thing it can do is to serve the lowest common denominator: VAST 2.0.
Solution: In order to help the industry gradually transition, we need a way for the ad request to signal what VAST version the player supports and is willing to accept from the ad server. This then allows ad servers to send back the most recent VAST version that both the player and the server supports. As more ad servers and players add support, the industry automatically upgrades to newer VAST versions over time.
2. VPAID Deprecation Held Back
A similar problem exists in migrating viewability measurement from VPAID (Video Player Ad-Serving Interface Definition) to the new Open Measurement specification. If an ad server does not know whether a player supports Open Measurement (OM), the only backwards-compatible thing it can do is to include a VPAID file for measurement, just in case. This means even OM-capable players would still have to run VPAID.
Solution: The ad request can now indicate which API frameworks the player will support: VPAID, Open Measurement and any future frameworks that might get introduced. That allows the ad server to respond with something that will be compatible: Open Measurement if supported, VPAID if not.
3. Universal VAST tags
If we take the abstraction of the above two problems, we want to reach a situation where there is only a single VAST tag to traffic to all destinations, regardless of whether that destination is desktop out-stream, in-stream, in-app, OTT or other. The objective should be that a single ad tag can live in all these worlds and “do the right thing”.
Before VAST 4.1, this was a complex proposition because it meant that the ad server needed to send back every single potential resource and feature in its VAST response, in the hopes that the player would pick up on most of them and render the ad correctly. But there was no way for the ad server to know that the player would in fact do that.
Solution: With VAST 4.1 we are introducing a way for the video player to share its capabilities and desires with the ad server upfront as part of the ad request, so Universal VAST Tags become a realistic scenario.
4. Server-to-Server Requests Are Unspecified Behavior
More and more use cases require server-side VAST fetching or pixel tracking. Server-side ad insertion (SSAI) is the most notable example, but bid-level VAST prefetching and verification wrapping are other scenarios. In general, all these scenarios are beneficial to the industry: improving user experiences, lowering ad loading times and reducing client-side workload. Unfortunately, while there are implicit understandings about how to perform a client-side request, no such market consensus exists about server-side requests and many systems are not correctly set up to deal with them.
Solution: VAST 4.0 addressed questions about how the VAST response should support SSAI use cases. Now VAST 4.1 fills in the gaps regarding the ad request itself.
URL Macros
The working group spent several months devising and evaluating multiple possible solutions to these problems. We looked at using URL macros, new HTTP headers, and posting JSON to the ad server. Eventually we settled on an approach that is fully backwards-compatible, well-understood in the industry and deals correctly with HTTP redirects and other edge cases. It involves URL macros and HTTP headers for some server-to-server signaling.
VAST 4.1 introduces an extensive list of macros that are supported across the VAST tag URL and tracking pixel URLs. Check out the full list in section 6 of the specification.
Among others, these macros allow servers to inspect all sorts of information from the video player and provide back personalized, optimized responses.
Some examples:
Both clients and servers, should fill in these macros in the VAST URL and tracking pixels. Most macros are optional and special values indicate if a value is unknown or cannot be shared.
It is important to note that while these macros are part of the VAST 4.1 specification, clients that adopt them will be sending them out on all VAST requests even when those end up resulting in a VAST 2.0 or other version response. This is because those clients cannot know upfront what version they will get back. As such, these new macros apply as much to older VAST versions as they do to VAST 4.1.
HTTP Headers
VAST 4.0 introduced a number of HTTP headers for tracking pixels fired by SSAI servers on behalf of a client.
In VAST 4.1, we are expanding this to cover server-to-server VAST requests as well, and are standardizing more information to be passed along.
When both old and new headers are present, servers should prefer the newer ones.
Conclusion & The Future
We believe the new ad request capabilities included in VAST 4.1 are real game changers, addressing significant market challenges.
The VAST request specification will
- reduce breakage and increase fill rates by allowing ad servers to traffic compatible responses
- speed up the transition of viewability measurement from VPAID to Open Measurement, and the adoption of new VAST versions
- improve user experiences by avoiding expensive, unnecessary VPAID loads
- enable new server-to-server use cases that reduce latency and client-side workloads
Given the significant benefits, it comes as no surprise that several industry players have already signaled their support and plans to implement these changes.
If you are performing or responding to VAST requests, we highly recommend that you take a look at the relevant sections of the new specification and consider implementing them to the fullest extent.
While this is a huge leap in the right direction, the working group intends to continue improving support for these scenarios in upcoming work. As we do so, we welcome all industry feedback and would like to invite all interested parties to join us in the IAB Tech Lab Digital Video Working Group!
VAST 4.1 Blog Series
Simplifying Interactivity Standards with VAST 4.1| Now with Audio Power | The Long Awaited Video Verification Solution! | IAB Tech Lab Releases Final Version of VAST 4.1
ABOUT THE AUTHORS
Pieter Mees
CTO & Co-Founder, Zentrick
Pieter is co-founder and CTO at Zentrick, a leading platform company for the video ad tech industry. Additionally, Pieter is a key contributor to several of the IAB Tech Lab working groups, actively participating in and co-authoring the VAST 4.1 specification.
Both Pieter and Zentrick have built extensive experience with VAST and VPAID, by handling tens of billions of video ad impressions on behalf of large verification vendors, SSPs and other customers. The company continues to launch first-to-market innovations like server-side wrapping, and VAST ad acceleration.
Pieter was born and raised in Belgium (Europe), studied Civil Engineering and Computer Sciences at Ghent University and founded his first company in 2004. He enjoys programming, reading and traveling. He is on a frequent flyer schedule, switching between Zentrick’s main offices in Belgium and his home base in New York City.
Timothy Olds
Product Manager, Google
As a product manager on Google Ad Manager’s video platform, Tim Olds exercises his obsession with efficiency and transparency by working to improve interactions between ad servers, whether it’s buyers and sellers or TV content owners and distributors. When not dreaming about the optimally-decisioned TV ad break, he’s dreaming about how to optimally report on it.
Simon Trasler
Vice President, Engineering, Rubicon Project
As VP Engineering at Rubicon Project, Simon is responsible for all the components for real-time ad serving. Prior to this role, he led several engineering teams working on similar high-performance, high-throughput systems in the finance sector, in the US and UK. He holds a bachelor’s and doctoral degrees in Mathematics.