Our customers have asked us this question time and again about 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 presented for why the deliverability is affected, are as below:

1. 1. 1. Notifications can be blocked by the 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 nor it inform 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 as 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 a mobile connection and every 15 minutes on Wifi. 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. 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 the app on the user's device but it won’t be delivered.
         
         
      6. Other Issues: Many times in corporate setups, the outer firewall rejects the incoming packets due to security settings. The solution suggested is of blocking 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 a similar problem and suggested solution)

Push benchmark report

Here is the benchmark report for Push campaigns that can help you to understand the trend for the standard metrics like Delivery rate, CTR, and CVR. 

Data from Q3'2020 [1st Jul 2020 - 30th Sep 2020]. Last updated on 2nd Nov 2020

With push deliverability 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 clients' devices. Hence understanding the gap was easier for us. We ran an analysis across our clients and divided our analysis into two themes:

1. User Activity - To understand if there is a correlation between the user activity (how recently your user visited your app) and notification deliverability
2. 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:  

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 received these notifications which also indicated that recency increases reachability.

User Devices

We also had a hypothesis that some of the device models, most of the time 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 a 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, and Redmi 1S were consistently as high as 97%-99% and device share for Mi devices in total user base is also high across clients. 

Other 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, and Z00LD devices also had delivery rates lesser than 4%. We also identified that Vivo devices (namely Y11, Y15S, Y27L, Y28, Y57L, and 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 the installed customer base and hence lowering 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 delivering 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 hampers 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 that we cannot validate in absence of data.

Why users received a simple text Push instead of a Rich Push notification?

It might sometimes happen that even if you configured a Rich push notification i.e. added an image/Gif/video to your Push notification, still some of the users only received a text notification but didn't receive the rich content. There are a few reasons why it could happen:

1. The image size was too big and hence it failed to download while rendering the notification. Recommended image size is 25KB with a 2:1 Aspect ratio
2. The image was well under the recommended guidelines i.e. <= 25KB, but still, it failed. This could happen because of slow internet issues on the user's device. Under such circumstances, the text would get loaded but the image might still fail due to poor network. 

As per the above-stated scenarios, whenever the image download fails, the user will see a "text only" notification.