Chrome Dumps Flash; Here's What Video Advertisers Need to Know

One of the noisiest news stories of the past few weeks has related to Google Chrome and Adobe Flash. There's been a lot of incorrect or incomplete reporting on this topic, and if you skim the headlines, you'd think that Chrome blocked all Flash ads all the time, which isn't correct. In this article, I'll explain what Google did and didn't do, how this will impact advertising numbers, what online video marketers can do to keep the revenue stream coming, and how this change will impact the typical Chrome user.

What's Changed in Chrome

It all started with a simple blog post back in March, where Google added the control shown in Figure 1 to the Chrome Settings screen (Preferences > Show Advanced Settings > Content Settings > Plugins). When the setting was originally created, the default was Run all plugin content. On September 1, Detect and run important plugin content become the default. Here's what it all means.

The aforementioned blog post reads. "With today's Beta release of Chrome 42, we've launched a new setting that automatically pauses plugin content that's peripheral to the main page. This can help you save precious battery power and CPU cycles. But don't worry, the primary plugin content on pages (games, videos, etc.) should still run just fine." Emphasis was supplied.

The key point from the post is that only the peripheral content is paused, not the main content. According to a blog post on the JW Player site, so long as the video window is larger than 400x300, it won't be paused. So if you're currently publishing in-stream Flash ads in a video player larger than 400x300, the Chrome announcement means absolutely nothing, though as I'll discuss below, there are several compelling reasons to start moving towards HTML5-based ads.

If your Flash advertisements are playing in a smaller window elsewhere in the page, Chrome will pause them, and display the play icon shown in Figure 2, a screenshot from www.fivethirtyeight.com, an ESPN sister site. While the viewer can certainly play the ad, it's unlikely that they will, which means the advertisement doesn't get viewed, and the publisher doesn't get paid.

Again, if the ad is larger than 400 x 300, it won't get paused, even if it's clearly peripheral to the page. You can see this in the 640x360 Boeing ad I grabbed from the Computerworld site just after grabbing Figure 2. As the article was about Mozilla blocking Flash after their zero-day security problem, the ad was as peripheral as you can get.

To be clear, Chrome doesn't pause all peripheral ads, just Flash ads, so ads created in HTML5 will play, which is both part of the solution and part of the problem. Once all advertisers convert their Flash-based ads to HTML5, the pages will look almost exactly like they do now. In fact, ad load times might even be longer, because many HTML5 ads are larger than their Flash counterparts. So if you object to the advertisements themselves, rather than the fact that they're served in Flash, you'll see little difference.

Another key point is the difference between pausing and blocking. Chrome is pausing ads, so the viewer can play them if desired, however unlikely. Ad blockers block the ad and remove it from the page completely. It's a minor distinction, but one worth remembering.

Sizing the Problem for Advertisers

According to ad management firm Sizmek, assuming that all advertisers continued with Flash advertisements, at least 12.1 billion ads would be paused by the new feature in Chrome in the fourth quarter of 2015 alone. That's a lot of impressions and a lot of revenue. Of course, this will never happen for a variety of reasons.

First, ad networks are working aggressively to minimize the loss. After all, if an advertisement doesn't appear, they don't get paid either. In the case of Yahoo's network, clients can target their creatives by browser, for example, targeting Flash ads to Firefox and Internet Explorer, and not Chrome. Google AdWords goes one step further, and automatically converts many Flash ads to HTML5. Or, you can start to create your own HTML5 ads with a variety of tools, including Adobe Edge, Google Swiffy, or Sizmek's Ad Builder for HTML5.

What's Slowing HTML5 Adoption?

Replacing Flash ads with HTML5 comes at a cost, however, and that's a key reason the transition from Flash to HTML5 has taken so long. Specifically, Flash ads are compatible with VPAID 1.0, an IAB (Interactive Advertising Bureau) spec that enables both interactivity and enhanced tracking of viewing details like where the ad was placed within the page and other viewability metrics that help advertisers measure the performance of their campaigns. HTML5 ads are not compatible with VPAID 1.0, so they can't capture this information.

An updated spec, VPAID 2.0, is in the works, but not yet widely implemented by advertising networks or HTML5 players, although many service providers are moving in that direction. For example, JW Player has committed to incorporating VPAID 2.0 compatibility into its namesake player by the end of the third quarter of 2015. The new spec has the added advantage of working with mobile devices, which is one of the most important benefits of switching over to HTML5-based ads: one creative that runs on all platforms.

However, another key factor slowing HTML5's uptake with instream ads is that key components such as digital rights management (DRM) are not yet in place. That's the primary reason most major networks still use Flash. According to Sorosh Tavakoli, senior vice president of Adtech for Ooyala, "We'll steer clients that don't monetize their videos or need DRM towards our HTML5 player, but recommend Flash for clients who need either feature. At least for instream advertisements, HTML5 is the future, but is at least 6 to 12 months away."

Scott Cunningham, senior vice president of technology and ad operations at IAB and general manager of the IAB Tech Lab, shared that the IAB has been strongly pushing its members towards HTML5 over the last few months and will continue to do so, though the transition has been slow. "Markets remain in status quo until external events like the Chrome decision force the ecosystem to adjust. Though the transition to HTML5 and VPAID 2 will require major changes throughout, I have a hunch it will move pretty quickly," he said.

If the market is looking for additional motivation to change, it won't have to look far. Also on September 1, Amazon stopped accepting Adobe Flash SWF-based display advertisements for Amazon.com. Combined with highly publicized security breaches that caused Mozilla to block Flash operation on the Mozilla browser in July, Flash is disproving the notion that any PR is good PR.

Let's summarize: If you're an advertiser using instream Flash ads, Google's announcement has no effect unless your video window is smaller than 400x300, but you should be watching VPAID 2.0 and converting to HTML5 as soon as possible to produce a single asset that runs on computers and mobile devices. If you're an advertiser running other video ads, the simplest solution is to make them larger than 400x300. Otherwise, you can target your VPAID 1.0 compatible Flash ads towards Firefox and Internet Explorer, and create HTML5 creative for Chrome and mobile. If you're part of the advertising ecosystem, you're probably already working towards HTML5 and VPAID 2.0 compatibility.

If you're a Chrome user hoping all video ads will go away, Google's move may provide temporary relief, but that's about it. If you're counting the days until Flash becomes truly unnecessary, we're one day closer, but the end is at least 12 months way, and probably much, much longer.

Authors note: The author would like to thank the folks at Ooyala and JW Player for investing the time and energy to help me understand the intricacies of the issues discussed (it's not just Flash SUX!). All insights are likely theirs, any errors mine.

Jan Ozer's article first appeared on OnlineVideo.net