Back in June 2016 the creative services team at RhythmOne threw their hands high in celebration as they officially shipped out their last Flash Rich Media ad to a client (who probably wishes to remain anonymous). We were on our way to a new creative paradigm, no longer living in a world constrained by a limiting technology. The next front in the creative execution war for the team was, of course, video.
Now approaching a year later, what happened!?
One of the projected industry shifts in 2016 was the total and utter annihilation (slightly exaggerative here) of Flash based video players as publishers saw the light and made the shift to HTML5 based players. It hasn’t happened that quickly with a significant number of publishers and industry players unfortunately taking their time with the transition. Industry observers predict that most of these companies will switch this year – but predictions are just that so we have been operating with the perspective that we will have to deal with this transition a bit longer
As a rule of thumb, support is needed for both Flash and VPAID to support ‘all’ players, but often it hasn’t been as easy or as simple as that. Even when delivering JS/SWF wrapped VPAID URLs, there are quirks with many players and SDK integrations that make it hard to guarantee 100% uniform delivery. It is easier when you know and can account for all the players in use on a campaign, but in the ride to Programmatic it has become much harder to account for these one-off player quirks. Even throwing Programmatic aside, it can still be challenging when dealing with thousands of direct publisher relationships, who all use their preferred player.
So, what to use and where? For our clients, we generally recommend:
- Use JS VPAID if you will be using the VPAID in HTML5 only players.
- Use SWF VPAID if you will be using the VPAID in Flash only players, or the HTML5 players have a Flash fallback capabilities.
- Use JS/Flash VPAID if you are not sure what to choose, or there is a mix of player types.
The last option, while the most useful to cover a broad spectrum, is also where we usually encounter most of the one-off quirks. For example:
- Non-linear JS/SWF VPAIDs, which consist of two non-linear ads, only works appropriately as intended in the Google IMA (within our testing set). Other players we tested only attempted to load the first non-linear ad available and disregarded the secondary format. As an example, if a player is only JS compatible and the first non-linear ad is SWF, it will not play, even if the VPAID contains the JS version of the ad in the secondary position. The reverse is the same for Flash players.
- When using a SWF VPAID, certain players render non-linear ads behind the video player; therefore, not in-view. Depending on your method of delivery, it is not always easily solvable, especially when injecting content in HTML instead of through Flash.
- Full-Screen mode is generally incompatible with SWF VPAID URLs.
Of course, there are more universal obstructions we deal with on occasion as well like:
- Certain players render the contents of a VPAID ad to a single container and then copy contents to another container or iframe. This leads to complications when rendering custom fonts, due to the player only copying content but not any additional font styles that were inserted into <head>.
These aren’t usually campaign shattering quirks, but they are often enough in our experience to warrant different VPAID options being made available within our creative platform.
Eventually, the technology behind VPAID will become standardized and we will phase out the extended offering to all users of our creative platform. But alas, as things do in our industry, as the sun sets on one transition period, another will likely arise. But that’s a topic for another day.