Note: the Chrome team is answering questions about push notifications on stack overflow if tagged either progressive-web-app, service-worker or web-push.
Best Practices for Push Notifications Permissions UX
Status: Public (since 2015/03/04)
Author: owencm@chromium.com
Exposing new capabilities to the web empowers you to create amazing experiences for your users, but with great power comes great responsibility.
This document outlines some best practices the Chrome team has developed to help you provide a high quality experience for your users when requesting permission to access these new APIs. This advice, and the feature itself will evolve over time as as common patterns emerge and we receive feedback from users and developers. Will are committed to ensuring the feature is used in a way that generates value for users.
Focus on creating value for your users. Use these new capabilities to make your users happy and everything else will follow.
Additional background
- In Chrome, when a user denies a site access to a permission, that site will not ever be able to ask for it again.
- On mobile devices, permission prompts consume more than a third of the screen real estate so it is important to carefully plan when to show them.
- iOS has a similar permissions model to the web, so advice about permissions flows on iOS is highly applicable to the web.
Principle: The user should show intent before a site asks for a permission
We believe users should only see a permission prompt if they’ve demonstrated willingness to grant that permission, or at minimum, intent to use a feature which requires that permission. In particular, we strongly advise against triggering permissions prompts on page load.
Showing users permission prompts they aren’t interested in is distracting and spammy. To ensure Chrome users get the best experience on the web we’re exploring automatically denying permission prompts from sites that display prompts which users largely ignore or deny (or worse, revoke).
Examples
Bad UX.
Here the site triggers the permission prompt on the first page load without any context. It is very unclear why the user would want to allow polymerairways.com to send them notifications and the prompt distracts the user from their task.
Good UX.
Here the site shows a clear opt-in call to action, “Get Notifications for Flight Delays” at a logical point within the flow, giving the user context for the permission prompt. When the prompt is shown, the site dims the rest of the screen to help guide the user through the flow.
Tips
- Assuming the user clicks ‘allow’, this site now has the Notification permission for the purpose of delivering notifications about flight delays. If the site wishes to send notifications for another purpose such as promotional discounts it should ask for their explicit permission.
- This model is just like email. Sites shouldn’t send their users marketing emails without their consent, even if the user has provided the site their email address.
- This site should add a section on the site for users to manage their notification preferences, especially since it will be hard for the user to get back to the confirmation page if this the only place they can opt-out again.
Good UX.
The site showed a clear opt-in call to action It then further explained the feature before directly requesting the permission. When it requested the permission it greyed out the remaining content, ensuring the user focuses on the permission prompt.
Tips
- It is sometimes useful to explicitly explain the permission prompt to users if many are denying or ignoring the prompt despite having shown intent to use a feature that requires it. There are many examples of iOS apps using this pattern.
- When permission prompt appears, consider ‘greying out’ the remainder of page with an overlay. This will help users notice and pay attention to the permission prompt.
How to measure success
Measure the acceptance rates of permission prompts. If it is low then value isn’t being created for the user.
Principle: Sites should provide in-site management controls for Notifications
Chrome provides users a kill switch that disables all notifications from a specific site. If used, this site will never be able to send the user notifications again.
Instead of causing users to rely on the kill switch we recommend sites allow users to set notification preferences within the site itself. Specifically, it should be easy for the user to find the relevant setting to disable notifications from any page a user will reach from a notification. For example, if a user receives a notification about breaking news, it should be obvious how to find settings and disable notifications.
This is especially important if your site delivers multiple kinds of notifications—or may want to in the future—as users may want to opt out of one type of notification, but leave others enabled. Furthermore, if a user disables notifications using in-site controls the site may then encourage them to turn it back on in the future when different or improved notifications are available.
If a large number of users choose to use the kill switch on a site this is a strong sign that it is not providing value for it’s users.
Examples
Good UX.
The site provides a way for the user to control the frequency of breaking news notifications or turn them off entirely.
Tips
If you might send notifications to users which aren’t logged in to your site ensure users can set notifications settings without logging in to avoid the situation where a notification takes them to a page which requires them to register or sign up to disable future notifications.
How to measure success
Measure the number of users revoking permission with Chrome’s kill switch. This can be done by storing a cookie when user grants permission and then verifying on a regular basis that the permission is still granted. If it’s state has changed from granted to denied then the user has revoked the permission.