Browsers Are Cracking down on Web Push Notifications, so What Is the Optimal Push Strategy for 2020?

Back in 2013, Google introduced web push notifications to browsers for the first time. Other browsers scrambled to do the same after seeing the popularity and potential, and a whole new marketing channel was created. 

4% of the 100,000 biggest websites and 8% of the biggest 10,000 sites now use web push notifications. This has doubled in the last 18 months for a reason – they work really well. 

2013 was a long time ago though, and the world has changed. Privacy and not annoying users are far more important in 2020. 

So it’s not a huge surprise that Google recently announced that Chrome version 80 will begin to block web push notifications. 

Google Notification Changes

Google acknowledges the value of web notifications:

“Notifications on the web enable users to receive important updates even when they are not interacting with a website. Notifications are an essential capability for a wide range of applications including messaging, calendars, email clients, ride sharing, social media and delivery services”

However, they also note that some sites use them in the wrong way, which has a negative effect on user experience.

“Unfortunately, notifications are also a common complaint as many websites request the notification permission on first visit rather than at contextually relevant moments in the user’s journey. Unsolicited permission requests interrupt the user’s workflow and result in a bad user experience”

So what are they planning to do about it?

Chrome’s Quiet UI

Chrome 80 will show, under certain conditions, a new “quieter notification permission UI” that seeks to reduce the interruption of notification permission requests for users.

The quieter UI will do away with the block/allow pop-up at the right of the Omnibox. Instead, a “notifications blocked” text will slide out briefly like so:

It’s a similar story on mobile too, with a subtle bar sliding up briefly from the bottom of the screen.

Will all Chrome users see the Quiet UI?

No, there are two circumstances in which they will.

Manual opt-in

In Chrome 80, users will be able to opt-in (or opt-out) manually through settings.

This will be explained to users on first launch, so it’s likely that a significant percentage of them will opt-in.

But user choice is only half of the story.

Automatic enrolment

Chrome will automatically enrol users in the quieter UI in two circumstances:

  1. Users who habitually and repeatedly deny notifications across different sites will be automatically enrolled in the quieter notifications UI
  2. Sites with very low acceptance rates will be automatically enrolled in quieter prompts, and visitors landing on the sites will see the quieter notifications UI

The first one is not surprising. If certain visitors would never allow notifications anyway there’s no point in asking them – doing so is likely to just irritate them.

The second point is interesting, the latest step in Google’s efforts to punish sites with poor user experience. 

Sites who get ‘blacklisted’ in this way will be unenrolled when the UX improves, for example, if the developer improves the notification permission flow to boost acceptance rates. 

Google also has plans to punish “abusive” websites that use push notifications for ads, malware or deceptive purposes. 

Are other browsers blocking push notifications?

Yes, Google isn’t the only one.

Firefox announced on January 7 that users will be able to block “pesky” notification prompts automatically.

Firefox discovered during testing that around 99% of notification prompts on their platform go unaccepted, and 48% are actively denied by the user. 

The old larger pop-up window has been replaced by a wiggly speech bubble that will briefly let the user know that the browser has blocked a notification message.

Firefox will show the quiet permission prompt whenever a website sends a notification permission message to visitors who have not undertaken any initial action on the page (like clicking a button).

This is similar to how Apple does it.

Safari 12.1 requires some initial user interaction before a notification permission prompt can be shown. 

On top of all this, don’t forget that many other browsers are built on top of Chromium. The open-source browser engine is the foundation of Chrome, but the changes are also very likely to affect browsers like Brave, Edge, Opera, Samsung Browser and others.

Why are browsers doing this?

The bottom line is that the browsers will do what is good for the browsers.

This primarily means driving up usage as much as they can, and offering a great user experience is the best way for them to do this.

They’ve realized that push notifications are less of a help than a hindrance in this, and so something needs to be done about them.

What should publishers do about push notification blocking?

In recent years many publishers have gone all-in on web push notifications.

It’s not surprising, they’re an effective way to increase traffic, revenue and engagement.

The recent moves by browsers are concerning though, especially if you get a poor acceptance rate on your notifications right now.

What can you do? There are two smart moves to make.

The first is to do everything you can to prevent push notification blocking and get users to accept your notifications.

The second is to diversify your push channels. This could just be the first move from the browsers, the long game might be to kill off the web notification ecosystem further.

How to prevent your push notifications from being blocked

Google recommends that publishers test their site’s permission request flow with the quieter notification permission UI.

You can enable it manually in chrome://settings/content/notifications, and it’s been rolled out in Canary, Dev and Beta.

This will allow you to see how Chrome 80 will interact with your site when it fully rolls out.

They also recommend following best practices when it comes to actually requesting the notification permission from visitors.

“Websites that ask users to sign up for web notifications when they first arrive often have very low accept rates. Instead, we recommend that websites wait until users understand the context and see benefit in receiving notifications before prompting for the permission”

Here’s a very handy 5 minute video from Google about making fluent permission requests.

Of course, it makes sense to show users the benefits of giving permission instead of bombarding them straight away.

Let’s look at some other web push notification best practices.

Adopt a two-step prompting flow

According to George Deglin, CEO of OneSignal:

“We recommend that websites always use a two-step prompting mechanism. That way, users will choose whether they want to allow or deny notifications on the two-step prompt prior to seeing the native prompt. When users do see the native prompt, they’ll be much more likely to click yes. That way, there’ll be no impact to the user experience of your website since the frequency of users clicking will be very low”

He sees the changes as generally positive, and confirmed the need to give appropriate context to visitors before showing the prompt.

“Overall, we actually see these as really, really positive. I think web push notifications have generally gotten a bad perception from a lot of users because they can be annoying when you visit a website and you’re prompted right away about whether you want to allow notifications or not before you really got a chance to understand whether the website is interesting or not”

It’s also a great idea to ‘pre-prompt’ visitors.

“Tell them why you want them to grant permission before you ask for it. This applies in particular to web push…….. The more specific you can be and the more convincing you can be, the higher your opt-in rate will be. That’s a much better practice by simply showing them the prompt without context”

Your notifications should not just be a tool you use in your marketing. To be truly effective, they need to provide real value to readers.

Find a way to communicate exactly what that value is. What do they get out of it, and why should they allow your notifications? Make a solid case and your opt in rates will be much better.

It’s also a good idea to time notification prompts for when a user is more likely to be engaged, for example when they spend a certain amount of time in an article, like something or register for an account.

Content Blocking?

There is also the possibility that content blocking will emerge as a way to get more users to consent to notifications.

The same thing happened with the rise of ad-blockers, publishers would block off all or part of the content to visitors unless they disabled their ad-blocker.

This could well emerge through 2020 for notification permissions too. Is it a good idea though?

Probably not. It will negatively affect the user experience, and might lead to higher bounce rates and less engagement. Also, if you need to ‘blackmail’ visitors to allow your notifications, are they that valuable from a business standpoint to begin with?

If content blocking is something you want to experiment with, only you know if it makes sense for your business.

Is there a more reliable push channel for publishers?

The publishing industry is moving toward a new paradigm in which the reader and your relationship with them are at the centre of everything.

Your success will depend on whether you can create a loyal audience and keep them around to support your work.

Channels that let you directly reach your audience are valuable.

Web notifications work well, there’s no doubt about that.

The question is – how long will they be around for? Is this just the first move that the browsers will make to curtail them?

There’s another way you can reach your audience with push notifications – native apps.

Apps let you send out rich push notifications to everyone who has it installed on their device (i.e your most loyal audience members). They are far more likely to receive the messages well and be interested in them too, after all they did download the app!

An app is an owned channel. There is less chance of tech platforms interfering with how you send push notifications to your users.

All publishers should be considering native apps in 2020 – if they don’t have them already. They provide a home for your most dedicated and loyal audience members, make your brand look truly up-to-date and professional, and open up numerous revenue and engagement avenues.

Isn’t building an app hard, expensive and time consuming?

It certainly used to be. But technology has moved on. Now you can have native apps as good as the New York Times of Buzzfeed – in just a few weeks and at a fraction of the traditional cost, all without having to touch a line of code yourself.

If you want to succeed on mobile and develop a winning app store strategy, get in touch with one of our app experts today and lets start making it happen.

 

 


App strategy handbook cover Want to learn all about building and launching mobile apps for your WordPress site? If you liked this article, you’ll love the Mobile App Strategy Handbook. Click here to download it for free.

Written by
Thomas Goss

I'm MobiLoud's marketing manager.

I write about media trends and business models - and host the Digital Media Growth Podcast, where I interview fascinating people from the world of digital publishing.

When I have time I like reading, skiing, fitness, cooking and learning languages.

View all articles
Leave a reply

− 1 = 6

This site uses Akismet to reduce spam. Learn how your comment data is processed.

MobiLoud Blog