It’s Time To Move Away From VPAID

On TV And Video” is a column exploring opportunities and challenges in advanced TV and video.

Today’s column is written by Andrew Broadstone, director of product management at Brightcove. 

The advent of the VPAID era came with a lot of false hope and promises. VPAID – Video Player-Ad Interface Definition – was supposed to be a game changer for the industry, allowing advertisers and publishers to work in harmony.

VPAID allows advertisers to craft and execute digital experiences for viewers, including the highly sought-after interactive ads. It also offered the promise of viewability. And it was supposed to help publishers sell more in-stream video ads.

However, as more companies adopt VPAID, the problems keep mounting, mainly the lack of support for mobile configurations and broken code. The biggest issue I see is the unreliability of the VPAID scripts.

The Wrong Approach

According to the IAB, VPAID was developed to help address market inefficiencies for publishers, advertisers and vendors by increasing common video and ad supply technology, providing specifications for advertisers to develop against and improving the video ad fill rate.

While addressing these inefficiencies is a necessity, VPAID is not the way to do it. In fact, VPAID is creating more headaches. The overarching issue with VPAID is it’s the single greatest source of unreliability of ad delivery of digital video advertising.

It increases error rates and latency significantly. User experience and fill rates suffer when VPAID is used, even on platforms where it works, not to mention the platforms that don’t support VPAID scripts. The unreliability of VPAID should be a huge concern for publishers because it can drastically take away from the user experience.

Furthermore, VPAID excludes a huge amount of valuable inventory from monetization. VPAID simply doesn’t work on OTT or apps, and it’s hit or miss on mobile web (mostly a miss). When campaigns require VPAID for execution, they are not compatible with the devices that account for a growing majority of digital video views. With the use of OTT services skyrocketing in recent months, not being able to monetize that content because VPAID doesn’t work on smart TVs and connected devices is a missed opportunity.

Publishers have little to no control over VPAID since it is software that is installed on a website without allowing the publisher to test it or even to know when it is going live. As a publisher this should be a red flag: What happens if and when the code goes live but doesn’t work? It decreases the value of the experience viewers have, opening the door for viewers to click away from the site or close the app. Worse, the publisher may lose viewers for good because the experience is so bad.

Would a publisher ever take untested code in any other context and deploy it to their live site? The answer is an overwhelming no, so why should VPAID be the exception?

Possible Alternatives

With so many concerns about VPAID, there needs to be another option, right?

Alternatives to VPAID include using pre-installed, tested, client-side code for viewability reporting. Publishers could also use server-side RTB instead of VPAID-based client-side ad managers for client-side waterfalls, auctions and pass-backs.

VAST 4.0 has the potential to help by separating the ad creative from the VPAID script, but it is only just starting to emerge within the ecosystem. And it will take time because while VAST 4.0 is great for publishers, media agencies potentially lose some control compared to its second and third versions, and they will have to change tools and processes to make it work. The buy side needs to be convinced that the ability to reach more inventory is worth the upgrade.

In today’s world, advertisers want to measure everything. Some worry that publishers can’t be trusted and fear fraudulent plays of a video are being reported. Originally, VPAID was a godsend for advertisers because they were in control, and it didn’t require coordination with the publisher. However, as time goes on, more people are realizing it doesn’t work as well as it should.

There are too many variables with VPAID scripts, too many places where the script can break and too many devices where it doesn’t work at all. There are better, more efficient options out there that can provide a more comprehensive view of how video ads are performing.

In the end, the goal is to make money, and that won’t happen when VPAID is ruining viewers’ experiences.

Follow Brightcove (@Brightcove) and AdExchanger (@adexchanger) on Twitter.

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!


  1. Great article. Absolutely agree about the issues with VPAID which you have laid out well, BUT VAST 4.0 can give buyers what they need. InMobi supports a forward compatible version to VAST 4.0 (and is rolling out VAST 4.0 support, at this time) and we today support VAST + buffer-free video (which VPAID can’t provide) + Viewability + Programmatic Buying + interactive end cards. VAST without Trade Offs; Independent measurement and buffer-free (error free) mobile video! Industry adoption of this approach is growing. Important that buyers understand that VAST can support viewability since for several years buyers were taught that vpaid was synonymous with viewability which is no longer true.

  2. Great post. Completely agree with everything you said. I personally think that right now the best thing for our industry is to move to VAST 4.0. It’s the best alternative out there and is the most accepted solution to give all of us the next level of quality and control. I believe that we should all adopt it sooner rather than later and help have this become the de-facto standard ASAP.

  3. Great article. I know of at least one major publisher forwarding this to lots of people. There is no doubt that VPAID as-is pre-dates mobile and OTT, and was not created to take into account issues like limited bandwidth and either less capable or less permissive client-side devices. Expansion of VAST capabilities are IMO inevitable at this point, and make a lot of sense, especially when the Open Source Measurement SDK moves verification to the client. As you say however, relying on the current VAST model could easily be seen as overcorrection, shifting all the power to the sell-side rather than the buy-side. As such, I think the market should also be open to the improvement of VPAID to meet performance concerns as well as the evolution of additional standards that fully acknowledge issues on both sides of the market. The problems are becoming more clear. I hope we can all work together on the solutions!