A few months back, I wrote a blog entry about RhythmOne’s approach to VPAID and why we made a business decision to offer multiple variations on our VPAID tags. However, a larger ongoing industry conversation continues to be had surrounding VPAID and the many obstacles it still faces in its path to standardization. I wanted to elaborate on RhythmOne’s handling and approach to these issues.
O Flash, Where Art Thou?
Many advertisers and creative management platforms (CMPs) are still producing VPAID tags using Flash and using them in the various programmatic exchanges. The problem, of course, is that Flash doesn’t work on mobile and Flash on desktop is not far behind. A lot of exchanges block Flash-based ads by default which results in a lot of missed opportunities and revenue for publishers. This is the fundamental reason behind why RhythmOne’s proprietary CMP offers the much-preferred JS only VPAID URLs – buy can also produce Flash, and JS + Flash when needed.
The Weight on the Shoulders of VPAID
VPAID enables interaction tracking that has allowed clients unparalleled insight into what works and what doesn’t in their interactive video ad units. That insight has come at a rather significant expense however, slowing down ad load times in the process. In recent years, video ads have become heavier and combating this added weight – and the latency it can cause – has become a big focus for RhythmOne. We’re actively participating in IAB’s new LEAN ad specifications process and have been taking a page from their book when balancing what we need for effective tracking vs. load times. Too much tracking can be bad, but too little provides an incomplete picture of campaign performance. Understanding your clients’ needs and knowing what the important metrics to track vs. superfluous event tracking is essential when identifying this balance (carousel direction swipes per domain, anyone?).
In-APP VPAID: WebView vs. Native Support
The main argument in this arena is that Native Support offers faster (lower latency) ad load times, while WebView offers any new VPAID related features and bug fixes to be released to production without publishers having to update the SDK software itself. RhythmOne currently uses WebView to support VPAID in our SDK, a practice which will most likely continue until we see more consolidation around a single VPAID spec (IAB or otherwise). While the latency times we see in-app for VPAID could be lower with a switch to Native Support, in the interim we have taken several steps to help mitigate any increases:
- Adblocker/Proxy Bypass – If the device has an adblocker/proxy, our SDK will bypass it and show the ad.
- Video Caching – Pre-buffering ad content reduces delays.
- Creative Validator – Protects against creative ad units that are not correctly coded or corrupted, breaking/crashing the app.
- Blacklisted Creative IDs – Our validator feeds into this Blacklist, so we won’t attempt to deliver failed creatives again in the future.
Pick a Format!
While VPAID does have general XML formatting standards, there are still a lot of formatting alternatives out there floating around. Therefore, it is important for the IAB to engage in a continuing open conversation with companies from all over the industry and refine the VPAID standard so that it works for everyone. This is the foundational reason RhythmOne works closely with the IAB and supports the VPAID specifications – to encourage more and more platforms and publishers to adopt the standards. Other formats like MRAID are a bit more in its infancy stages in terms of specifications, but in time we expect to standardize around IAB MRAID specifications as well.
In the face of all the efforts to overcome the above challenges, we still have our work cut out for us. Educating the masses, as I mentioned above, is probably the most important and effective path for progressing and having a solidified VPAID standard for our industry to build from. As long our industry keeps pushing responsible advancement forward, adoption is inevitable.