The Importance of Good Notifications

In this episode, we're joined by OneSignal CEO & Co-founder, George Deglin who interviews Google Chrome Product Manager, PJ McLachlan to discuss Google Chrome web push browser changes, the future of notifications, and the importance of PWA's (progressive web apps).

PJ speaks at length about what trends the Chrome team was seeing, how they are tackling the challenges, the importance of notifications and how they want to improve the quality and utility of notifications.

Need a quick summary? Here are 4 big takeaways from this podcast:

1. The essential driver for the changes seen in Google Chrome’s web push notifications was to “increase the signal to noise ration in the notification ecosystem”. The Chrome team saw that improperly used web notifications culminated in web push becoming one of their top five user complaints.

2. Seeing the need to make sure that users were receiving high quality notifications, the Chrome team made it a priority to “make it easier for users to tune out requests for notifications, access from lower-quality sources and/or outright abuse of sources.”

3. From PJ’s perspective, “what we want is that a developer who's choosing to use web technology would have the same tools and capabilities as a developer choosing to use any other technology.”.

4. Ultimately, the Chrome team wants for sites to focus on benefiting the user by following best practices for web push notifications. “Think about things from the user's perspective. They're getting bombarded with prompts from a lot of different sites. That's something that hopefully will change over time. “

PJ can be found on Twitter, where you can provide product feedback or pose questions.

Enjoy the conversation? Please subscribe to the OneSignal Podcast at your preferred podcast directory, Spotify, Apple, Google, TuneIn, Stitcher, among many others.

Josh: Welcome to the OneSignal podcast where we aim to educate ourselves on product, industry and best practices as it relates to building and growing a custom messaging practice. This is your host, Josh Wetzel.

Today, we have a great guest. Google Product Manager, PJ McLachlan, will be interviewed by OneSignal CEO and co-founder George Deglin right here on what being a web champion means, how the whole team thinks about PW as Chrome web notifications that feature customer engagement functionality [00:39 inaudible]. We're really excited about this interview. So, I'm going to turn it over to George and PJ now.

George: PJ, thank you for joining us. So, you've been at Google for nearly two years. Can you tell us a little bit about what your role entails?

PJ: Sure. Yeah. I'm a Product Manager on the Chrome Web Platform Team. The Web Platform Team focuses on features of the web platform across our browser. So, these are APIs like web payments or installable web apps like progressive web apps. In particular, I'm responsible for progressive web apps, also often referred to as PWAs, on mobile and desktop permissions and notification. So, a real focus on where are the user experience and user interface touches on underlying device or operating system features.

George: Yeah. Great. Can you tell us a little bit about how your team thinks about the open web and the future of native apps versus progressive web apps?

PJ: I always found that as a little bit of false competition between web and native apps. Those two things complement each other. There are different technical approaches. Sometimes they solve the same problem. Sometimes they solve different problems. I think developers should look at them as different tools for getting the job done. With a given job, we'll apply usually the right tool.

How I think about the open web is that it has a tremendous momentum behind it. There's tens of millions of web developers in the ecosystem. It's also evolving, I think, very rapidly in terms of its capability. So, that's something that our team is investing in significantly with new features and functionality. For example, desktop PWAs becoming installable last year and new features in notifications like the quieter notification prompts that rolled out recently that really increased the utility of the web for developers and users.

George: Yeah. Great. So, on that topic, I think that's something that a lot of customers of OneSignal have been keeping a close eye on. This quiet permission prompt that you introduced, can you us a little bit about the drivers behind that change?

PJ: Sure, yeah. The most essential driver for the change is to increase what I think of as the signal to noise ratio in the notification ecosystem. Something that we were seeing in feedback you're receiving from users to Chrome was that notifications were a frequent user complaint. They were in our top five user complaints. There was overall a negative user sentiment towards notifications and web notifications being called out in particular because we're just seeing more abuse problems with the web notification ecosystem than in the native app ecosystem just because it's so easy in the native app ecosystem if you are unhappy with a notification to just delete that app. Whereas in the web notification ecosystem, the UI was harder for users to navigate, to understand where was this notification actually coming from and what do they do about it if there was something that they didn't want.

We really-- I guess I won't use the word "we". I'll say, I really think that the notifications have a lot of utility for users for all kinds of use cases. Those use cases like ride-sharing, calendars, mail, social networking, package shipping, tracking, order delivery, et cetera. There is a ton of reasons why users get benefit out of notifications. But we needed to do more to make it so that users were receiving high-quality notifications and they make it easier for users to tune out requests for notification, access from lower-quality sources and/or outright abuse of sources. We were seeing a fair number of sites that had either deceptive or either doing deceptive marketing or distributing malware notifications. We really want to make sure that we're acting on the user's behalf and reducing the noise level of those kinds of notifications.

[05:00]

George: Yeah, absolutely. Yeah, we definitely see this as an opportunity to help surface the higher quality ones, and hopefully, just that user sentiment to be more positive. One thing that can be challenging is explaining how this difference goes into the fact, like what is the difference between how the traditional permission prompts worked versus what the new ones do as far as the quiet prompting?

PJ: Yeah, the main difference is that the old prompts were more interruptive of the user flow. So, for example, on mobile, you effectively were forced to make a decision when that prompt came up. Whereas with the quieter notification prompt, it's possible to continue your browsing journey without making any decision at all if you wish, and the prompt is easy to dismiss, less intrusive of the viewport over the web content.

The same is true on desktop. The previous prompts could be ignored on desktop. There's more screen real estate to work with, so it's easier to make prompts that don't disrupt browsing, but it did still occlude part of the web content viewport. So, now the new prompt is completely on desktop in the omnibox. It doesn't include any content. So, it's much easier for the user to choose not to engage with it, but it was also a goal of ours to ensure that the user interface was accessible within a single click from the content.

So, we didn't want to tuck it away completely into a sub-menu because there are all these use cases where not only are notifications useful, but in many cases, they might be essential. If you imagine a messaging app, if you're not receiving notifications about new messages, that messaging app's utility is, it's a small fraction of its utility with notifications.

George: Yeah, absolutely. So, in some cases, the traditional prompt is still showing, right? So, what are the ways that Chrome determines what type of prompts should be shown?

PJ: So, first, this is a setting that's exposed to the user. So, we want users who don't frequently use notifications or prefer the quieter UI to just be able to opt into it. So, that's now available as a Chrome 80 in the settings panel or users can just enroll in quieter notifications.

Second is, we've found that there's a set of users who are all basically never say yes to a notification. So, they're not interested in receiving web notifications for whatever reason. For these users, it doesn't make sense to interrupt their browsing journey with a notification request. So, the quieter UI makes sense for them. That way, if at some point they changed their mind, there is a particular application they need. Where they need notifications, they can still turn them on, but it's less prominent and doesn't disrupt their flow as much.

And then the third case is with sites that have a very low notification accept rate. Right now, this is being applied as a percentile. So, that's why it's complicated to give an exact number. The absolute number will shift as the ecosystem changes. But this is really the enforcement against abusive sites where we see, for example, under 5% accept rates. Don’t take 5% as kind of the absolute bar, but just to give you an example of the types of sites that would fall under this category right now. These sites typically are either offering almost no value to the users through notifications. It's something that users are able to see even when the notification permission is requested. Or, it's a site that's clearly abusive.

So, those are the kinds of sites that are automatically enrolled in quieter notifications. We're working with the community to make sure that content creators are aware of these changes and are doing more to implement best practices to increase enrollment rates and accept rates. It's in the best interest of any content site to be reasonably sure that a user is going to say yes before prompting. So, that's really the focus of our efforts with the community right now, is to help them understand the UX that can lead to a user accepting the permission prompt.

George: Yeah, that makes a ton of sense. In that latter case, let's say that one of these prompts is in sort of that last category, decides to reform itself, decides to implement a better user experience around notifications, is there an opportunity for them to get the original prompting behavior restored?

[09:55]

PJ: Yeah, absolutely. So, this will happen automatically over time. So, as part of the quieter notification auto-enrollment, it rolls over a 28-day window. So, if accept rates improve over that 28-day window, as soon as they move above the threshold, the standard notification prompts will be restored. So, this only applies to sites that are being enrolled as a result of the low accept rate. So, if the users said, "I prefer quieter UI and their preferences," the user's preference will always be respected. It's only in the case where a site has a very low accept rate and is therefore enrolled in quieter UI that they would then be unenrolled in quieter UI if their accept rate improved.

George: Yeah, that's really useful information. It's great to see how deeply your team has thought about this. So, yeah, shifting gears a little bit, I'm curious how you see notifications evolving in Chrome or amongst the web.

PJ: I think from my perspective, what we want is that a developer who's choosing to use web technology would have the same tools and capabilities as a developer choosing to use any other technology. So, we keep a close eye on the ecosystem from, like what's happening in the Android native notification space, for example. An open question for us to explore is adding channels to web notifications. That's something that I'm very interested in reaching in the community feedback on. You can reach me out on my Twitter account. We can probably tag that at the end of this.

The concern with channels, adding channels so far and the reason why it hasn't shipped to date is that it's an Android-specific idea. There's no concept of channels in iOS, for example. So, we're just not sure how the community would think about using these because generally, the web tries to avoid implementing things that are really specific to a particular operating system or device class. Right now, channels is kind of a narrow capability. But if it's something that the community would be interested in, I'd love to hear back from them. Generally, we're interested in offering a comparable feature set to what users are used to.

On desktop, things that we're evaluating are, for example, ability to receive notifications when Chrome is completely closed. So, right now, for desktop notifications, Chrome doesn't need to be in the foreground, but Chrome does need to be running. That is a limitation for desktop notifications. For obvious reasons, it's complicated to make the decision about whether or not to allow them to arrive in the background. Actually, maybe it's not obvious. So, I'll just say like, I mean, we would have to be running some sort of software in the background, which users might not like. It'll use some memory. There's all kinds of reasons why users might not want this. So, it's a tricky trade-off to make. Some users want those notifications regardless of whether Chrome is running or not and some don't. So, again, it's something that I would love to hear from the community about.

George: Yeah. Cool. Yeah, hopefully, we can help you receive some feedback from our customers and others that see this. So, what advice would you have for websites in creating experiences that you'd like to see more of on the web?

PJ: Sure. Yeah. So, there's a lightning talk that I put together for Chrome Dev Summit in 2019 that covers a lot of these patterns. It has visuals just to help web developers and designers see what good patterns look like. But I think the central idea behind pretty much every UX pattern on how to use notification permission or any other enhanced permission requests is to think about things from the user benefit perspective. Does the user really benefit from enrolling in this particular capability at this moment in their journey? And if they don't benefit at this moment in the journey, then why not wait until the moment when they will benefit to ask them?

When we see sites or web apps take the time to only ask for permission when it's contextually relevant to the user at that moment, the enrollment rates can be very high. There are some sites which you can see in the Chrome user experience report data now that has 80%, 90% accept rates on web notifications. That's all about when they ask and the level of utility to the user.

So, focus on that benefit to the user. Think about things from the user's perspective. They're getting bombarded with prompts from a lot of different sites. That's something that hopefully will change over time. So, I actually hope as an outcome of this over the medium to long-term is that sites that are implementing those practices should see an increase in accept rates as the quality of notifications goes up. And hopefully, users feel a little bit less bombarded. That you have to be seen, but it's one of the objectives here.

[15:28]

George: Yeah, I definitely agree. I think as we see more websites adopt notifications as a critical part of their user experience, more and more intentional go into making sure that a lot of the right product attention and best practices are being put into that part of the experience as well.

PJ: Yeah. And sites that are using engagement features like notifications or installability effectively typically see improvements in their top-line metrics, whether that's conversion rate or other engagement metrics like time on site, repeat visits.

George: Yeah. Excellent. Well, PJ, this has all been super, super helpful, super informative. I definitely learned a lot myself. Thank you again for taking the time with us today.

PJ: Thanks so much. I appreciate it, and I look forward to working with you more in the future.

George: Thank you.

PJ: Take care.

Josh: That was a great session with PJ. Really appreciate him joining us. Really interesting commentary on [16:23 inaudible]. What were the summary high-level things that you got there, George?

George: Yeah, I think it's really great to see how deeply the Chrome team cares about notifications and also how deeply they care about user experience. And not just the care they put into it, but also the really data-driven approach that they're taking to understanding how people use the channel today and how the channel needs to evolve in the future to be a great experience.

Josh: Yeah. Well, thank you all for listening. Subscribe to the podcast if you liked the content you're hearing at your favorite directory. And from there, have a good day. Stay safe. Take care.