An intro on what are Web Push Notifications?
Web push notifications (also called Web Push) 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.”
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.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.
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. It particularly addresses the pain of businesses, which have low transaction frequency with the user (like insurance, loans etc) and don’t have or even necessarily need a mobile app.
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
Like email, web push can also be targeted to the exact user thereby promising relevancy which now users want more than yesterday.
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.”
Do not confuse web push notifications with old-school-classic web notifications, although confusion is genuine as both of them relatively work in the same way. However, the difference is that unlike web push, web notification will work only when the corresponding web page is open in the browser. So, if the concerned web page is closed you can still trigger web push but not web notification.
Also, web notification works with both non-SSL and SSL website which web push doesn’t (will read about it ahead)
Web push notification only works with SSL secured (https) websites
It’s because web push depends on service worker which is a script that browser runs in the background. 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.
Setting up a web push notification campaign
There are three stages involved in setting up a web push notification campaign.
Permission ⟶ Segmentation ⟶ Measurement
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’.
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.
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.
Pro tip 1– 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.
Pro tip 2– Send a welcome message as soon as the user accepts notification request.
- 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.
This is crucial for every messaging campaign but we see it missing it in browser notification campaigns because
- The available SaaS products in the market do not collate enough data to provide flexibility in segmentation. They focus entirely on engagement and are not much into the analytics side.
- Another problem is the usage of standalone web push engines which are oblivious of the user’s engagement on other devices and channels. Since customer engagement with a brand is built across myriad touchpoints siloed engagement cannot achieve anything more than clicks (which is okay for media websites since their conversion is viewership).
So, if you have a long conversion cycle which involves more than a couple of clicks then it is imperative that you deploy an engagement suite that gives you the holistic view of the user’s behavior and lets you build an engagement plan spanning across devices and channels.
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
Pro tip 3– 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.
I visited the dashboard of two prominent web push notification engines and this what they report in their stats
Ultimately, they report just CTR.
Which is understandable since they focus primarily on engagement and analytics is not their USP as I stated previously.
Now, CTR is a number one vanity metric in perhaps every sphere of digital marketing, let alone browser push. It doesn’t give a clear indication of anything. Low CTR is an indication of poor notification copy and vice versa which obviously cannot determine the success of a campaign.
Hence, to effectively measure the success of any campaign we take into consideration two critical metrics.
– What is ongoing churn rate?
– Which notification caused the most unsubscribe?
Most of the notification engines provide this data after some mix and match.
This is the primary interest of any marketer. Eventually, your push messaging campaign succeeds only if it makes the user more valuable than he was before the campaign. Enterprise automation platforms (like WebEngage) which have web push in their suite provide much better UX to track conversion. If you don’t use any of those platforms and rely on Google Analytics this is what we can do:i. Define the goal
The goal could be anything like purchase, session duration, download, a specified number of pages viewed etc. GA provides you with four goal types. While the first three are self-explanatory, event is most commonly going to be used. Refer to Google Help article for helpii. Now, track the conversion
Once you define the goal (event) your requirement is to track the conversion against your web push. To do that it is imperative to add UTM parameters to the landing page URL. Now you only need to go to Reporting-> Conversions-> Goals and track the goal completion by adding the traffic source filter.
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.
That’s all. I hope this article satisfactorily answers the question that you had pertaining to browser push. If it doesn’t, please leave you questions in the comment below and we shall follow up.
If you like this article, you would also love to read this: