 Hi everyone. Thanks for joining. I'm PJ. I'm a product manager on the Chrome web platform team responsible for progressive web apps, notifications, and permissions. Today's talk is about quieter notification permission prompts and how recent changes to how Chrome handles notification permission requests can make browsing for the web a little better for everyone. There's also important information in here for developers who use notifications to help you improve your user experience, improve your notification accept rates, and to tell you about upcoming changes that will detect and flag abuse abuse of notification prompts or content. If you're not familiar with them, 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. Before we get into that, though, I want to talk about how users get enrolled in 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. I want to cover why we have notifications in the web platform in the first place in a little bit more depth. The 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 for food delivery notifiers, taxier ride-sharing apps, all dependent notifications to provide a timely tap on the shoulder to the user. And, well, you can imagine that some of these apps might be usable without notifications. You could see that most of the time, you're probably going to want one. We've also all equally experienced some of the misuse of notifications, though. That includes things like unwanted marketing, promotions, or content that just isn't very important or relevant to us at a given moment. To address this problem starting in Chrome 80 that was released in January of 2020, we started making changes to how these notifications requests work to help make browsing the web safer and less interruptive. We're going to get into that new UI in the next slide. In Chrome 80, we added quiet notifications 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 dialogue 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 info bar at the bottom of the screen. Quiet notification UI aims to reduce the visual priority and interruptiveness of notification requests. On desktop, which 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 info bar. In both of these cases, in product help explains to the user why notifications were blocked on the site. Quiet notifications UI was created specifically to address the concerns I mentioned earlier in this talk. We receive frequent complaints from users in Chrome feedback about disruptive notification permission prompts or unwanted notifications. That being said, there are services with tens or hundreds of millions of users like messaging apps and calendars that are depending on timely web notifications every single day. Let's talk for a moment about how users get enrolled 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 few percentile of notification accept rates. So the absolute rate needed for quiet notification UI does change over time because we are using percentiles. We'll also periodically increase the accept rate percentile that's needed to preserve normal notification UI. We 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, we adaptively enable quiet notification mode on their behalf in Chrome settings if they repeatedly block notification requests. As sites improve their behavior and use of notification permission requests, we expect that there will be fewer and fewer users who are adaptively placed in quiet notification UI mode. Finally, and this is starting in Chrome 84, which is coming up soon, we're going to begin enforcing against abusive notification prompts that try to mislead users or phishing for private information or promoting malware. In this case, in addition to quiet notifications UI, the user is going to be advised in the notification prompt that the site may be trying to trick them. So 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 know 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 UX, 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, which is a public database containing important information about real world Chrome metrics for popular destinations on the web. There's a minimum number of users and decisions that are required for data to be available in the Chrome User Experience Report, and that's to help with preserving visitor privacy. So if your site doesn't have data in the Chrome User Experience Report, you may need to get that information from somewhere else. For example, most notification service providers will have this instrumented so that you can check your accept rates. Or if you've rolled your own notification implementation, you may need to add your own instrumentation. It's also a good idea to look at the notification accept rates of sites that are like yours in the Chrome User Experience Report, so you can get a sense for what the benchmark accept rates are and aim to be better than those. The article linked here in the slide will give you more details about how to use the Chrome User Experience Data Set to learn more about user's notification permission prompt decisions on your website. So the second thing you need to think about is how can you make your notification requests more in context? I know I mentioned this before, but it bears repeating. 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 a response 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 notifications if they want them. If your user doesn't accept notifications with this in context pattern, there's a pretty good chance that they just don't want notifications and you should respect that decision. Before I finish, I want to share a little bit about what's coming next for notifications. First, we're planning to increase the accept rate percentile that's needed to have normal notification prompts. Since this is a percentile as well, something to keep in mind is that if other sites are improving their notification UX and you're not, your site may be slipping into a lower percentile and quiet notifications may be activated for your site. If your site has a notification accept rate of over 50%, you're in safe territory, but we recommend aiming for 80% or better. Second, Chrome places a high priority on user privacy and security, and we intend to take more steps to protect users from abusive notification in the future. That includes more protections from abusive notification content, as well as retroactive action to help users who may have already enrolled in notifications from abusive sites prior to the release of Chrome 84. Most important, as we improve the signal-to-noise ratio of the web notification ecosystem, we hope users will come to view notifications as being more helpful. If this happens, it means we're doing a good job at protecting users from unwanted notification prompts and unwanted notification content. Ultimately, this will help developers who use notifications for key functionality in their apps as users are more likely to accept notifications when they have less reason to be worried about spammy or abusive notifications. Thanks again for joining today, everyone. Have a great day.