Why Some Users Don’t Receive Push Notifications? [with Examples]

Reading Time: 6 minutes

Our customers have asked us this question time and again that why some of their users are not receiving the notifications sent by them. Why the notifications that are successfully sent to GCM were not delivered to the end-users?

Here are a few examples that we have observed over time,  on the issues surrounding push deliverability,

1. Notifications can be blocked by User at OS Level: Operating systems give users a choice to block the notification for a particular app. The problem with this implementation is that GCM won’t invalidate the token neither it informs the app-server about this temporary de-activation. Also, some battery-saving apps Force Stop the running apps which then won’t be able to deliver notifications to the user’s device.

2. Device-specific issues: Some devices like Xiaomi are known to not receive notifications when apps are not running either in the foreground or background. The manufacturers are coming up with fixes in the new updates but for older versions, the problem persists. For Mi & Lenovo 6000 series, we have found the failure rate to be around 98% – 99% i.e. we can only deliver to 1 out of 100 devices.

3. User Not connected to GCM due to Network issues: A lot of customers are not connected to the Internet for a long time and hence GCM cannot deliver notifications to them as well cannot mark them inactive. GCM works by maintaining an idle socket connection from an Android device to Google’s servers. To make sure that the connection remains active, Android will send a heartbeat every 28 minutes (which has recently changed to a dynamic value as per Google I/O 16) on mobile connection and every 15 minutes on Wifi (source). If this heartbeat is not received, the connection is considered broken and Google attempts to re-establish it.
Google suggested that in general nearly 15% of users are not connected to GCM and hence might not receive notifications at the right time. This, in turn, results in two problems:

1. Delay in messages
2. Non-delivery in case the user is still Out of Network

4. Time to Live expires before notification delivery: It might so happen that GCM was not able to connect with the device within the TTL time hence GCM won’t deliver the notification if the TTL is expired at the time of delivery.

5. The gap from GCM in marking token as in-active: There is a gap between the time device is uninstalled and GCM marking the device as inactive. Verbatim from Google’s documentation is: “Note that it might take a while for the registration token to be completely removed from GCM. Thus it is possible that messages sent to GCM get a valid message ID as a response, even though the message will not be delivered to the client app.” As a result, we might successfully send the notification to GCM without knowing the install status of an app on user device but it won’t be delivered.

Other Issues: Many times incorporate setups, outer firewall rejects the incoming packets due to security settings. The solution suggested is of blocking of certain ports but we aren’t sure if that is the right solution or in the first place if that is the right problem as we were not able to establish the causality ourselves. (You can check another blog here about a similar problem where we have suggested a solution)

Seeing this becoming a perennial problem, we deep-dived into our data to see what it speaks. Unlike many other vendors, we not only track sent numbers but also capture the notification impressions from client’s devices. Hence understanding the gap was easier for us. We ran an analysis across our clients and divided our analysis into two themes:

User Activity – To understand if there is a correlation between the user activity (how recently your user visited your app) and notification deliverability
User Device – To understand if there is a correlation between device model (Mobile device used by your users) and notification deliverability

User Activity

We identified that out of all the notifications sent to all Users and that were successfully accepted by GCM but were not actually delivered to users, the break-up was as below. Around 84% of the people who did not receive the notifications were not active for the past 4 weeks.

Bottom line: Though we were not able to establish direct causality, we can see a high correlation here. As the duration of inactivity increases, reachability decreases i.e. GCM might not be able to reach and deliver notifications to these users.

We ran the same analysis for users who actually received these notifications which also indicated that recency increases reachability. Of all the people who successfully received the notifications, around 73% were seen active in the past 2 weeks.

User Devices

We also had a hypothesis that some of the device models, most of the times do not receive notifications sent by our clients. This hypothesis stemmed from our past experience of debugging device-specific issues for our clients. (Note here the dedication of our customer support to understand client issues). We ran the numbers across multiple campaigns for few clients and the result was certainly worth the dig.

Failure rates for Mi Devices namely Mi4i, Mi3W, Mi4W,Redmi Note, Redmi Note 2, Redmi Note 3, Redmi Note 4G, Redmi 1S were consistently as high as 97%-99% .

Given that device share for Mi devices in total user base is also high across clients, the deliverability of the whole campaign is impacted.

Another device series is Lenovo A6020 and Lenovo A6000 where the failure rates were also dismally high around 98%-99%. Micromax also exhibited high failure rates around 90-95% for its canvas series.

ASUS Z00AD, Z010D, Z008D, Z00UD, Z00LD devices also had delivery rates lesser than 4%. We also identified that Vivo devices (namely Y11, Y15S, Y27L, Y28, Y57L, V1) along with Iris X8 & Iris Fuel 50 also have very low delivery rates ranging from 2-3%.

All these devices have a substantial share (particulars vary as per genre and demographics of client apps) of installed customer base and hence lowering down the push delivery rate as a whole.

Motorola and Android Marshmallow: Some of our users are also facing problems on Android Marshmallow devices because of battery optimization introduced by Google with Android M i.e. not deliver the notification when the device is idle. In Motorola phones, doze mode detects when your device is not in use and it will automatically go into a deep sleep state which saves your battery. App Standby reduces the battery drain of your phone by putting your seldom-used apps into a reduced activity state which then hamper the notification delivery.

If you have also observed any such reasons, do let us know.

(Solved: See how MoEngage Push Amplification can help deliver notifications to these users to increase engagement and conversions)

Note: The analysis below covers the Android platform. Once we hand-over our notifications to GCM Server and they successfully accept the message for a particular user, our servers don’t have visibility on the reasons why it was not delivered. The next hop is a black box for all the developers. Hence the reasons below are just hypotheses which we cannot validate in the absence of data.

Delivery Rate = (Impressions Received)*100/ (Total Sent)
Failure Rate = 100% – Delivery Rate

Want to know how brands like Bigbasket, Travelz, and Oyo Rooms use MoEngage Push Amplification to improve their push notification delivery rates? Learn more about push amplification here.