Web Push Notifications Done Right

Hello, dear developers. Let's talk about web push notifications. In this short session, I'll share some tips and tricks on how to use this extremely powerful API for good. My name is Maxim Salnikov, I live and work in Oslo, Norway, I do developer engagement in Microsoft, and I'm a big, big fan of the developer communities.

I run few meetups, conferences, and you often find me presenting about web and cloud technologies on the stages of meetups and conferences. And you know what, folks? Let's stay on this slide for a couple more minutes because using this set of information pieces, I want to explain or remind you what is web push notification.

First of all, let's pretend that this is a notification that came to either our or our user's device, and it has a title. Actually, this is the only required component of a notification's API notification object, but definitely you want to use more components of it, like a body. This is actually main text of the notification. Also, many platforms support relatively small, at least by specification, graphical components, called icons that is normally placed somewhere close to the title and body. Then, actions. All platforms support at least generic actions when users click or tap on the notification bubble, and some platforms support even multiple set of the actions, where we provide name, icon, and actually what to do. You write the code yourself, of course. Some platforms support larger graphical component called Image in Notification API. These are pieces of information we send as developers or business owners. Also, there are some components provided by the system or operating system itself, because we want to let users know where this notification came from, and maybe they can take some extra actions. First of all, we talk about Web Push notifications. This is why there is always an icon of the browser where the application was running. Also, there is an origin where this notification came from, and a set of, let's say, extra actions, either as a menu item or a three dot item expanded to some extra actions. It's for the users to react somehow on, for example, unwanted notifications. They can either block the sender, or the browser, or notifications in general. That really depends on a particular platform, this set of features. This is anatomy of web push notifications, if you wish.

Then, let me provide some motivations. Why using web push notifications is a really nice way to reach out to your users. First of all, compared to all other ways we can organize communication between us, as developers or business owners, and users of our web app, web push has a very important advantage. It works regardless of the application state. So once subscribed, users can close application, application tab, they can close the browser, notification will arrive anyway. Of course, this is because modern browsers, they always have some background service component that is always on duty. This is how all this works.

Compared to older or conservative or traditional ways to reach out to our users, for example, Push has way higher opt-in and click rates, compared to other traditional ways to reach out to users like, for example, SMS, it's way cheaper. And actually, since the delivered channel is completely free, we cannot even say how many times cheaper because we cannot divide by zero, right?

Then, I hope that my previous slide convinced you that the format itself is quite rich with different ways to express what we want to deliver to the user. And after all, it's at least relatively easy to set everything up and you can start sending message immediately. Of course, after your user's subscribed. And last but not least, motivation point is this one. After arrival of iOS 16.4 and the latest macOS, we now have 80% of Internet users who are technically can receive web push notifications. I think this is very impressive number.

Now, some tips and tricks. First of all, web push as a flow contains two separate parts. Subscription, and then sending notification itself. Let's talk about subscription. Politeness is a must there. All modern browsers are extremely protective in that sense. They don't want to annoy or bother users by some unwanted notifications themselves, but even requests to subscribe to notifications or allow showing notifications. This is why it might sound strange from me, like from ambassador of web push API. But dear developers consider different alternatives.

First, literally think about web push API like about last resort for you to reach out to this particular user. Because we all know how push notifications work in general. If we are not in focus mode or not in DND mode, you will be disrupted as a user by this pop up like message bubble or something like this. Then now it's only technically to initiate subscription requests after explicit action from the user. So don't even try to subscribe users somehow in the background. No, it will just not work even technically. The click or some other action from the user side is required.

Actually you have only one chance to get this permission to show notifications from the user. Because once they hit block or even dismiss few times, your notification subscription request will not be shown, will be blocked by the browser itself. This is why it's really good idea to show soft prompt. Before calling this API method with show permission request dialog, show your own UI component like snackbar or dialog or whatever, where you provide all information about your messaging channel, what kind of content are you going to send, frequency, and of course what kind of way to unsubscribe from this messages. And then only then, if user is completely aware and fully agree and they click like button I do agree, then call this permission request dialog and then subscribe. And that's really good to separate these two pieces in your code because this notification permission dialog will be called implicitly after you try to just subscribe user to PushNotifications, but you can do it explicitly and then you have better flexibility to have plan B or plan C if user is blocking or dismissing your dialog.

Now, your best notification, time has come to send something to the user. So be transactional, try not to use, my personal ask for you never use a Push API for mass like broadcast message to all users. Keep it only for concrete users for concrete task like checking is available, new messages right, something like this. Of course, then it will be timely, personal and relevant. And yeah, you have all possibilities of notification API format to send information itself, not just hint about something is updated. And yeah, again, you have all possibilities to contain to provide very clear call to action or even set of call to actions if actions are supported by this platform. And after all, we have only a few pixels on the screen. So try to not repeat yourself and latest research shows that emojis are working better for engagement.

This is why as an exercise I did improvement of a generic notification from my imaginary airline about checking is available to, let's say, using a format of push notification API to the maximum. This is why I tried to remove all repeated components and tried to place as much information as possible and tried to provide very concise call to action.

Let's sum up. Web push feature is very powerful and very convenient for the users, currently available on all major platforms. You remember that 80% of Internet users can technically receive Web push notifications now. That's very important for us developers to not misuse, to not overuse this very powerful API.

Yeah, we have a set of services that can simplify our lives in setting everything up. Like this one. Small app I created for you to start testing Web push notifications immediately on multiple devices and on the same website you'll find extended presentation on the topic with more technical details, both video recording and slides. And my main call to action for you let's stay connected. Find me on LinkedIn and ask me about Web push API.