Written by Ramón Saquete
Table of contents
- 1 How can Push notifications increase traffic and conversion?
- 2 How to create Push notifications?
- 3 What can a Push notification do and display?
- 4 Best practice when requesting a user to subscribe to receive notifications from our domain
- 5 Best practice when displaying notifications
- 6 Can Push notifications be measured?
- 7 How do they work technically?
The web is slowly evolving to become something of a web and mobile app hybrid. I had already talked about web apps some time ago, a kind of applications Google aptly named Progressive Web Apps. For this post, however, I am going to focus on one of the most important features that a progressive web app should have, Push notifications.
Push notifications in a web environment are similar to notifications of a mobile app. Pending notifications of websites we’ve subscribed to will start appearing, without us having to actually open these websites in our browser, just when we open our browser on a desktop computer, and even without doing anything on our mobile device. They can also appear whilst we’re browsing websites we’ve subscribed to, of course.
If you want to implement these notifications on your own website, besides having to put some effort into programming them accordingly, you must know that they only work with HTTPS domains. Instead of moving your website to HTTPS, you can also subscribe users redirecting them to a different domain that does have HTTPS. Evidently, if it’s your actual domain requesting users to subscribe, it will always look much more trustworthy. Moreover, this is something that also allows us to offer other progressive functionalities, like caching of pages, so that our website works offline.
Push notifications only work with HTTPS domains.
How can Push notifications increase traffic and conversion?
The most important thing to know about Push notifications is that they can be customised entirely for each different user, without them having to register on our website. We only need to request their permission to display notifications once. In a similar way to Google AdWords remarketing campaigns, but asking for each user’s permission and not having to pay for each click. If we try not to send too many notifications, and most importantly, bring added value to our website’s users providing interesting information, then they won’t block our notifications, and may click on them, thus returning to our website.
For example, in an online store, we can remind users that they have pending items in their basket, or that there’s a special offer for a product that we know a user’s interested in (because they checked this product’s details, because they added it to their wish list or to their shopping basket). Another interesting option is to notify them when a product they want becomes available, something that up until now was only possible if we asked a user for their e-mail. If we have a blog, we can provide the opportunity to users to subscribe only to those posts, which we think they might be interested in, based on the categories they usually visit or whichever ones they’ve chosen through a configuration panel. Facebook and other social platforms have been using this kind of notifications for a while now, to notify users about new comments or events.
Depending on your business model and what your website has to offer, it’s just about being a little creative.
How to create Push notifications?
They can be generated automatically by your website, whenever certain events occur, or there can be an administrator, who is in charge of their management. Your web developer can suggest several different options to create notifications. For example, there can be filters assigning different types of notifications to specific types of users; time and date when you want them to be sent, actions that users can perform upon clicking on each notification, etc.
What can a Push notification do and display?
Notifications must have a title and an icon (this is optional, but highly recommended), but it can also include a text and an image. In terms of their behaviour, they can make a phone vibrate, and request users to perform concrete actions.
The action can be carried out upon clicking or tapping a notification, or there can be several options with several different actions. You can open a URL in their browser, activate a tab with the URL (if it was already open) or to perform an action server-side, and display a message confirming that the action was performed correctly (for example, that a product was saved in your customer’s list of favourites).
Notifications can be assigned a tag, enabling us to combine various notifications into one, to replace them or to delete them. The following page has examples of all these features:
And with the following notification generator you can try to configure them:
Best practice when requesting a user to subscribe to receive notifications from our domain
When a website requests permission to send notifications to users, a default browser message appears, which usually says something along the lines of “www.youdomainname.com wants to send you notifications”, and there are two buttons, one that allows the subscription, and another one that blocks it.
If a user hits the ‘Block’ button, you hardly ever get another opportunity to ask them to subscribe again.
To revert blocking your notifications, a user will have to go to the browser’s settings, remove your website from the list of blocked ones, and only this way you will have the chance to ask again. This complication makes it rather improbable that something like this will happen again. This means that you need to be aware of the fact that your chance to convince a user to subscribe is truly unique, so it’s counterproductive to ask their permission to send them notifications as soon as they enter your website, as it can be perceived just as intrusive as an interstitial ad. For that reason, you need to convince them first, and to make them see that their subscription to your notifications will really bring value to them. For example, we can suggest subscribing to notifications after they’ve purchased something at our store, to let them know about their order’s progress. To do this, you can add a button to your “Thank you for your purchase” page with the following message: “I would like to receive notifications about my order’s status and other special offers”. If they click on it, you can then display the official message requesting to receive browser notifications.
It is also annoying when users are offered notifications with a pop-up window. It is best to just display a button. In the case of a blog, this button would ideally appear next to the RSS link.
If –in spite of this advice– you prefer to be more aggressive and display the request for Push notifications the moment a user opens your website (I really do not recommend doing this), first you should display a pop-up with a fake request, before displaying the real one from the browser. This way, if they block the first fake request, you can always try asking them again at a later time. Such technique grants you the opportunity to explain to the user what your website can offer, and why you’re asking their permission.
Best practice when displaying notifications
Schedule custom and relevant notifications for your users. Don’t harass them with offers or purchase suggestions, as they will end up cancelling their subscription.
All notifications always show by default their domain of origin, so you don’t need to include who you are in your message. It is, however, recommended, to include an icon and a badget (smaller icon displayed on the phone screen’s status bar), with the logo of our brand or website.
If we don’t use an icon, there will be an empty space in its stead, and if we don’t use a badget, the browser will display its default one.
As for vibration and sound, they should only be used when notifications are really important for the user. To make a user’s phone vibrate just to tell them about a new product they might be interested in is way too intrusive.
Can Push notifications be measured?
Yes, we can easily know if a user has clicked or tapped on a notification if we add parameters to URLs used in our notification’s action, and then analyse it in Google Analytics.
If we want to get conversion rates, the developer is the only person who can prepare the system for storing how many notifications have been sent, and how many of these were seen by the user. Your developer can also prepare the system to store URLs seen through the notifications, which will give you even more reliable stats, than the ones provided by Google Analytics.
How do they work technically?
In general terms, this is how they work:
On the image above, we can roughly see what happens when we send a notification. The Push service allows notifications to be stored, until subscribed users open their web browser or switch on their devices.
Notifications are sent signed and encrypted, so as to avoid the Push server from accepting fake notifications from spammers. For that reason, I recommend using a library to send notifications.
When we send a Push notification there’s a series of parameters that can be configured through Web Push protocol headers:
- Notification expiration date: this is useful for time-limited offers, or for information that eventually stops being relevant.
- Notification subject: if the Push service receives several notifications with the same subject, only the last one will be sent to the client, so we can ultimately use the notification subject to override certain notifications if there’s an error or if we have a notification that invalidates the other.
- Urgency: if the device is low on battery and the priority is low, the Push service may not send the message until the user plugs in their phone. If we use this parameter correctly, it is less likely that a user will deactivate their subscription.
As good developers, we should control error messages that we receive from the Push server and act in consequence:
- When the notification has been sent correctly to the server (code 201) we can register it as such.
- If we exceeded the maximum number of notifications, we should try again later (code 429).
- If the subscription’s expired or is no longer valid (code 404 and code 410) we must request the user to subscribe again.
- If we exceeded the maximum size of information we can send through the notification to the Push server (code 413) we must reduce the message’s size.
With every Push event that we will place in the service worker, we will have a code to display a notification. If the notification action consists in directing the user to a specific page, we can request our server this page and cache it in advance inside this event, using the Cache object.
In the service worker we will have an event called “notificationclick“, to capture notification actions. Here we should control that notifications don’t get displayed when a user has already opened a URL of our website, which also shows the same information that we will send to them in the notification. We can also highlight this information within the page somehow, instead of displaying the notification.
Presently, Push notifications are only available in Firefox (desktop and mobile), Google Chrome (desktop and mobile), and Opera (only desktop version). They can also be used in Safari, but for the time being, the implementation it requires is different from other browsers.
With all this information you should have a pretty solid base to keep investigating and to think of situations where notifications can prove to be useful. I hope it was an interesting read.