Over the past year, I have been faced with a dilemma as a Product Manager at Smaato: Should we extend our support for VPAID on the client-side? This dilemma arose from statements floating around that range from predicting the end of VPAID to highlighting its growing demand. Let me take a step back from the rumors, define the purpose of VPAID as intended by its creators from the Interactive Advertising Bureau (IAB), and then move on to explain how we at Smaato chose to resolve this dilemma.
What Is VPAID?
VPAID (Video Player Ad-Interface Definition) adds interactivity and deeper analytics about the video view events to your basic vanilla VAST (Video Ad Serving Template) video. A VPAID video for a car, for example, could include a button that allows the user to open a photo gallery with unique customizations of the car or an overlay that allows them to search for local dealerships.
You may be thinking: If VPAID brings interactivity and measurement to standard videos then why the dilemma about whether or not to support it?
Let me break down the three main factors for consideration:
1. Buyers Demand VPAID Inventory
Due to a lack of standards for tracking video viewability, advertisers started using VPAID tags to track viewability and engagement. This works out as a great solution for advertisers to know if there is real value behind their investment, and as a result, there is a strong demand for VPAID supportive inventory within the market.
2. Mobile App Publishers Dislike VPAID Integrations
While VPAID is loved by buyers for its viewability verification, it is not so popular among mobile in-app publishers. Publishers’ dislike for this integration comes down to two main factors:
Firstly, an app’s SDK or video player needs to be capable of handling and rendering the VPAID ad and associated events, and not all apps have this functionality. Scenarios in which VPAID tags are delivered to incompatible inventory can lead to errors in playback or bad user experience.
Secondly, in-app environments often use tags for client-side arbitration. This means that after the tag is delivered to a publisher, the VPAID tag could end up running an auction that does not result in an ad. This not only adds to a publisher’s latency issues on the client side, but it could also lead the publisher to believe that an ad was served when there was really just the possibility of an ad — all thanks to VPAID.
3. VPAID Is Out
As the industry has acknowledged the above issues regarding VPAID, the IAB came to rescue. Firstly, the recent release of the Open Measurement Interface Definition and the OM SDK aims at replacing the VPAID’s viewability measurement aspect. Secondly, there are also ongoing efforts at the IAB labs to replace the current VPAID with a new set of interactive specs for video ads that will give publishers more control over interactive ads served on mobile. However, any new protocol requires widespread adoption; therefore, the success of the OM SDK alongside VAST 4.1 will take time, as will the launch of the new “interactive” protocol.
As for my dilemma, we at Smaato are currently running beta tests with API-integrated publishers. We want to understand what it will take to invest full-scale efforts into a spec that currently has high value for advertisers but will eventually be phased out (for the right reasons).
So, while there is definite light at the end of the tunnel, I expect that until mass adoption takes place, we will still have to understand and work with the current challenges of VPAID.