Engineering

The secret sauce behind uninstall tracking

November 15, 2016

It takes a lot of effort to design, build and launch an app, and even more to acquire users. Unless you’re tracking app uninstalls, how would you know if you’re sailing in a leaky boat?

Is tracking App Uninstalls that important? ABSOLUTELY!

Here are the facts.

Did you know – 50% of all users who uninstall an app, do it within in the first 4 to 5 days?

app-uninstall-stats

Data statistics show that half of all uninstalls happen during the first few days. The way for a mobile to combat this issue is to track and discover the reasons why your user uninstalled your app and address them. What are the most common problems? They range from a bug in the latest version of the app, frequent crashes, or a UX problem on a particular phone model.

How are App Uninstalls detected?

You can detect app uninstalls by sending ‘silent’ push notifications. Silent push notifications are those notifications that aren’t rendered on the user’s device. You could send a silent push notification daily to all the devices with your app to track uninstalls.

Let’s review how Uninstall tracking typically works on each platform.

Detecting Android uninstalls

  • Send a silent push notification to the GCM (Google Cloud Messaging) server. Keep the push notification payload empty, as you don’t want the empty message to pop on the user’s device.
  • The GCM server will send a message or query the device.
  • The GCM client will receive the message and will query the Package Manager about whether there are broadcast receivers that are configured to receive it.
  • This message returns a false flag.
  • The GCM client will then inform the GCM server that the application has been uninstalled.
  • The GCM will return a “NotRegistered” error back which indicates that the application has been uninstalled.

app-uninstall-flow

Detecting iOS uninstalls

  • Detecting uninstalls on iOS is much simpler, as APNs (Apple Push Notification service) has a feedback Service where Apple reports any device token that is no longer active on the user’s device.
  • Send a blank push notification to the APNs keeping the payload empty.
  • The APNs Feedback Service allows you to discover device tokens that are no longer active.
  • As a developer, poll the APNs Feedback Service and detect which devices are invalid.
  • Once detected, these users can be marked as uninstalled.

 

Alternative ways to track app uninstalls

For Android

Send a daily ping from the device

In this case, you would run a service on the device and ping the server once daily (or every hour, if you’re super aggressive), to confirm that the app still exists on the device. This is a solution that works but is not elegant.

Here’s why you shouldn’t go with this approach –

  • Running a service permanently in the background will hog memory and users who do not like apps running in the background unnecessarily might uninstall the app.
  • Users are more comfortable with smartphones and now use smart task managers that can kill your service or never even let it run once they realize that it is not directly affecting your core offering. As an example, if it’s a calculator app, killing the background uninstall ping service has no effect on the ability of the app.
  • Another issue that might turn off certain users is that continually sending data will eat into their data plans.
  • Most low end devices which run low on memory will kill apps to give priority to foreground apps and priority services that are being run.

Using the ACTION_PACKAGE_REMOVED broadcast

You can register a receiver that will be invoked when the app is uninstalled but unfortunately the ACTION_PACKAGE_REMOVED intent will be sent out to all receivers except for your own broadcast receiver 🙁
Read how this works

Use FCM or GCM

  • The FCM will send an error saying “NotRegistered” when it figures out that the app is uninstalled – note that this might take a few hours to happen after the actual uninstall – typically this happens within the first 4 hours.
  • Please note – always register for a token once – doing it twice will cause unexpected behavior.
  • If you have registered the device with the same sender ID and use the corresponding server key to send the messages, it’s rare to see any issues regarding this approach in tracking uninstalls. However, if you don’t use sender ID corresponding to its GCM server key then you can have GCM report “NotRegistered”  and this can lead one to incorrectly deduce that the user has uninstalled.
  • Note – the general practice to register for tokens is the very first app launch, and then every time you upgrade the app.

For iOS

Send a daily ping from the device

On iOS, your app can in fact run in the background periodically. However, the cases for this are the frequency of app usage, and when the phone is charging. There, this is not really a viable option. You must also have a legitimate use case – uninstall tracking will probably not play well with Apple’s app review process.

Sending a silent iOS notification with content-available flag and have background mode enabled. In this mode you can communicate with your server to do a “ping,” however your app is not guaranteed to be woken up.

Send notifications

While sending push notifications using HTTP/2, you’ll get back a response.Error Code 410 This would indicate that the user uninstalled the app.

Other nuances related to tracking uninstalls

  • What happens if the user’s device is turned off or what if the user is unreachable when the person uninstalls the app?
    If GCM already knows that the app is uninstalled, it will return “NotRegistered. Else, it will queue the message for delivery. When the device comes back online, and the app is still installed, the message will be delivered. Else, if the app is uninstalled, GCM will now mark this token for deletion and subsequent notifications for this device will receive the “NotRegistered” response.

  • Do we know if they reinstall?
    Store your own generated persistent UID in the iOS keychain or Android key value backup, then use this to check when the user reinstalls the app.

 

How does CleverTap handle uninstalls

CleverTap’s Uninstall Tracking reaches out to hundreds of millions of devices on a daily basis to detect app uninstalls, and these numbers are reported on the Uninstall Dashboard. CleverTap does an uninstall sweep once a day for your entire user base. During this sweep, we reach out to users having a valid Push Token by sending a silent Push Notification.

Tracking and visualizing these numbers is easy through the CleverTap Uninstall Dashboard.

clevertap-uninstall-stats

Here, you can see Net Activations for a given time period. Net activations are new activations less the number of uninstalls in that period.

clevertap-uninstall-graph

When a client is running a campaign, we superimpose the campaigns on a graph. This tool will allow our clients to correlate these uninstall rates to marketing activities or app release cycles. This feature is very helpful in tracking or enhancing the campaign and figuring out how to increase user retention rates.

Both Android and iOS Notification APIs give feedback regarding an app uninstall. Whenever a user installs an application, unless they have notifications specifically disabled, they can receive Push Notifications on their mobile. These can take various forms. For example, a banking push notification tells you about any transactions or services you completed. A shopping app might send you a push notification when items you are watching are on sale, or about any offers.

The uninstall numbers on the CleverTap dashboard are based on the feedback we receive from the Notification APIs. To detect uninstalls, we send blank push notifications without a payload and based on the API response, CleverTap can deduce if the application has been uninstalled.

If you know, any other way of tracking uninstalls, or wanted to discuss anything related to push notifications or uninstalls, do leave a comment in the reply section.

,

4000

55 billion

1 billion

10 billion