How Castled doubled our Push Delivery Rates

Back

Product Update

https://castled-strapi.s3.us-east-1.amazonaws.com/push_boost_3_8a1de919f1.png

Franklin George

Jun 1, 2024

2 mins read

Mobile push is one of the most commonly used engagement channel by our customers. Last month alone, we have send over 100 million push messages on behalf of our customers. Push is cost-effective and also offer open/click rates in the range 4-7% on average. But one of the challenges in push is getting good delivery rates. This is a problem especially on Android devices, because you have all these different OEMs and they tweak (usually the cheaper ones) the default Android OS behavior to eke out better battery/cpu performance on relatively cheaper hardware.

Android by default uses firebase send notifications to apps and it expects apps to be in non terminated state so that it can deliver the push message and in turn for the notification to show up in device notification tray. One effect of these optimizations in cheaper OEMs is that the apps are proactively terminated when it is sent to background (user no longer interacts with the app) and this hinders the ability of firebase services to deliver the push to the app and thus leading to poor push delivery rates on such devices.

For our customers a 1% improvement in delivery rates typically means an ability to reach an additional 10K+ users, so at Castled we have spent quite some time chasing these issues and also coming up with some workarounds so that our customers get the max delivery rates for their push campaigns.

Following are some of our learnings and workarounds that we currently employ. In some cases we were able to push (no pun intended :)) our delivery rates to over 90% following these approaches.

Pull Mode - This is an approach complementary to firebase delivery. Here the app polls a server periodically for any new push messages not yet delivered by firebase. The polling task is usually scheduled using Android job scheduler. Downside of this approach is notifications are not very real-time and a bit of work is involved in implementing the polling framework if implementing yourself (both server and app side).
Inbox - This can be considered as a separate channel altogether. But we have a few customers using this alongside push. Basically there will be a notification center within your app and every push message sent to your app will also land here. So user can catch up on any push messages that firebase missed whenever he opens the app next time. Persistence of push messages is an added benefit, but this approach mainly caters to your active user base.
Timeouts in Data Push Messages - When sending push messages as a data payload using firebase(typically the case when sending rich push notifications) , make sure your app push handler you have registered with firebase, processes and renders the notification in less than 10 seconds, this might seem a long time, but in reality we have seen quite a lot of devices not able to handle push within this time due to poor network connections or app startup taking more time due to some resource constraints, so if push processing detects a slowness fall back to rendering the basic notification.
Direct integration with OEM specific push providers - Chinese OEMs like Xiaomi, Huawei has their own push framework which provides better delivery rates than firebase on their devices. We have done integrations directly with these providers, but overall their SDKs are poorly maintained, docs not up to date and a pain to work with. Also Xiaomi recently announced they are stopping their push service (MiPush) outside of mainland China out of the blue. But if you have significant number of users on these devices, this is worth exploring.
OEM specific settings - Also to increase chances of receiving push messages for your app, there are some device specific recommendations that you can make to your app users. https://dontkillmyapp.com is a great resource for these recommendations. Basically the idea is to prevent non-stock Android OS es from killing your app by making app users opt-out of battery optimizations, enabling-auto start, etc. Your app has greater chance of receiving push if not killed by the OS