Fix Your VPaid Wrapper Immediately

ted-dhanik-tvOn TV And Video” is a column exploring opportunities and challenges in programmatic TV and video.

Today’s column is written by Ted Dhanik, CEO at engage:BDR.

Publishers, here’s why fill rate is low. Advertisers, this is why viewability is dismal and campaigns aren’t serving effectively.

As browsers drop support for Flash, ad servers aren’t keeping pace. The majority of ad servers have not developed JavaScript VPAID wrappers – they’re still Flash-based – and until they do, I believe all players in the digital ecosystem will lose out.

Picture this: A brand or agency creates two versions of its creative, Flash and an HTML5-supported video file. They upload the creative and think they’ve done their job. We’ve talked Flashpocalypse to death, right?

But the problem lies in the middle, with intermediary ad servers that haven’t created a JavaScript VPAID wrapper, which facilitates ad unit and ad player communication. It is this wrapper that allows us to learn all sorts of useful things about the environment in which the ad will serve, such as player size and page-level domain. Without it, an impression is not viewable in HTML5.

VPAID Wrappers Impact Publishers And Advertisers

In my experience, VPAID wrapper issues are the No. 1 reason why publisher fill rates aren’t where they should be. In the video ad ecosystem, video demand is classified as either JavaScript/HTML5 or Flash. Advertisers label creative file types accordingly, but even if they do so correctly, their ad will not serve if it is executed with a Flash-based VPAID wrapper. Basically, we have rendered our classification system irrelevant.

The damage does not stop there. A publisher wants to monetize as much of its inventory as possible, so it may stop serving the demand source’s impressions entirely when it realizes that it is bidding on traffic but not actually filling it when it wins.

Let’s say I am a publisher with a video impression to fill. The user is in Chrome, where Flash is blocked. I call on a demand partner and that partner, an ad network, responds with its tag. Its VPAID wrapper is Flash-based. The ad cannot be executed, regardless of whether or not the advertiser used the correct file type. That impression dies.

Why am I, the publisher, going to keep working with someone who doesn’t fill the impressions they buy? I am going to automatically optimize that partner out, and then the advertiser ends up confused and frustrated when the campaign is not fulfilled.

Publishers are upset because their fill rates aren’t strong, and demand partners are irate because their campaigns aren’t serving and viewability is dismal. Video players are also contributing to this issue. Not all are updated to support JavaScript VPAID, and many publishers have yet to update their player versions. Furthermore, a lot of technology still uses Flash to measure viewability. That was the easiest way to do so because the Flash plug-in provides this information. Now, organizations need to write their viewability measurement technology in JavaScript, too. Until they do, their viewability metrics will be skewed. I have seen this issue firsthand, too.

Why Aren’t We Talking About VPAID Wrappers?

I don’t think most people realize the magnitude of this problem, or even its existence. In our fragmented industry, few players have a bird’s-eye view.

It is a lot of work to update a VPAID wrapper. Flash-based wrappers are easier because the browser has a Flash plug-in, so you don’t have to provide that code. With a JavaScript VPAID wrapper, you have to do all the work – there is no pre-existing JavaScript plug-in on the page. But it can and must be done.

In The Meantime

Assuming they have updated their video player versions, there’s not much that publishers or advertisers can do while they wait for the industry to catch up. I suggest they audit their partners and start asking questions. If we can raise awareness about the issue, companies will be forced to make the necessary changes.

In my experience, the VPAID wrapper issue is responsible for at least half of publishers’ unmonetized inventory. Unfortunately, publishers often don’t have a voice in ad tech. Some publishers may circumvent this issue if they only sell media directly to advertisers, but to best serve the vast majority of publishers who rely on external solutions, the guys in the middle need to make some changes.

Again, it doesn’t matter if the brand or agency did everything right. If they buy from a trading desk that then buys from an ad network that ultimately purchases the publisher’s inventory, and there is a Flash VPAID wrapper somewhere in that chain, both the publisher and the advertiser suffer.

We read about advertisers’ viewability struggles every day, and understandably so. It’s a real and poignant problem. But here is one tangible step we can take to help correct the issue, while also addressing the needs of publishers. The absence of JavaScript VPAID wrappers is leading to poor user experiences and a loss in value for advertisers.

Ad servers, I implore you: Update your VPAID wrappers immediately.

Follow Ted Dhanik (@teddhanik), engage:BDR (@engageBDR) 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. Clever insight, very happy to see a post on this topic here!
    This Flash legacy is indeed a major issue for the video programmatic market. Publishers & networks should indeed audit their partners and vendors and ensure full compatibility with html5. Considering the amount of video views are done on mobile it’s especially critical. Keep in mind that VPAID2.0 (including non-flash environment guidelines) was defined in 2012 (!!!). I can’t understand why most of the major vendors (including video players & buy side solutions…) still didn’t implement it.
    This being said I think another related topic is the extensive usage of VPAID ad manager in the programmatic video space. What has been called programmatic video until recently was a basic client side daisy chain of VPAID wrappers. A large part of the video traffic is still traded that way – eg the Liverail way – and it’s bad (high latency, low control for publisher, fraud friendly, etc.).
    We must push for more truly programmatic (server side) implementation, it would solve this VPAID problem right away!

  2. I am happy to agree that more/faster JavaScript VPAID aka HTML5 VPAID aka VPAID 2.0 is desirable. There are a number of inaccuracies in this article though, unfortunately, the worst (from my perspective) being that the delay in adoption is caused by ad servers needing to make an update. We and other ad servers have been HTML5 VPAID compliant for a long time – publisher players need to be updated to support the format. The inventory incompatibility is not on the ad server side. Additionally, the choice for publishers is laid out in this article as being Flash or HTML, which is also misleading. Most of them choose to support VAST, which is just a video and tracking pixels and can be supported by either technology. They can potentially do that indefinitely, without supporting VPAID at all. Worth noting as well that Chrome has not yet blocked Flash for many video players – it’s actually called out in their original notice as an example of content “central to the website” that would not be blocked. Certainly Google will block it, but they are aware that the pubs need time to transition their players. Browsers don’t support a JavaScript plugin because they all support JavaScript natively, one step better than a plugin – code needs to be written in either case. VPAID is a defined standard – there is absolutely something publishers can do – they can update their player to support it. Advertisers can pick an ad server that supports HTML5 VPAID if they want to force the issue, and they can select publishers on their media plan that support it. There are some advantages to supporting HTML5/Javascript VPAID (for my own company as well as, I suspect, for the author’s company), but I think there’s a bit too much fearmongering here and the finger is pointed in the wrong direction, since many/most ad servers are already compatible. The first commenter is right that VPAID has been hijacked for arbitration purposes in some cases, and in addition to that, HTML VPAID support does not automatically equal mobile support and does not automatically equal viewability/verification support on mobile. So there are forces against VPAID as well as with it as far as publishers are concerned. Fortunately the IAB and many companies (including publishers) are working to close the gaps in the existing standards and improve the ecosystem.

  3. Milena Markova

    There is a lot of “flash inertia” on both publishers and agencies sides. While major video player vendors are able to keep up with transition to HTML5, large publishers utilizing custom players are still struggling to make the move away from Flash. On agencies’ side, Flash technology is so deeply entrenched into the previously established models of video ad campaigns execution, that despite availability of HTML5 ad serving and verification technologies, Flash remains the dominant format for video ad creatives. I disagree with the author’s assessment for lack of available HTML5 VPAID wrappers, considering that provider of such 3rd-party technology solutions are usually the first to react and adjust to video technology changes. As an ad delivery intermediary, no VPAID wrapper provider is in a position to lose business by breaking ad delivery and failing clients due to technological complacency.