How to Track App Uninstalls — And Whether You Can Find Out Who

There are three different questions hiding inside "how many people uninstalled", and every tool answers a different one — which is why your dashboards disagree before you have made a single mistake. Sorting them out first saves the argument later.

The three questions are: how many times was the app removed from a device, how many people stopped being users of the app, and which specific accounts left. Those are not versions of the same number. They have different denominators, different latencies, and — critically — different privacy ceilings. One of them is not answerable at all on iOS by design.

Most teams that ask us to "add uninstall tracking" want the third question — the named list — and the honest answer is that you can approximate it on Android, infer it lately and imperfectly on iOS, and never get it from either store's own analytics. Across the 300+ apps we have managed since 2013, resolving which question is being asked usually changes the brief more than any tooling decision that follows.

Everything below is taken from the platform documentation rather than from vendor marketing, because the vendor claims in this category are the least reliable part of the market. Where a figure is not published, we say so instead of estimating one.

Yes — App Store Connect reports a metric called Deletions, and it is far more specific than most teams realise. The widespread belief that Apple publishes nothing on uninstalls is out of date, but the metric comes with conditions that decide how you may use it.

Apple's app usage metrics define Deletions as the number of times your app was deleted on devices running a minimum of iOS 12.3, macOS 11, tvOS 9 or visionOS 1. The definition then narrows twice. It includes deletions of the app from the Home Screen and deletions of the app through Manage Storage. And it states that data from resetting or erasing a device's content and settings is not included.

Read those clauses as a measurement contract. A user who wipes their phone and never reinstalls you is gone in every commercial sense, and they will not appear in Deletions. A user who clears you out of Manage Storage to free space — a deliberate storage decision rather than a rejection of your product — will. The metric measures a specific act, not the end of a relationship.

The second condition is bigger. Apple states that Analytics in App Store Connect provides usage data collected from users who have agreed to share their data, and that to protect user privacy, Analytics only shows data after a certain number of data points are available. So Deletions is a sample of consenting devices, not a census, and Apple does not publish the share of devices that consent. That means the absolute number is not comparable to your total install base, and any "uninstall rate" built by dividing one by the other is wrong. We do not print such a rate, because there is no published denominator that would make it honest.

Note also where Apple does not put uninstalls. Its app retention documentation defines retention purely as usage over time — the percentage of active devices that installed the app on the selected day and opened the app a certain number of days later — and adds that users who install your app but never open it do not qualify, and are not counted in the numerator or the denominator. Retention on iOS is silence-based. It never tells you whether the app is still installed.

Play reports device-level and user-level loss, and the user-level figure quietly treats thirty days of silence as equivalent to an uninstall. This single definition is behind more misread Play Console charts than anything else in the product.

Google's statistics definitions are explicit about it. User loss is defined as the number of users who uninstalled your app from all of their devices or stopped using any devices that your app is installed on for over 30 days. Device loss is the number of devices from which users uninstalled your app, and Google adds that this includes when a device has not been used in over 30 days, making them inactive and counting as deactivation.

The companion definitions follow the same logic. Installed audience is the number of users who have your app installed on at least one device and have used the device — though not necessarily your app — in the past 30 days. Install base is the number of active devices on which your app is installed, where an active device is one that has been turned on at least once in the past 30 days.

Three consequences fall out of that, and they are all counter-intuitive:

• A dead handset counts as a loss. Someone who upgrades their phone and abandons the old one generates a device loss with no uninstall action at all.
• Your app being ignored is not the trigger — the device being ignored is. Installed audience counts users who used the device, not the app. An app nobody has opened in six months still sits inside the installed audience so long as the phone is switched on.
• Loss is lagged by up to a month by construction. A user who leaves today can only be counted thirty days from now, so a loss spike always points at something that happened weeks earlier.

That last point is the one to hold on to when reading any Play chart during an incident. It is also why device installs and uninstalls can look arithmetically impossible next to each other, which we unpick separately in why Play Console shows more uninstalls than installs.

Because one counts a specific deletion act on a consenting sample of devices, and the other counts an inactivity state across a full population — so the two figures are not measuring the same event. No integration work will reconcile them, and attempting it is wasted effort.

Line the definitions up and the gap is structural rather than technical:

There is a reporting delay to account for too. Google's documentation on the aggregated Statistics reports states that data is captured daily and posted within 3 to 7 days in monthly CSV files, so the exported series and the console view will not agree on a given morning either.

The practical rule we apply in our portfolio is to never build a cross-platform uninstall metric at all. Track Deletions against Deletions on iOS, loss against loss on Android, and compare only the direction of travel across the two. Any single blended number you construct on top of these definitions is a fabrication, and it will be quoted back at you in a board meeting as though it were measured. The same discipline applies across the rest of your funnel, which we cover in our guide to mobile app funnel analytics.

On Android you can get close enough to act on, using push infrastructure. On iOS you can get a delayed, imperfect version of the same signal, and you cannot get it from analytics at all. Neither store will ever hand you a list, and the reason is deliberate rather than incidental.

Start with what is ruled out. Apple's Analytics data comes only from users who agreed to share it, and Apple states that to protect user privacy, Analytics only shows data after a certain number of data points are available. A store analytics product that suppresses small numbers by design will not be producing individual identities, now or later.

Android has one direct, documented event. Firebase's automatically collected events reference lists app_remove, logged when an application package is removed — uninstalled — from an Android device. Two constraints matter before you build reporting on it: the event is Android only, and it belongs to your analytics property rather than to your own backend, so it tells you a removal happened in your audience rather than delivering a user record into your CRM.

The mechanism that does reach your own systems is push. When your server sends to a registration token that no longer belongs to a live installation, the platform tells you, and that response is a per-token fact you own. It is the closest thing to named uninstall detection that exists, and the next two sections are about how far you can trust it.

Reliable enough to clean your database and size a cohort, not reliable enough to call an uninstall — and Firebase's own thresholds explain why. The gap between "undeliverable" and "uninstalled" is where teams get the number wrong.

Firebase's guidance on managing registration tokens gives you the definitive responses. It instructs you to detect invalid responses from FCM and respond by deleting from your system any registrations that are known to be invalid or have expired, and it names two: UNREGISTERED (HTTP 404) and INVALID_ARGUMENT (HTTP 400). If you are certain that the message payload is valid and you receive either of these responses for a targeted registration, it is safe to delete your record of this registration.

Safe to delete the record. Not proof that the app was removed. Firebase separately defines staleness in time rather than in intent: stale registrations are associated with inactive devices that have not connected to FCM for over a month, and by default FCM considers a registration to be stale if its app instance has not connected for a month. For Android, when a registration has been inactive for 270 days, FCM considers it expired and garbage collects it.

Those numbers are Firebase's, and they are the only ones in this article that describe uninstall detection directly. There is no published figure for what share of dead tokens correspond to genuine uninstalls, so we do not print one — a device that has been off for six weeks, a user who revoked notification permission, a reinstall that minted a fresh token, and a genuine deletion can all land in the same bucket.

Firebase also tells you how to keep the signal timely. It recommends updating tokens on a schedule, noting that an update frequency of once per month strikes a good balance between battery impact and detecting inactive registration tokens. Without that refresh, the freshness of your uninstall cohort is whatever your send cadence happens to be, which for most apps means the signal arrives late and unevenly. If your sends themselves are unreliable you will misread all of this, and our piece on why Android push is not being delivered covers that failure mode first.

APNs returns a 410 with a reason of Unregistered and — unusually — a timestamp saying when the token stopped being valid, which makes it the most precisely dated uninstall proxy available on either platform. Most teams throw that timestamp away.

Apple's documentation on handling notification responses from APNs defines status code 410 as meaning the device token is no longer active for the topic. Two reason strings sit under it. Unregistered means the device token is inactive for the specified topic, and Apple adds that there is no need to send further pushes to the same device token unless your application retrieves the same device token again. ExpiredToken means the device token has expired.

The valuable part is the response body. Apple documents a timestamp field as the time, represented in milliseconds since Epoch, at which APNs confirmed the token was no longer valid for the topic — and states that this key is included only when the error in the status field is 410. That is a dated event, not merely a flag, so you can place a lapse on a timeline against a release, a paywall change or a permission prompt change instead of only knowing that it happened at some point before your last send.

Apple is equally clear on what not to do with the other failures. Status 400 with BadDeviceToken means the specified device token is invalid, and to verify that the request contains a valid token and that the token matches the environment — a sandbox-versus-production mismatch, in other words, which is a bug on your side and not a user leaving. Apple instructs that you should not retry notification responses with the error codes BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered or PayloadTooLarge.

Treat those two groups separately in your pipeline. 410 with a timestamp is a user-lifecycle signal worth storing. 400 BadDeviceToken is an engineering defect that will otherwise inflate your uninstall figure with your own configuration errors — which we have seen do exactly that on more than one app in our portfolio before anyone questioned the chart.

Store the raw platform responses with their dates, keep the platforms separate, and label every series by the definition that produced it. The build is short; the discipline is what makes it survive scrutiny.

What we deliberately leave out is a benchmark. There is no primary source that publishes a defensible cross-app uninstall rate, and every figure circulating in the market is either a vendor's own panel or an unattributed number that has been copied enough times to look official. We will not print one. Where genuine published figures exist for the adjacent question of retention, we have collected them in our app retention benchmarks.

Use it to date a cause and to size a win-back audience — not to grade the product, which it is too noisy and too laggy to do. The value of uninstall data is almost entirely diagnostic.

Dating a cause is the strongest use. If iOS 410 timestamps cluster in the days after a specific build, you have a version-level suspect and a much smaller search space than "retention is down". If Play user loss rises with no corresponding movement in device installs, ask whether a cohort of devices simply went quiet — a market where people change handsets, or a seasonal audience — before treating it as rejection. The same reasoning applies in reverse: an uninstall figure that does not move after a bad release is not reassurance, because both platforms' definitions delay the bad news.

Sizing a win-back audience is the second use, with one hard constraint. On Android an undeliverable token means you have lost your push channel to that person, so the campaign has to run over email, SMS or paid re-engagement instead. Building a push-based win-back for users you identified through push failure is a loop that cannot close, and we have watched teams ship it. Our guide to re-engagement and win-back covers the channels that remain, and choosing a push service matters here because your provider decides whether these raw responses are exposed to you at all.

What the number should never become is a target. It measures an act you cannot observe reliably, on a sample you cannot size, with a lag you cannot remove. The metrics worth managing sit upstream of it — activation, early sessions, the first week — and those you can measure honestly.

If your uninstall reporting is producing a number nobody can explain — or you need someone to say plainly which parts of it are measurable — that is a short conversation with someone who has taken these definitions apart before. Tell us what your two consoles are showing, or see how we treat measurement as its own workstream in our analytics work.