Why Play Console Shows More Uninstalls Than Installs

Because Play Console applies a strict definition to what counts as gaining a user and a loose one to what counts as losing them — and because a device that simply goes quiet is counted as a loss. The lines can cross on a perfectly healthy app, and in a mature app with a large install base they eventually will.

The asymmetry is structural, not accidental. A gain has to be a genuinely new user. A loss can be a phone that was replaced, reset, or left in a drawer. Those are not comparable events, and the chart plots them against each other anyway.

There is also a base-rate effect that makes this inevitable over time. New installs are a flow that depends on your marketing this month. Losses are drawn from an install base accumulated over years. An app with 500,000 installed devices and 2,000 new installs a day does not need anything to go wrong for daily losses to exceed daily gains — it only needs a small fraction of a large accumulated base to retire their handsets.

In our portfolio this chart causes more unnecessary alarm than any other single number in Play Console, and it is nearly always raised by someone reading it for the first time before a board meeting. The correct response is to read the definitions, which Google publishes, and then to look at the metrics that actually answer the question being asked.

Not just uninstalls — Google's own definitions fold long inactivity into both of its loss metrics, which means "uninstalls" on your chart include people who never uninstalled anything. This is the single fact that resolves the whole question, and it is stated plainly in Google's documentation.

From Google's page on viewing app statistics, quoted exactly:

• User loss is "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. This includes when a device has not been used in over 30 days".

Read those clauses again. A user who buys a new phone and leaves the old one in a drawer generates a device loss on the old handset. A user whose phone breaks generates a loss. A second, rarely-used tablet that goes a month without being switched on generates a loss. In none of those cases did anyone decide to remove your app.

The same definitional logic runs through the install base: it 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". Play's whole model treats a device that has not checked in for a month as gone. That is a defensible modelling choice — it just is not the same thing as an uninstall, despite what the chart label implies.

Because the metric on the other side of the chart deliberately excludes anyone who already had your app on another device — so returning users and second devices count on the loss side but not on the gain side. The two lines are not symmetrical measures of the same population.

Google defines user acquisitions as "the number of users who installed your app and did not have it installed on any other devices at the time". That exclusion is doing a lot of work. The person who installs your app on a new phone while still having it on their tablet is not an acquisition. If the tablet later goes quiet for a month, that is a loss.

Compare it with the more permissive metric alongside it. Install events are "the number of times your app was installed, including devices on which the app had been installed previously" — reinstalls included. This is why teams comparing Play Console against an ad platform get different answers even before attribution enters the picture, a problem we cover in detail in our piece on why Meta and your MMP report different installs.

Put those two columns side by side and the crossing lines stop being mysterious. You are watching a narrow definition of gain plotted against a broad definition of loss.

Yes — Google improved its inactivity detection, and told developers directly that this would increase reported uninstall and device loss figures. If your loss numbers stepped up without a matching product change, a methodology change is a real candidate and worth ruling out before you go looking for a cause in your app.

Google's page on understanding recent changes to report metrics is explicit about the direction of the effect. On users, it notes you may see an increase because Google can now more accurately pinpoint when a user becomes inactive. On devices, it says you may see an increase because a greater number of signals are used to generate a more accurate measure. The stated basis is that active devices are those that have checked in with Google at least once in the past 30 days.

Better detection of inactivity means more inactivity detected. The underlying behaviour of your users did not change; Google's ability to observe it did.

Google's troubleshooting page for app statistics is worth knowing about for the same reason. It documents a series of historical corrections and outages — including a systems change in mid-2022 that caused missed data across installs, acquisitions and engagement metrics, with some of it unrecoverable, and a period where some app updates were being counted as device installs before the calculation was changed.

The practical rule that follows: before investigating a step change in any Play Console metric, check whether Google changed how it was measured. We have watched teams spend a fortnight hunting a retention regression that was a reporting change, and the check that would have saved them takes five minutes.

Because Apple measures retention rather than loss, and reports no uninstall metric — which means the comparison you are trying to make across platforms does not exist. Founders regularly ask why their iOS uninstall rate looks so much better than Android. It does not look better; it is not reported.

Apple's App Store Connect analytics documentation on app retention defines the metric it does provide: retention "tells you the percentage of active devices that installed the app on the selected day and opened the app a certain number of days later". Day 1 retention is the percentage that opened your app one day after installation, and so on.

One exclusion in that definition is worth holding on to, because it is the mirror image of Play's approach. Apple states that users who install your app but never open it "do not qualify, and are not counted in the numerator or the denominator of the calculation". Play counts that device in its install base until it goes quiet. Apple removes it from the retention calculation entirely.

So the two platforms are not reporting the same thing in different formats — they are answering different questions. Play asks how many devices still have the app. Apple asks what share of people who opened it came back. Both are useful. Neither converts into the other, and any cross-platform "uninstall rate" comparison you build is comparing a measured number against an inferred one.

By watching push tokens die — which means they detect an app that can no longer receive messages, not an app that was definitively removed. Third-party uninstall tracking is an inference from a delivery failure, and understanding that tells you exactly where it is unreliable.

The mechanism rests on push infrastructure. Firebase's documentation on managing registration tokens describes the signals available: a send request targeting an invalid or expired registration returns UNREGISTERED (HTTP 404) or INVALID_ARGUMENT (HTTP 400). A tool that pings tokens periodically and records which ones stop accepting messages can build an uninstall figure from that.

Three limitations follow directly, and they are the reason your MMP and Play Console will never agree either:

• It is a poll, not an event. Detection happens on the next check, so there is an inherent lag between the uninstall and the record of it.
• It cannot distinguish removal from other causes of a dead token. A token can stop working for reasons other than uninstallation.
• Inactivity gets folded in here too. Firebase notes that by default it considers a registration stale if its app instance has not connected for a month, and that any registration older than one month is likely to be an inactive device.

That last point is the striking one. Play Console treats 30 days of silence as a loss. Firebase treats roughly a month of silence as a stale registration. Two independent systems have reached the same conclusion — that after about a month of no contact, the difference between "gone" and "quiet" stops being worth modelling. Your uninstall number, from whichever source, is really a "no longer reachable" number.

Two of them are measurable inside Play Console itself — storage pressure and app size, and technical quality — which makes them the right place to start because you can prove or dismiss them without guessing. The broader question of why users leave is a product one; this section is about the causes Google will show you directly.

Storage and size. Google's guidance on optimising your app's size states outright that "App size is an important aspect of technical quality that can affect your app's install and uninstall metrics". More usefully, Play Console reports "Active devices with <2GB free" and "Uninstalls on devices with <2GB free" as distinct figures. If the second is disproportionate to the first, storage pressure is a real cause for your app rather than a theory about apps in general.

Google also documents the size threshold that changes the install experience: above 200MB, users on a mobile data connection see a non-blocking dialog when installing from Google Play informing them of the app's large size. That is friction at the moment of acquisition, applied to exactly the users least able to absorb it.

Technical quality. Google's bad behaviour thresholds are published numbers: a user-perceived crash rate of at least 1.09% of daily users across all device models, and a user-perceived ANR rate of at least 0.47% of daily active users, with an 8% threshold for a single device model in both cases. Exceeding them makes an app likely to be less discoverable on Google Play, and a warning may be displayed on the store listing. We cover what to do about that in our piece on the vitals thresholds that decide distribution.

Deliberately absent from this section: the widely-repeated figures linking each additional megabyte to a specific percentage increase in uninstalls, and the various "X% of users uninstall within 30 days" statistics. We traced the popular ones and could not reach a primary source for any of them. The direction is well supported by Google's own statement above; the specific numbers in circulation are not, so we do not print them.

Retention of the cohort you acquired, not the net line between gains and losses — because the net line is dominated by the size and age of your install base rather than by anything you did this month. Switching which number you watch is the actual fix here.

Across the 300+ apps we have managed since 2013, the teams with a real handle on churn are the ones tracking cohort retention weekly and treating the Play Console loss chart as context rather than as a KPI. The teams in trouble are usually reporting the net line to a board, which produces panic in mature apps and false comfort in young ones — a young app has almost no accumulated base to lose from, so its net line looks wonderful right up until it does not.

When the loss rate moves rather than the loss count, when early-life uninstalls climb, or when a release date lines up with the change. Everything else on this page is definitional; this section is the short list of things that should actually worry you.

• The rate changed. Losses as a share of install base moving materially, with no methodology change to explain it, is a real signal. Check Google's change and troubleshooting notes first, then look at your own releases.
• First-week uninstalls rose. This is the most actionable signal in the whole area, because it is about the experience you control most tightly. It usually points at onboarding, permissions asked too early, or a mismatch between what the store listing promised and what the app delivered.
• It starts on a release date. Line the loss chart up against your release history. A step change that begins the day a build rolled out is a regression, and vitals are the first place to look given the published thresholds above.
• Storage-pressure uninstalls are over-represented. If uninstalls on devices with under 2GB free are disproportionate to your active devices in that state, app size is worth engineering time rather than debate.

None of those is diagnosed from the net line. All of them are diagnosed from a rate, a cohort or a date. If your uninstall picture is moving and you cannot tell which of the four you have, that is a worthwhile conversation to have with someone who has seen the pattern before — tell us what the chart is doing, or read how we approach the retention side in our analytics work and our guide to re-engagement and winback.