We’re two months past Sept. 1, the date when Google Chrome started detecting and pausing any Flash content it deemed “unimportant” to a page’s main content — in other words, Flash ads. Mozilla’s own Flash-blocking practices preceded Chrome’s, in practice.
And yet, not only has the internet not broken itself, but creatives are still building ads with Flash. So what happened? Why aren’t agencies and publishers getting the message that Flash is dead?
Browser and device compatibility be damned, a whole lot of creative people are still building with Flash because it’s what they know. Flash has been around for a lot longer, there are more toolkits and tutorials out there for Flash than there are for HTML5, and some creatives simply prefer Flash’s animation functionality. And of course there’s the issue of file size, and pushback from creative agencies about building in significantly weightier HTML5 formats. Publishers are seeing a continuous stream of Flash creative coming through the door, and they need quick solutions for dealing with that creative while, without universal browser support, it’s basically dead in the water.
In order to implement those quick solutions, publishers need a firmer grasp of HTML5. It’s very different from Flash, not just in its capabilities, but in its features and deployment. Publishers have a learning curve in familiarizing themselves in the ins and outs of the technology, but also in developing best practices and specifications for working with HTML5 tools. For smart, forward-thinking publishers, this is the time to get on the ball, regardless of what’s coming through the door.
Becoming familiar with HTML5 can help publishers boost their own creative output: For publishers, the ability to provide creative services in an HTML5-forward world would be a great opportunity, a way to level up against creative agencies that have been afraid of change and what comes with it.
So Converting Flash Files Is a Publisher Problem Now?
Right now, though, publishers have more urgent problems to attend to — everything that surfaces with these outmoded Flash campaigns and browsers that resist them, like page latency, reduced viewability and discrepancies between parties. When ops get down to the day-to-day concerns of file hosting and DFP integration, we can really see just how much of a mess pubs have to clean up when Flash comes into the house, and how much time and effort they stand to lose. Publishers do have a few band-aids in the cabinet, though, which they can slap on right now as temporary fixes.
Most obviously, pubs could institute an all-out ban on Flash. Problem is, as we just explained, advertisers are hooked on this stuff. To paraphrase Amy Winehouse, pubs tried to send advertisers back to rehab, and they said “No, no, no.” Publishers report getting pushback from advertisers by demanding HTML5, with advertisers fretting over the file sizes in creative specs, asking how low pubs would be willing to go. Flash is still advertisers’ fix of choice, and pubs need to somehow make do with what they’re getting, until advertisers trust an HTML5 campaign will swim when they throw it into the water.
Advertiser clients are asking publishers to convert creative files from Flash to HTML5 as it is, and there’s a lot of discussion among publisher ad ops about the best ways to convert the files quickly on their own to traffic in DSP, or where to outsource the work. Some have reported they’ve called in a vendor that specializes in rich media. Others have just taken up Swiffy, which Google has made available to publishers as a free Flash-to-HTML5 conversion tool.
Google’s instructions on Swiffy are pretty straightforward — the publisher uploads the creative as an SWF file, and Swiffy sends it back as an HTML file via a download link. But Swiffy is more of a compromise than a solution, obviously, and publishers have been eager to work with it, if wary of what it means for increased workflow. One publisher source pointed out that the massive file Swiffy gives you has images embedded, which means you get a huge mess of code in the package, but that it’s better than the alternative.
Some publisher sources had difficulty with image hosting and have resorted to manual workarounds, whether that meant hosting images on their own servers and editing reference links, or having difficulty in uploading images from the bundle when building off a template rather than developing custom creative. But publishers have said Swiffy is a workable quick fix for this, because the HTML it generates points to an external library script hooked up to Google’s server. That publisher also suggested DFP users might load and host images via DFP Studio, in turn linked to their DFP account; or using Google’s free Web Designer to simplify HTML5 packages.
It’s also worthwhile to consider a possible “Flash replacement” — a stand-alone creative tool that outputs a single vendor-agnostic file, much like a .swf. If and when demand continues, it seems likely vendors will be competing with platforms like Google to provide the industry’s tool of choice.
There are pros and cons to this proposition. On the one hand, you’d have potentially universal acceptance, and you could avoid serving fees. On the other hand, there’s already more complexity in this realm than ever. Dynamic, personalized creative and libraries trying to accommodate those cases take up a particularly crowded niche, and bundling these tools as plugins could result in just the same security issues that plagued Flash. If a Flash replacement emerges, it would be recommended to partner with supported platforms specifically addressing advertising requirements.
So, HTML5: Where Are We Going With This?
To some folks, this transition away from Flash and toward HTML5 might seem kind of analogous to the transition in the ’90s from unique, site-specific rich media and working with rich media agencies. There’s workflow disruption, a call to master new tools, a great re-shuffling of hosted assets. But as with the transition from early rich media and toward Flash, we’re looking at a broad move toward something more suitable to the broader public’s media habits.
On Sept. 25, the IAB announced an updated set of HTML5 specs. In particular, it changed specs around the Universal Ad Package and Rising Stars for HTML5, including specs for file weights and packaging for optimal load performance. Other updates aim to offer some guidance on shared libraries, browser compatibility and developer tools.
Regardless, some publishers opt to go with their own specs. The IAB’s new specs for maximum file weight are 80K for a 180×150 unit, 200K for other units — compare that to the oddly small 40K limit many programmatic platforms impose. HTML5 files have a lot of stuff contained within. So there’s a line to toe: You want the responsiveness, but you don’t want the file bloat. Oversized files can lead to latency. Latency can diminish viewability. Reduced viewability reduces ad revenue for the publisher.
That said, there’s a granularity afforded to HTML5, specifically, the ease with which individual creative components can be responsive or user-targeted. HTML5 makes that granularity possible, because it makes each element more accessible. That opens the door for each element in the ad to be called out programmatically, building ads at the moment they run, based on conditions agreed upon beforehand.
Creative Opportunities for Publishers
There is in all of this an opportunity for publishers to take the lead in offering their own creative services. If creative agencies don’t want to comply with HTML5 requirements, well, publishers can develop in-house teams to become HTML5 creative specialists and allow their advertiser clients to effectively cut out the middleman. If publishers have a clear idea of how their ad creative loads optimally, they can get to work making creative that performs under these conditions they know so well.
For publishers that don’t have the bandwidth to develop full-blown in-house creative studios, they can hold onto the parts of the workflow they’re comfortable with and turn the rest over to a nimble partner. According to AdMonsters’ most recent State of Ad Ops survey, 54% of publishers say that less than 25% of the creative advertiser are sending them is HTML. And 59% of publishers say they’ll change their specs to say “no Flash.” The HTML5 creative is going to have to come from somewhere, and if the stakes to run it are highest for publishers, maybe publishers should take matters into their own hands. Publishers already find themselves in a position of advising advertisers about the importance of running fresh, engaging creative — why not close that loop, if they have the resources?
Resources are an issue, though. That includes storage. HTML5 files are large. If a publisher is going to become a creative studio too, it needs to assure its server can handle that new role.
We want the transition from Flash to HTML5 to be simple, but unfortunately, it hasn’t been. This is a murky time, straddling two eras. But one thing to be sure of is that Flash doesn’t have a future, except as a museum piece. Imagine that—someday, your kids will ask, “What was this Flash I read about, and what was it like?” And you’ll be able to say, “It was fine in its time, but it just didn’t have a place in a digital environment that demanded more interactivity and responsiveness.” Or don’t say that; you can raise your kids however you want. That’s the difference between your kids and your publisher business, which needs to break the chains binding it to converters and other band-aid solutions. Publishers and service provider partners need to take the lead and develop the creative offerings that will deliver the best site performance, audience response and revenue, growing their business and positioning themselves as creative leaders.
var s = document.createElement(‘script’);
s.async = true;
var host = (document.location.protocol == ‘http:’) ?
‘cdn.snapapp.com’ : ‘scdn.snapapp.com’;
s.src = ‘//’ + host + ‘/widget/widget.js’;
s.id = ‘eeload’;