As desktop browsers place restrictions on autoplay, publishers have more reason than ever to embrace click-to-play advertising
With changes in the industry over the last year and a half around supporting autoplay for mobile (when muted) and the more recent newsworthy restrictions implemented by Safari 11 and soon Chrome 66, there are some clear pieces of information and actions necessary for anyone in the digital video world.
Click-to-play is king
As we’ve said many times before, click-to-play is the future of the online video world. Not only does it help with monetization, but web browsers are making autoplay harder as a way to improve the user experience of viewers across the web. Embracing click-to-play is the clear path forward.
Desktop, meet Mobile
Mobile devices only allow autoplay when the content or ad is muted. Desktop is now joining the party in an effort to improve user experience and save bandwidth for viewers. Fortunately, this unifies the behaviors, simplifying things and making it easier to remember what the behavior will be.
Safari 11 desktop
Safari 11 brought autoplay restrictions with it.
The new default (which is configurable by the viewer) is to only allow autoplay if the content or ad is muted. This is set on a page by page basis, and viewers can choose to always allow autoplay, or never allow autoplay for that page.
Chrome 66* desktop
Chrome will implement similar restrictions as Safari that you can read more about here.
* While the Chrome version number and date have been shuffled around a bit, the current timeline from Google puts these changes around mid-April 2018.
Safari 11 came with a fair amount of buzz even with it only being 5% of traffic; surely Chrome’s 45% is nothing to ignore.
Why do desktop autoplay restrictions matter?
When desktop browsers restrict autoplay, ads will start immediately and then get paused, requiring users to click on them to continue OR the ad will error out and then require the user to click to start the content:
This change is a departure from autoplay ads, which allow ad requests and ad impressions to happen automatically, eating up bandwidth and inflating numbers for what may not be a real, watched ad. More importantly, user experience is poor.
While autoplay ads pump up impressions, they often aren’t the most effective. A click-to-play ad (in an autoplay-restricted browser) supports intent to watch and, in the long run, reaches audiences much better.
So long story short: These desktop autoplay restrictions might seem daunting. But they’re actually a significant step toward creating online videos that place user experience first and make ads more successful.
How will JW Player handle the change?
Given how poor the user experience is in autoplay, the player needs to detect the browser setting and react accordingly, prior to starting playback. To do this, the player will have to test to see which scenario is allowed:
- If the publisher wants to autoplay, and we detect we can autoplay, we will
- If we detect we can’t autoplay, but can autoplay muted, we’ll check to see whether the publisher has confirmed they want to run ads muted, and we’ll mute the player to let it run
- If we can’t autoplay at all, the player will disregard the autoplay setting and remain in a click-to-play state
There are some pretty serious advertising implications, not the least of which is that advertisers may not be keen to have their ads run muted, and that plays and impressions will likely drop for many sites. But as mentioned above, the quality of those impressions will likely be improved with click-to-play.
Aside from the functionality above, Google has a requirement that entails passing autoplay and mute settings along with ad requests so that advertisers have more transparency around what the player functionality will be when their ad would run. This allows advertisers to decide whether they want to run ads on autoplay players, muted players, etc.
So what do I need to do?
JW Player will be releasing a new version of the player that fixes the user experience and passes the appropriate information to Google. If you’re on the latest version of JW8, you’ll get the update.
If you’re not on the latest version of the player, you’ll need to update. This isn’t a bad thing as you’ll get loads of new functionality and better performance as you can see in some of our other posts, like this one about the benefits of JW8.
JW Player Version 8.2 will available on Wednesday, March 21, 2018. You can get on the latest version by following the steps below.
For Cloud Hosted Players:
- Log on to your JW Player account
- Navigate to “Players“
- Click “Create new player” or update the existing one by clicking “Update“
For Self Hosted Players:
- Log on to your JW Player account
- Click “Downloads” on the top right portion of the dashboard
- Navigate to “JW Player 8 (Self-Hosted)” and select the latest “Version” from the drop down menu
- Click download
What happens if I don’t do anything?
If you’re not on the latest version of the player, a few key things will happen as the browser changes proliferate:
- The user experience on your pages will remain poor, driving viewers away
- Advertisers may opt out of bidding on your ad inventory, resulting in a lower fill rate, or bid less, resulting in a lower CPM
- You may simply get ad errors rather than impressions
Much like the Flashpocalypse, this is an unavoidable industry movement for the better. With such advance notice, the Flashpocalypse passed quietly into the night and is now a distant memory. Take this opportunity to get on the latest and greatest version of JW Player and ensure you get out in front of these important upcoming changes.
You can read more about autostarting and some of these issues in more detail in our support article.
Also, don’t forget to register now for our upcoming webinar on Thursday, February 22, to learn more about what these browser autoplay changes mean for your video advertising.
Ready to become a video-first publisher? Schedule time to talk with one of our video experts.