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; when 100% reliability of delivery cannot be guaranteed, it neutralizes the benefits of 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.
The Architecture Behind Reliability Problems
It’s no mystery why an app needs to be assured of a 100% delivery rate of its push notifications. 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 notifications to be received near-instantaneously, and in the exact order they were sent. 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 is sent 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.
Another common problem with sending push tokens through cloud servers is that 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 was delivered
- Whether notification went to the lockscreen/notification center
- Whether notification was engaged with or ignored
- Whether 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 for notifications to be hyperpersonalized according to not only user interests and browsing history, but their work schedules, sleep habits, and daily activities.
Building off of their 100% deliverability guarantee, OpenBack’s platform is dedicated to providing 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.