Flash has been around for what feels like forever. In some ways the Flash creative standard has been simple, but ensuring clicktag compatibility between platforms was not so straightforward.
Everyone seems excited about letting go of the old Flash legacy. Even Adobe, its owner, seems ready to not have to support Flash anymore (article)
The main issue
Some major publishers, like Amazon (article) and LinkedIn, had already announced that they would stop accepting Flash creative this month.
Others will probably just convert Flash creative to HTML5 on the go, even though doing so leads to heavier ads, badly impacting the web page load, as you may have noticed recently on a few major mobile publications.
The big issue: Ad platforms need a solution that enables them to measure the clicks on the creative they deliver, and thus to communicate with that creative (as we did in the past, with the clicktag parameter in the Flash creatives). And because many ad platforms maybe be involved in the delivery of an ad, everyone involved needs to measure clicks, and to share a common standard.
After Firefox and Chrome announced that they would block Flash over security concerns, the U.S. Interactive Advertising Bureau brought out a standard in August. This new standard is necessary and great — but it doesn’t fully solve the issue. Each vendor will need to interpret it for themselves.
Our own interpretation is that each creative needs to integrate a library that will sense creative behavior, detect click URLs, and track accordingly. The extensive, essential usage of iFrame by ad tech vendors makes it necessary to include these libraries in the creative, rather than relying on the code delivered by the different vendor tags and this code often can not interact with the creative through the iFrame.
What it means in practice: The creative will need to include as many libraries as there are platforms involved in the delivery of the ad.
That idea frightens those who are aware of the number of intermediaries that can be involved in the delivery of an ad.
HTML5 advertising, our best practices
Having supported mobile ad serving for a lot of big-brand publishers during the past few years, we’ve experienced the rise of HTML5 ads, built some tools for them and gathered a few best practices for creative development:
– Don’t use automated flash=>HTML5 conversion, because that process generates over-complicated and unoptimized code that may strongly impact the user experience on the page
– Use compressed PNG or GIF images, rather than JPG, in order to significantly reduce creative weight and, thus, latencies
– Avoid parallel http requests by optimizing your CSS implementation, using coordinates or merging all image files into one.
– Embed your JS library in the creative file
As always in web development, the goal is to keep your code clean and optimized, and that’s especially important for a proper advertising experience. You may find more about this in one of our (rather old) blog post.
Also note that the impact of Flash’s demise will be felt especially in the video advertising ecosystem, where, despite many previous notices, many vendors and publishers continue to rely on Flash.
The IAB provided some recommendations here, too, but it’s difficult to imagine everyone giving up so fast on VPAID and other broadly adopted Flash implementations. We are nearly ready on our end, but some in the industry are sure to be surprised. It may explain why Flash support has apparently been extended for a while.
In the world of advertising as well as that of content, may forewarned be forearmed.
