Reliability in Push Notifications: An Industry-Wide Challenge
To the end user, push notifications may not seem noticeably different from marketing communications via SMS or email. However, from a mobile app’s end, push notifications are an enormous improvement in terms of reliability and sophistication to SMS. Notifications are highly personalizable, incorporate rich media, and when done correctly deliverable in real-time. However, a common challenge among traditional push notification SDKs is that of reliability. Without 100% guaranteed reliability of delivery, there is no benefit to using push in the first place. If you’re having problems with deliverability, you may be asking yourself, “Why is my push notification not getting through?” There could be a few reasons behind that, as we will see.
Calculate how much your revenue would increase per month using OpenBack:
The Architecture Behind Reliability Problems
It’s no mystery why 100% delivery rate of an app’s push notifications is a necessity in this day and age. Particularly with apps that provide time-sensitive information or services – say, a travel app that needs to give users real-time updates of their flight schedules, or a news app that needs to get breaking news out – reliability is paramount. Even when it comes to sending out run-of-the-mill information, any sort of marketing campaign or series of messages requires near-instantaneous delivery of notifications. What’s more, user-end delivery needs to occur in the exact order that notifications leave the server. Otherwise, the information they convey may become jumbled, or outdated, making them a nuisance.
To understand why reliability is a real issue for push notifications, it’s first crucial to understand how the industry works. In the traditional model, there are three key players:
- The app
- App backend servers
- Third-party cloud servers: APNs (iOS) and Google Firebase (Android)
When a user installs an app on their device, that app registers its push token – a unique string of characters that allows gateways to route messages – with the iOS (APNs) or Android (Firebase) cloud servers. Once the push notification SDK is activated, it goes inside the app, collects the push token, sends it to be stored in the notification system, and then sends it onward to APNs or Firebase. The cloud server will then determine the moment to send the push token back to the app as a notification.
Most of the time, this method is sufficient in getting notifications to their designated devices in the right order, and in a timely manner. However, with so much ping-ponging of the push token, the shortcomings are clear: any method that is built around the inclusion of a middleman is by definition not going to function at peak efficiency.
Common Problems of Sending Push Tokens to a Cloud Server
Once the push token goes to the cloud server, the app has no control over what happens to it, or what time it goes out. So if the push token changes on the app’s side while it’s being stored in the cloud server, then it will have to re-register with the server, causing a delay. Similarly, data coming in from the device’s side to be processed in the server and function as triggers for notifications to be sent out again can also result in a time lag.
There is another common problem with sending push tokens through cloud servers. Your app will only receive a response from the server if your token was invalid. Other stats that are key for analyzing push campaigns, such as whether your notification actually made it to the device, are not communicated.
What’s more, on the side of the individual device, in order to receive notifications from a cloud server, the device radio needs to continuously wake up to check for notifications. This causes considerable battery drain, and device manufacturers have tried to introduce measures to preserve battery power. Unfortunately, these measures often interfere with reliable push notification delivery.
So what’s a mobile app to do?
How Does OpenBack Improve on This Method?
OpenBack breaks with the traditional structure of sending out push notifications by doing away with the necessity for cloud servers. OpenBack utilizes edge computing to leverage device-side data in real time, without ever having to transport it to a server. By keeping user data on the device, this not only cuts out a key contributor to delivery delays, but it also improves data security as well as compliance to data privacy regulations.
OpenBack’s direct-to-device process for sending notifications also provides comprehensive data analysis on your push campaign. They offer crucial feedback such as:
- Confirmation that your notification delivered
- Whether notification went to the lockscreen/notification center
- Whether notification was engaged with or ignored
- If a notification directly resulted in an uninstall
Instead of blasting out notifications as determined by APNS/FCM servers, OpenBack takes a more holistic approach. OpenBack use of device-side metrics and data triggers enables a more sophisticated analysis of when is the appropriate time to deliver a notification. Detailed segmenting functionalities allow you to hyperpersonalize notifications according to various different demographics, including:
- user interests and browsing history
- work schedules
- sleep habits
- daily activities
- past purchases
Building off of their 100% deliverability guarantee, OpenBack’s platform provides a more valuable notification experience for the customer, which will ultimately boost engagement with your app.
To learn more about OpenBack’s unique platform and their approach to superior reliability,
Or, contact one of our experts for more information.