It’s Time To Say Goodbye To VPAID, For Real This Time 

Mike Chowla PubMatic

"The Sell Sider" is a column written by the sell side of the digital media community.

Today's column is by Mike Chowla, Sr. Director of Product Management at PubMatic and video chair for Prebid.

The retirement of VPAID has been announced several times, including in 2017 and 2019. However, as of May 2021, VPAID is still widely used.  If VPAID could talk, it would surely use the Mark Twain quip, “The report of my death was an exaggeration.”

But times are changing, and 2021 could be the year VPAID finally will be retired. Tech providers, publishers, and buyers should start preparing now.

VPAID is a standard for video ad creatives that allows for JavaScript execution on web pages along with the video ad. The full details get quite technical, but it’s enough to know VPAID allows for arbitrary code execution as part of the ad. That “arbitrary” allowance creates both security risks and compatibility issues.

VPAID is widely used on the web for execution of measurement code.  Buyers use VPAID as  a window into viewability and other metrics -- but newer, better options are taking its place, specifically Open Measurement, which works across channels and has lower error rates.

What’s wrong with VPAID? 

The biggest issue with VPAID after the security risk is a high rendering failure rate. When a video creative fails to render, publishers do not get paid for the impression. Every percentage point of error rate costs publishers revenue.

There’s a lack of published data on VPAID error rates, but based on conversations with participants across the ecosystem, my benchmark is that a 30% error rate with VPAID creatives is average, and that rate can easily spike higher. In contrast, non-VPAID creatives tend to have half the error rate of VPAID creatives.

Moving to non-VPAID creatives will bring other benefits for the buyers. Some publishers never allowed VPAID on their sites due to the security risks. What’s more, VPAID was designed specifically for the web environment. Retrofitting VPAID to mobile in-app and CTV was problematic due to historical device constraints and thus never became widespread on those platforms.

Using non-VPAID creatives, and relying on Open Measurement for measurement, means one creative can run across multiple platforms. The newer standard opens efficient avenues for advertisers to reach their audiences.

The reduction in failure rate alone is reason enough for publishers to phase out VPAID. Publishers will, of course, want to weigh the reduction in error rate against loss of demand from VPAID creatives. However, once enough demand switches to using Open Measurement, there could be a tipping point as publisher revenue will rise from turning off VPAID.

What’s different this time 

As an industry, we’ve been aware for years that VPAID can be problematic. Until recently, VPAID was the only option for making web video ads measurable.  What’s changed is that we are at the cusp of the widespread availability of Open Measurement for web video ads.

Open Measurement standardizes viewability and other metrics like invalid traffic and brand safety in a secure and uniform manner across key channels like CTV and mobile. Since the IAB Tech Lab released the in-app Open Measurement SDKs in April 2018, Open Measurement has been successful in improving in-app video ads. Importantly, Open Measurement has negligible failure rates and stronger security protections.

In December 2020, the IAB Tech Lab announced the availability of the Open Measurement Web SDK.  The most widely used video ads library, Google’s IMA [Interactive Media Ads] SDK for video ads, released Open Measurement for the web as beta functionality in February 2021. Once Open Measurement becomes a general availability feature in Google’s IMA, our industry can phase out VPAID, and the entire ecosystem will be better off.

How to prepare 

VPAID’s longevity, despite its shortcomings, means many in the industry are not prepared for VPAID’s retirement.

We are now on the cusp of a better option for the one significant benefit VPAID provided: measurability. This is not the time to be complacent.

Publishers should join the Open Measurement beta on the web to start measuring the benchmark improvements. Joining the Open Measurement beta in IMA HTML5 SDK allows publishers to compare the error rates and other metrics between Open Measurement and VPAID to see for themselves what improvements they should expect when the market switches over.

Most ad servers can report on video errors. To make comparisons, publishers can multiply the error count by an average video CPM to understand financial impact from video errors. Turning off VPAID will often result in a 50% reduction in errors. Publishers can run an A/B test with VPAID off on a portion of inventory and then measure where revenue per video opportunity is higher with VPAID on or off.

Whether publishers decide to opt-in for the Open Measurement beta or not, it’s valuable for publishers to understand the opportunity loss. Just check what percentage of video inventory is lost to errors from failure to render. This check can help get your company motivated to transition to Open Measurement more quickly after the general release.

Once Open Measurement for web video becomes widely available, the industry could shift away from VPAID rapidly. Even publishers that don’t join the beta should watch closely to understand what the changeover will mean for their businesses.

As the beta picks up steam, those benefits would likely become even more clear in the coming months, serving as a driver to motivate even the most complacent teams to prepare for the switch.

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>