As previously announced on the Chromium blog, Chrome 80 will include a new, quieter notification permission request system.
This new system, designed with the intent to allow for useful notifications while addressing customer complaints about excessive prompting for subscriptions, attempts to automatically reduce the visibility of the permission prompts based upon a number of performance factors. Below we’ll take a look at what the Chrome team is doing about notification requests, how it might impact your business, and how you can work within the guidelines to continue delivering real-time value to your user base.
What’s changing in Chrome 80?
When Chrome 80 ships on February 4th, 2020, a key feature being added is a new, quieter method of requesting permission to display notifications to the user. While Google understands that proper notification usage is a vital component of keeping your users informed, they are also tasked with delivering a premium user experience to people browsing the internet. The new release tries to balance these two priorities by attempting to automatically reduce noise from low-quality notification permission requests, while letting those websites with high notification subscription rates continue to present requests to users as needed.
The key element in how Chrome will determine which system to use is based on the likelihood that your request for notification permission will be granted. There are three scenarios under which a user will see the new notification request UI:
- The user explicitly enables the interface via the settings pane in Chrome. If the user has opted to see the new quiet notification request panel, then websites will be unable to override the setting.
- The average user rarely enables notifications for the website being visited. If only one user out of every 10,000 unique visits enables notifications, Google is far more likely to present that website’s requests in the quiet interface.
- The specific user viewing the website rarely enables notifications for any website. If the user has been asked several dozen times across several different sites about notifications, and has denied every request, they are more likely to see the quiet request UI.
Aside from manually enabling the quiet notification request pane, statistics on usage will be compiled using Chrome Usage Statistics from Google.
Understanding the key metrics
When evaluating how you need to modify your notification approach in response to this change, you need to have a full understanding of the reasoning behind the development of the quiet notification pane. Google generally wants to create a positive user experience that drives more users to download Chrome, and notifications play an important role in creating that positivity. Websites that immediately prompt the user for notification access once the page finishes loading tend to see very poor take rates for their notifications, for example, and the very act of requesting that access then results in a negative user experience.
In recognition of this, improving the user experience necessarily entails reducing the impact of these frivolous notification access requests. If a user is generally not inclined to accept notifications, or if your notifications tend to be ignored by most of your users, there is no benefit to showing these requests to the user in a manner that calls for immediate attention. These principles guide the automatic classification of websites into the quiet notification request UI.
Improving notification take rates
To improve the number of users that are alerted to your notification permission request, you’ll want to focus on improving the take rate of your requests. The take rate is, generally speaking, the percentage of your user base that sees your notification request and decides to grant the notification permission. The higher this rate is, the more priority your requests are given in the browser and on the user’s mobile devices. Thus, it’s important to focus on quality over quantity.
While asking users more frequently for access can provide short-term gains in subscriptions to your push notifications, the quiet notifications in Chrome 80 will ultimately identify this type of behavior and reduce the priority of those requests. If, instead, you focus on building a relationship with your users and demonstrating value before prompting them for notification access, you’ll be far more likely to both see an increase in the take rate of your notification system and in the priority with which your requests are related to your user base.
Additionally, simple user education can go a long way towards improving the visibility of your notification requests. By informing users of this new setting, you can keep the importance of your notifications at the forefront of your users’ minds. For those users who value the notifications your website or app provides, this is crucial in continuing to maintain the value that your software is delivering. Make use of your standard communication channels – social media, blogs, email marketing, and so on – to let your users know how to disable this system if they want to continue to see your new notification requests.
Increasing take rates with tooling
A powerful workaround is present in the PowerInbox Push solution. This solves the issue of take rate by instituting a pre-filter. As you generally only get one chance to subscribe a user to your notifications, and a user declining to subscribe will impact your reliability metrics in Google’s algorithm, it is important to pre-filter your users before presenting them with the browser-based notification request. The process goes something like this:
- A user visits a website powered by the PowerInbox Push Notification service.
- PowerInbox detects the new user, and presents them with a UI dialog in your website’s interface. This dialog asks your user for their permission to enable notifications.
- If the user approves this permission, PowerInbox forwards the request to the browser and presents the native notification request prompt, thus improving both the take rate of your notification subscription requests and the overall lifetime value of your subscribers when your users grant the permission.
- If the user declines this permission, PowerInbox makes a note of the decline and no decline is registered by Google, allowing the pub to re-offer that user to subscribe at a later time. This reduces the risk your website is exposed to by reducing the opportunities that users have to intentionally refuse to subscribe to your notifications.
By doing this simple pre-filtering step, you’ll likely see some potential decrease in overall subscription rates for your notification stream, but the subscriptions that do come through will be more engaged with your content and thus more likely to convert, improving your overall monetization.
What does this mean for you?
With Firefox 72 leading the way, and Chrome 80 following suit, the mobile and desktop website notification space is changing very rapidly in favor of user privacy. Similar to Google’s regulation of the toolbar industry in 2012, companies that fail to respond to these changes run a strong risk of seeing a significant portion of their user engagement plans disappear overnight.
By following the guidelines provided by Google, and focusing on delivering user value with your notification system rather than attempting success in aggregate through excessive permission requests, your users can continue to see the time-critical information that helps them find the value you provide.