What is a Web Push Notification?
Web Push notifications were first introduced by Chrome in early 2015 in its 42 version. The version included “two new APIs that together allow sites to push native notifications to their users even after the page is closed—provided the user has granted explicit permission.”
The update allowed websites to send notifications just like apps could, so far. It was allegedly the most critical mobile feature that was missing from the web and thus upon release witnessed a tremendous adoption by web publishers.
Here is a complete tutorial to what is web/browser push notification:
In fact, the biggest exploiter of this channel is perhaps Facebook which, via this medium, has acquired the power to send you notifications, even if you don’t have the Facebook app installed. In fact, very interestingly there was quite a chaos among a significant number of facebook users, evident in this thread, who were confused, some to the extent of frustration, about how on earth is facebook able to blast them with notifications without having its app installed or even website open.
History of web push notification
2003- Blackberry OS launched push email. This saved executives and business class from constantly checking their email. Almost everyone believes that this is what that fueled Blackberry’s success.
June 2009- Apple launched APN (Apple push notification). The first push notification service ever
May 2010- Google launched Android Cloud-to-device messaging (C2DM). The first notification service by Google, introduced in Android 2.2 .
June 2012- C2DM was replaced by GCM to overcome the limitations that C2DM had. This is important because the current delivery of push notifications is facilitated by GCM. It has been added with additional features in its new version as FCM.
April 2015- Chrome launched Chrome 42 with support for native web push notification.
Jan 2015- Firefox extended support to web push with the launch of their version 44. This was not applicable on mobile site.
Aug 2016- Firefox extended support to web push even on the mobile devices.
Feb 2017- Chrome introduced rich web push notifications with Chrome 56
Anatomy of web push notification
Appearance of a browser push varies according to the browser and also according to the OS. For instance, for the same Chrome browser, web push looks differently in Windows and Mac and likewise for Firefox.
Check out the below diagrams to understand how web push looks in Chrome and Firefox browser.
Chrome in Windows
Chrome in Windows offers two unique features- banner image and action boxes. Mac doesn’t support these two and Firefox hasn’t introduced these features yet.
Chrome in Mac
In Mac, a significant chunk of the web push real estate is occupied by compulsory Browser’s icon. Rest is the same.
Also, like we discussed Chrome in Mac doesn’t support banner image.
Firefox in Windows
Firefox hasn’t introduced banner image or action box functionality.
Firefox in Mac
It is similar to how it looks in Windows except that ‘Close’ and ‘Setting’ buttons become visible only when you hover over it.
Not all browsers support Web Push notification
Since it is still in a nascent stage not all browsers and OS support it so far. Below is the latest table of browsers and OSs which support web push notifications.
|iOS||No browser support|
|Mac OS||Chrome 42+, Firefox 44+, Safari Mavericks|
|Ubuntu||Chrome 42+, Firefox 44+|
|Window||Chrome 42+, Firefox 44+|
What makes Web/Browser push notification a preferable choice among marketers
1. Easy to set up
You either go for a web push service provider which sets up your account in a jiffy (really). Or, you go the hard way, but yet relatively easy, of manual implementation in your web-app. And even if you go the hard way your web push notifications will be up and running in less than a day.
Read- How to add Chrome Push Notifications to a Web App
2. It kills the need of having an app just to send notifications
Since, most businesses especially blogs, weather, e-commerce rely extensively on notifications for engagement, the introduction of web push mitigates the need of having an app.
Further, there are three major downsides to launching your native app:
- Launching and marketing an app is real capital intensive. (there are 2.2 mn+ apps on play store already)
- According to Comscore most mobile users download zero apps per month
- 80% of mobile usage time is centered on only five apps.
Web push thus makes launching an app just for push messaging a bad proposition for any business. It particularly addresses the pain of those businesses that have low transaction frequency (like insurance, loans etc), basically the ones which don’t necessarily need a mobile app at all.
3. Assured message delivery
Web push doesn’t risk ending up in the spam folder. Neither it can be blocked by ad blockers. It shows right up on your browser even when the website is shut. In mobile, it shows up in the notification tray, just as app push notification, even when the browser is not running.
4. Like email, it can be targeted on one-to-one basis
Digiday had lately published a story in which it projected web push as an alternative to Facebook- which is plagued by its ever-shifting-algorithm. Quoting Anthony Sessa, VP Product at Mic, from the article “It’s (browser push) our feed. We get to control that feed and it’s not a black box like the Facebook algorithm. We can drive the conversation the way we want at the time we want.”
Marketers obviously wish to completely control the conversation something which web push permits. Just like email, it can also be targeted to the exact user.
How web push notification actually works?
– Push service provider, say WebEngage, essentially provides an application server. This server send the push message payload to the user’s device via FCM.
– FCM is the notification service by Google which lets you deliver message to the user’s device (both desktop and mobile). Google doesn’t charge you anything to use this service because Google is very generous.
– Now, FCM doesn’t directly flash the message on the user’s device. It first sends to the service worker. The service worker processes this information and displays notification to the user.
– What is service worker? Service worker is a script which runs in the background of browser and do a bunch of things. Visit this Google tutorial to learn more about them.
Web push notification only works with SSL secured (https) websites
That’s because web push relies on ‘service worker’ to operate.
According to w3c consortium specs, service workers will only work on secure origins (https://) and therefore web push too only works on https domains.
The HTTP websites, therefore, need to employ a third party service provider (like WebEngage) which does a little workaround.
What these service providers essentially do is that they create a subdomain of their own website, like yoursite.webengagepush.com, which is HTTPS and trigger notification to the user on client’s (yoursite) behalf.
So in the case of HTTP websites, web push is not natively sent by yoursite.com rather by yoursite.webengagepush.com.
For the same reason, the opt-in process for web push in an HTTP website is accomplished in two steps while in HTTPS it is doable in just one. We have documented this process in detail in our help center
UX hacks- how to take permission for web push the right way
Like already stated, to be able to send push messages to the user’s browser, web-app is required to take explicit permission from the user which is taken via a dialog box like the one pasted below.
There are three ways a user can engage with this prompt:
Default– When the user ignores by pressing ‘escape’ or by canceling the notification
Granted– When the user clicks on ‘Allow’
Denied– When the user clicks on ‘Block’
However, once the user denies, the browser doesn’t allow you to invoke the opt-in again.
It’s entirely up to the user to reverse his decision which can do by manually navigating a complex UI and change the site settings.
Now, as much as 60% of the users opt-out of push notification, so the probability of user changing-site-setting-to-receive-notification is the guess of any pragmatic person.
Our aim is to mitigate the probability of the user clicking on ‘block’.
Following are the two ways in which we can do that.
1. Introduce a popup to nudge for permission
The permission setting of web push notification could be vaguely compared to that of iOS wherein you have just one attempt to launch the push notification permission dialog box.
Now, to reduce the possibility of ‘don’t allow’ iOS developers camouflage the system opt-in with a pre-permission dialog box.
We are going to adopt the same trick for web push notifications too. Instead of directly launching the system permission dialog box, we are going to take the consent of the user via a notification that would nudge them to opt in the next step.
2. Trigger system permission dialog box by a click on a CTA button or widget
Another safe way of taking permission is to place a CTA button on your website which triggers permission dialog box upon click.
This is naturally a fail-proof method because it is entirely driven by the user’s actions. However, the subscription is obviously going to be low because the nudge is subtle and not on the face, like the previous case.
Pop a notification if the user who has already subscribed to your notification clicks on the button again.
Permission for non-SSL secured websites (HTTP)
The above two tricks that we learned is possible only for https website because as discussed non-SSL secured websites cannot trigger web push in the first place. These websites have to follow a two-step opt-in process. Let me illustrate an example of prettysecrets.com
First, service provider pops a custom notification like the one below.
If the user chooses anything other than ‘allow’, then it is at the publisher’s discretion to pop the notification whenever he wishes.
If the user, on the other hand, chooses ‘allow’ then the service provider (WebEngage) is going to open an opt-in window(prettysecrets.webengagepush.com) which in turn is going to pop the browser prompt.
This means that if the user opts in then notifications would be sent to him from the service provider managed domain(prettysecrets.webengagepush.com) rather natively from the client’s domain like it was in the previous cases.
Use cases of Web Push across industries
Having said that, browser/web push too has got numerous use-cases across industries and it warrants a whole new post to talk about it. In this post we are just going to highlight some of the use-cases that businesses can quickly explore:
- Cart abandonment
After user abandons the cart, send him a notification after an optimum time to nudge him to complete the purchase.
- Send time-sensitive offers
- Transactional message
If the user doesn’t have the app installed, this could be well used for providing updates.
- Behavior-based offer
A user who has expressed interest in a particular product page would be more likely to click on the offer related to it.
News and media
- Segmentation based on previous engagement with notifications
If the user has clicked on category A notifications the most then it clearly indicates his interest in that category and would be more likely to entertain notifications from the same.
- Live score of sporting events
- Update on the flight status
- Tailored offer based on behavioral history
Best practices while setting up a browser push campaign
- Do not send web push to the users who already have app push notification enabled.This is futile and carries the risk of duplicity as you might send the same message via app and browser.
- Send a welcome message as soon as the user accepts notification request.Why?
- It makes the user confirm that they have just subscribed to your push notifications.
- web push notification is a relatively new entity. It was introduced first by Chrome just a year ago, followed by Mozilla and Safari. A majority of users still confuse it for app push notification. So if they happen to receive a notification even after the app is uninstalled it leads to utter chaos (recall this facebook thread again). Sending them a welcome message would give them necessary hint about the distinction between browser and app notification.
- If you are sending a time-sensitive offer, make sure that you limit the expiration time accordingly. A user receiving the message when the offer is closed is a nudge to opt-out.
- Don’t invoke the permission on the very first visit of the user. It’s non-contextual and the user is most likely going to click on ‘deny’ unless he is really into you. And once he denies you technically lose that user forever on web push channel.
Finally, it should be noted that web push notification is still in its nascent stage and has several limitations, some of which I have listed below:
- Unless a browser uses default OS notification like firefox does where the non-interacted-with push can reside, there is no provision for the user to interact with the notification at the time of his choice. This way you have simply lost the opportunity to engage the user.
- It doesn’t allow media rich content. The maximum you can do is play with the logo and notification text.
- As discussed, browser push only works with the SSL website. Although, it is explanatory why browsers have kept this standard but still since the majority of sites are non-SSL this still counts as a limitation.
- It doesn’t allow rich media content. Only in Feb 2017 Chrome launched an update to their notification API which allowed marketers to send images, progress, list and action items to the users.
- Push message can contain only as many visible characters. Rest of them will be truncated.
That’s all. I hope this article satisfactorily answers the question that you had pertaining to browser push. If it doesn’t, please leave your questions in the comment below and we shall follow up.