FAQ: Why some of your users are not receiving the push notifications?

August 19, 2016 - 9 minutes read

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?

The probable reasons that we have observed over time from our experience as well as literature present for why the deliverability is affected are as below:

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 user’s device.

Device specific issues: Some devices like Xiaomi are known to not receive notifications when apps are not running either in 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 failure rate to be around 98% – 99% i.e. we can only deliver to 1 out of 100 devices.

User Not connected to GCM due to Network issues: A lot of customers are not connected to 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% 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

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

Gap from GCM in marking token as in-active: There is gap between the time device is uninstalled and GCM marking the device as in-active. 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 app on user device but it won’t be delivered.

Other Issues: Many a times in corporate setups, outer firewall reject 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. (One can check another blog here mentioning similar problem and suggested 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 received the notifications were not active for past 4 weeks.

Bottomline: Though we were not able to establish direct causality, we can see high correlation here. As 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 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 whole campaign is impacted.

Another device series are 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 substantial share (particulars vary as per genre and demographics of client apps) of installed customer base and hence lowering down the 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 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.

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 absence of data.

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

Facebooktwittergoogle_plusredditlinkedinmailTags: , ,