Notifications on the web help users receive important updates for a wide range of applications including messaging, calendars, email clients, ride sharing, social media and delivery services. Unfortunately, notifications are also used for abusive purposes. Browser notifications can be used to spam, mislead, show ads, phish or promote malware.
Google made major changes in Chrome to reduce abuse of notifications and create a safer, better web browsing experience for Chrome users.
- Quieter notification permission prompts.
- How recent changes to how Chrome handles notification permission requests can make browsing for the web a little better for everyone.
- Improve your user experience
- Improve your notification accept rates
Web notifications are a channel for communicating timely and contextually relevant information to the user. Mostly, these work just like push notifications in mobile apps, except, they can also work on desktop, on Windows, Mac, as well as smartphones.
On Android, for example, web notifications appear in the notification drawer. And on desktop, they typically appear in the top-right corner of the screen. In some cases, notifications aren’t just helpful. They’re almost essential to the app’s functionality.
For example, if you had an incoming call from a communication app, like Google Duo or Chat, that’s not something you want to know about later. You need to know about it right away. Of course, not everyone uses apps that require notifications. And not all websites are putting the needs of their users first.
That means that we are seeing a lot of websites out there that are misusing notifications in ways that are annoying or could be abusive.
How users enroll in web notifications?
To receive web notifications, a user needs to accept a notification permission request. When websites prompt users out of context for a notification, such as when a user first arrives on the website, it can be a pretty annoying distraction, both from the browsing experience itself as well as from the website’s content.
Worse, some abusive websites look for ways to trick users into accepting notifications that are then used to promote malware or undesired content.
Why we have web notifications on the web platform?
Web platform is there to enable web developers to create powerful applications and web notifications are part of that toolkit. Without notification support, there would be entire types of apps that would be simply impossible to build using web technology.
So for example, messaging apps, calendars, e-commerce, food delivery notifies, taxi or ride sharing apps all depend on notifications to provide a timely tap on the shoulder to the user. And while you could imagine that some of these apps might be usable without notifications you can see that, most of the time, you’re probably going to want one.
Quiet Notification UI
Quiet Notification UI is less interruptive, but it still lets the users know that the request has been made. There’s a little bit of animation to catch the eye. But on desktop, the dialog is in the omni box, so it doesn’t actually cover any part of the web content.
On mobile, the notification prompt used to be a modal in normal UI, but, in quiet UI, it’s an easily dismissed infobar at the bottom of the screen. Quite Notification UI aims to reduce the visual priority and interruptiveness of notification requests. On desktop, what you’re seeing in this example on the left, you’ll notice the bell icon initially animates with text, indicating that notifications are blocked on the site. In mobile, the quiet UI is now an infobar.
In both of these cases, in-product help, explains to the user why notifications were blocked on the site.
How users enroll in Quiet Notification UI?
There are several ways that this can happen. First, users could just enroll themselves manually by changing their preferences in Chrome settings. Second, sites that have very low accept rates for notification permission requests will be automatically enrolled in Quiet Notifications UI.
And this is currently sites that have the lowest percentile of notification accept rates. So the absolute rate needed for Quiet Notification UI does change over time because we are using percentiles. Google also periodically increase the accept rate percentile that’s needed to preserve normal notification UI.
Google always keep a control group of users that are in normal notification permission UI so that, if a site’s accept rates improve, we can remove it from Quiet UI enforcement.
Third, there are some users who almost never accept any notification permission request. These users simply don’t want notifications. And for these users, Google adaptively enable Quiet Notification mode on their behalf in Chrome settings if they repeatedly blocked notification requests.
What should you do to make sure your website is not enrolled in Quiet Notification UI?
Well, first and foremost, if you’re prompting users to enroll notifications as soon as they arrive on your website. Please stop doing that. This is the easiest way to improve your notification accept rate.
Very few users will accept a notification from a site they’re visiting for the first time. And if you think about it, why would they? We’re all experiencing information overload. Wait until you know your user better and you can add value for your user before you prompt them.
You can and should prompt your user to accept notification when there’s a clear user benefit. And in the context of the user’s journey in your application. Websites that ask for notification permission in the context where the benefit is clear to the user have 80% accept rates or higher. That should be your goal.
Even if you do the best possible job with your notification prompt UI. It’s possible that some of your users may be in Quiet Notification UI mode.
So the first thing you want to check here is to make sure that the accept rates on your site are what you really expect them to be. Notification accept rate data is in the Chrome User Experience Report. It is a public database containing important information about real-world Chrome metrics for popular destinations on the web.
How can you make your notification request more in context?
You want to make absolutely sure that you’re asking for notification permission at a moment in the user’s journey that makes sense to them. In this example, we’re showing a notification request the first time the user receives or responds to their first chat. This is a perfect moment.
Even with Quiet Notification UI, it should be obvious to the user why they would want to accept notifications. The activity and motion in the web app, combined with the motion of the browser prompt. Should be sufficient cues for the user to enroll in notifications if they want them.
If your user doesn’t accept notifications with this in-context pattern. There is a pretty good chance that they just don’t want notifications, and you should respect that decision.