If you enjoyed the post you just read, we have more to say!
web push notifications
Last updated on
The number of smartphone users has surpassed 6 billion worldwide in 2021. This is projected to increase to more than 7.5 billion worldwide users by 2026 as entry-level smartphones become more affordable. As more and more essential services move to smartphones, consumers have little choice if they want to take advantage of services such as mobile shopping, mobile banking, and more.
In June 2009, Apple launched Apple Push Notification Service (APNS) for its smartphones. Other developers followed suit, and eventually, push notifications became a ubiquitous part of the smartphone experience. Push notifications have become a powerful marketing tool to acquire and retain users. To understand the value of push notifications, let’s take a look at the differences between push notifications and pull notifications, how push notifications work, and their benefits.
For any notification system, there are two components:
When the end-user has to enter the client application and request specific information to receive notifications and other information, it is a pull-based notification system. These notifications can also be initiated by software clients. Pull notifications work similarly to HTTP requests sent using web browsers. The connection between the application server and the client application is not always open. Pull notifications are most often used for non-urgent notifications such as non-critical software updates and communications.
In a push notification system, the information is sent to the end-user once the information is generated. The end-user does not need to actively seek the information to receive the push notification; it is delivered straight to the device. It appears with a notification banner in the notification tray according to the user’s device and operating system. The connection between the application server and the client application is always open.
Push notifications are widely used in smartphone applications. Smartphone operating systems have their own notification systems that developers can make use of, which is known as the Operating System Push Notification Service (OSPNS). iOS and Android operating systems have their own OSPNS that the developers can use to deliver push notifications.
App publishers need to build their applications (application server and client app) with OSPNSs enabled that can connect with iOS and/or Android smartphones. To get access to the respective operating systems’ OSPNS, the app publisher has to register with the push notification service for each OS. After registering, developers then receive access to the API to communicate with the OSPNS. The push notification capability is packaged with the code for the client application and the instance on the app server.
Once the end-user installs the client application from the app store of the respective operating system, the app and device are registered with OSPNS with a unique ID. This can be used by the app publisher to tailor services and push notifications to different users.
To send a notification, the app publisher can choose to create each message manually and push it to the client app or use the OSPNS API to send automated messages. The developer can also create an elaborate workflow to create tailored messages to individual users according to different parameters. These parameters could include user demographics, subscription status, time of the day, usage pattern, location, etc. App publishers have a lot of flexibility in the ways they can use push notification systems.
Users have an average of 80 applications installed on their smartphones. Among the 80 applications, users interact with an average of 9 apps daily and 30 apps monthly. This means users don’t access the majority of the applications installed on their devices regularly. Push notifications are a powerful tool for engaging in permission-based marketing.
Some of the core benefits of push notifications include:
The scope of using push notifications to engage, convert, and retain customers is endless. It is only limited by the creativity and marketing acumen of the product team.
While there are many benefits of push notifications, it’s crucial that developers get notifications right to prevent customer churn. Too many notifications can lead to alert fatigue, and 61% to 78% of users delete applications that send them too many. The likelihood that users will delete apps that send too many messages varies by generation. Millennials are most likely to delete apps that send too many notifications (78%), and Baby Boomers are least likely to delete apps that send too many (61%). Generation Z falls somewhere in the middle, with 67% of Gen Z-ers deleting applications that send too many notifications.
On the other hand, too few notifications can have the same effect, with 95% of new app users likely to churn if they don’t receive any notifications at all within the first 90 days. Developers must find the right balance of notifications – by segmenting users, sending timely notifications, and creating a personalized experience – to keep users engaged while avoiding alert fatigue.
Push notifications are a great tool, but the transitory nature of these notifications makes it difficult to make the messages ‘stick’ with end-users. Smartphones let users view mobile notifications from the lock screen or the operating system’s notification center, and from there, users can dismiss the messages directly. The push notification from your application could be buried among the hundreds of messages from all the different applications on the users’ devices. This minimizes the effectiveness of push notifications.
To counter that, developers can provide an easily accessible inbox with the app, where all the push notifications sent can be accessed. Inbox symbols with the number of unread messages can be used to prompt the user to open the inbox and view the unread push notifications.
Building push notifications with a notification inbox is a complex task that can take up valuable development time that could be spent on core application functionalities. Services like MagicBell can be used to implement a custom, complete notification system with an inbox within 15 minutes.