We’ve all seen the little pop-up with a one line message and ‘Allow’ and ‘Block’ options when we open an address on the browser – either on our desktops or on our mobile phones. These are called ‘push notifications’.
In this article, we will talk about the history of push notifications, their effectiveness & how they work. Please note, in this article, we will only cover web push notifications (on desktops & mobile browsers). We will leave the mobile app and in-app notifications for perhaps another article in the future 🙂
Push notifications are best for:
- Short or urgent, time-sensitive messages
- Re-engaging your visitors/ customers
- Nudging them to complete a purchase / subscription process
- Adding another marketing channel to your strategy
History of Push notifications
How did push notifications start? This simple infographic provides some detail:
(Image courtesy: https://au.pinterest.com/pin/738731145097325693/)
Effectiveness of Push notifications
While many companies use Email marketing, SMS marketing, social media and more (which are all great), push notifications is a channel that should be optimised too. Let’s take a look at how web push notifications compare to the other marketing channels:
(+) Allows for a lot more content & more customizable than push notifications
(-) According to PushEngage, Emails have an open rate of 15% – 30% while push notifications have a view percentage of 45% – 90%
(-) According to PushEngage, emails have a click rate of 1-3% while push notifications have a click rate of 5-30%
(+) People spend more time on social media than any other online activity (source: http://www.go-gulf.com/blog/online-time/)
(-) Only 0.03% audience interacts with your tweet on Twitter (Source: wizshop)
(+) 90% of SMS messages are read within 3 minutes (source: docstoc.com)
(-) Considered low quality communication channel as no permissions are required from the user & phone numbers are easy to acquire
One of the critical reasons why push notifications are effective is because they are a permission based communication channel, especially web push notifications. This means only those who really want your notifications are those who enable it, making this channel high quality.
According to a recent survey of 1200 adults, nearly 70% of adults and more than 70% of young adults enable push notifications from their favourite brands’ apps. However, while this statistic highlights the effectiveness of app push notifications, as I mentioned earlier in the article, web push notifications differ from mobile app push notifications as web notifications also include desktop. 48.7% of total internet usage worldwide still uses desktop which means web push notifications enable you to reach out to this chunk of global users.
According to Business.com, if reach is the goal, mobile websites are performing much better than mobile apps. This means web push notifications become even more critical as it gives you the ability to send push notifications without investing in an app.
Data from Kahuna suggests that push notifications have high-engagement rates with click-through rates as high as 40%.
Listed below are the engagement rates by industry.
How does a web push notification work?
For push notifications to work, there are three essential things necessary:
- HTTPS – Web notifications can only be installed on HTTPS to prevent attacks. Although it’s not impossible to be implemented on a HTTP site with a few work-arounds.
- Service workers should be supported by the browser
- Your website should be registered on the notification server like Google Cloud Messaging (GCM) which will return the API key.
There are also two ways you can shoot out push notifications:
- Do-It-Yourself (DIY)
- Plug-n-Play Services
This literally means do-EVERYTHING-yourself – from building the functionality to tracking & analytics. Here’s how it works:
- A user visits your website & recieves a pop-up seeking permission to display push notifications & you register a service worker (a script that will be executed when a push notification is received).
- If the user has clicked ‘Allow’ to grant permission, the service worker is registered along with her/his subscription id. You can read the device token which should be sent to the server & stored (you can have a table in your database to store user ids/ tokens with information like subscription/ unsubscription date).
- The subscription id identifies a particular device so that notifications are sent to the correct device
- When you wish to send a notification, the user ids are fetched from the application server & sent to the notification server which checks user-agent (device) for permission. If permission has been granted, the service worker sends a fetch request to the application server for the notification to be displayed.
- If the user unsubscribes, a request is sent to the push notification server which clears the user’s id from the database.
To know about the technical details on the integration, Google’s official doc on push notifications might be useful.
There’s a much simpler way of sending push notifications to your customers, though. You can easily opt in for a plug-n-play solution for your business for a low cost. Here are some options:
A user can always see the list of push notifications he has subscribed for and can manage subscriptions, even disable the ones he no longer requires. On Chrome, he can do this by Settings > Advanced settings > Content Settings > Notifications
Web push notifications can be customized to suit your brand tone, style & design.
To look like this:
We hope we were able to give you a brief introduction to web push notifications. Stay tuned for Part II of web push notifications where we will discuss the segmenting, best practices & more. Have something to share? We’d love to hear it in the comments section below.