How to Reduce App Uninstalls and Improve 30-Day Retention

The fastest way to reduce uninstalls on Google Play is to work the same numbers Google uses to judge retention: keep user loss rate below 5%, keep DAU/MAU above 8%, and stay under the core vitals thresholds of 1.09% user-perceived crashes and 0.47% user-perceived ANRs overall. Fix in the order your own Play Console data points, not in the order a generic checklist suggests.

One thing to establish before you act: Play's "user loss" figure is not a pure uninstall count. Google defines it as users who uninstalled your app from all of their devices or stopped using any device it was installed on for over 30 days. An uninstall spike can therefore be device turnover in your markets rather than rejection of your app.

This guide explains what each metric actually measures, why a fix takes roughly a month to appear, which intervention moves which number, and what Play Console still cannot tell you.

What Google Play counts as a loss (and what it doesn't)

Play Console publishes its metric definitions, and they matter more than most developers realise. Google's View app statistics help page defines user loss 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 (making them inactive, and counting as deactivation)."

So three different events land in the same bucket: a deliberate uninstall, a phone put in a drawer, and a handset that broke. Loss rate is then "the ratio of User loss (people who have uninstalled your app from all of their devices) to Installed Audience (people who have your app installed on at least one device that has been turned on in the last 30 days)."

Two practical consequences:

• A rising loss count in a growing app tells you nothing on its own. The denominator is your whole install base, so raw losses grow with age. Read the rate, not the count.
• Before you rebuild anything, split the number by the Loss mechanism dimension in Statistics and look at "Uninstalls" specifically. If that line is flat while total user loss climbs, you are looking at inactivity, not rejection — and the fix is re-engagement or market analysis, not a code change.

Google also exposes device loss after update: "the number of devices from which your app was uninstalled after the app has recently been updated." That is the metric that tells you whether a specific release drove people away.

The numbers Play uses to judge your retention

Google publishes explicit thresholds for two of them and publishes bad behaviour thresholds for the stability metrics that push users to leave. Every figure below comes from Google's own documentation, linked in the Sources section.

Metric	Where it lives	Google's threshold	If you miss it
User loss rate	Android vitals > Core value; Statistics > Users	Below 5%	"A warning may be shown on your store listing, and your app may not be eligible to appear on certain surfaces on Google Play."
DAU / MAU	Android vitals > Core value	Above 8%	Same warning and surface-eligibility consequences
User-perceived crash rate	Android vitals > Core vitals	1.09% overall, 8% per phone model	Play may reduce visibility of your app; a warning may appear on the listing
User-perceived ANR rate	Android vitals > Core vitals	0.47% overall, 8% per phone model	Same as crash rate
Data needed for user metrics	Play details page treatments	—	Google needs enough users "over a minimum of 24 days in a 30 day period" before it can assess the metric at all

The per-model column is the one that catches people. Your overall crash rate can sit at 0.5% while one popular handset is at 9%, and Google states it will "steer users on those devices away from these titles." This is also why our own test runs use a spread of Samsung, Pixel, Xiaomi and OnePlus devices across Android 11–15 in 80+ countries rather than a single reference phone: behaviour genuinely differs by model, and the per-model threshold is where that shows up.

Why your fix takes about a month to show

Google is unusually specific about the evaluation window: "Play checks your app's key performance indicators daily, using a 28-day average. When this average improves, Android vitals warnings disappear. Store listing warnings may be removed faster if Play's system detects improvement."

Read that as a planning rule. On the day you ship a fix, the bad days are still inside the 28-day window, so the metric barely moves — then it improves a little each day as the bad days roll out of the average. A fix shipped today takes close to four weeks to be fully reflected, and rolling back and re-shipping every few days resets your own progress.

Two details worth knowing:

• Android vitals flags "emerging issues" after a problem has affected devices for over seven days for crashes and ANRs, which Google frames as giving you 21 days to address them.
• Vitals data is available for the previous 90 days in Play Console and for three years through the Play Developer Reporting API. If you only look at the default window, you cannot tell a spike from a plateau.

Match each retention fix to the metric it moves

Retention advice usually arrives as a list of features. It is more useful as a mapping: here is the problem, here is the number that proves it, here is the intervention Google itself points to.

Crashes and ANRs: the cheapest uninstalls to prevent

A crash is the one moment when your app actively confirms a user's decision to delete it. Fixing the largest crash and ANR clusters first moves three things at once: the core vitals thresholds above, the user loss rate, and the discoverability penalty attached to bad behaviour. Google's own guidance is to "fix the crashes and ANRs affecting the most users" and, on specific devices, the biggest groups on those devices. Our Android vitals guide covers how to read each metric and which threshold to triage against.

App size: Play may suggest your app for uninstallation

This is the most under-appreciated retention lever on the platform, and Google states it plainly: "Google Play proactively helps users free up device storage by suggesting apps to uninstall, and will prioritize app size when formulating these recommendations." Play Console's own engagement guide lists the practical version of this as "Reduce uninstall metrics by optimizing your app size."

Concretely: ship the app bundle rather than a universal APK so each user downloads only what their device needs, use Play Feature Delivery and Play Asset Delivery for large modules, and audit uncompressed resources and duplicate assets in every release. Google adds that "not all users have reliable or affordable network access, or available device storage" — so minimising update size also determines whether your improvements reach users at all.

A risky release: watch device loss after update

If user loss jumps within a few days of a rollout and the device loss after update line moves with it, you are looking at a regression, not a slow drift in product value. Check the correlation before you change anything else: open Statistics, compare the update date against device loss after update, and identify the release. The response is a hotfix or a paused rollout, not a new onboarding flow. For a larger app, staged rollout gives you the same read on a fraction of the audience before the whole base is exposed.

Low repeat usage: get DAU/MAU above 8%

DAU/MAU below 8% attracts the same store listing warning as a high loss rate, because Google reads it as low core value: people who installed are not coming back. The levers here are product rhythm rather than code — new content on a predictable cadence, time-limited events (Google's engagement guide explicitly recommends live-ops as a long-term strategy), sensible notification prompts, and deep links that take users straight to the content they came for.

This metric also gates revenue. A subscription or ads-based app with weak repeat usage has nothing to monetise, which is why retention work usually has to precede the model changes in our Android monetisation breakdown rather than follow them.

Expectation mismatch: fix the first day, not the thirtieth

Some uninstalls happen hours after install, when the app turns out to be different from the listing. Play Console cannot isolate that cohort for you — see the next section — but the diagnosis is usually visible in reviews and in the drop between store listing visitors and installers. Google's engagement guide points at the tools that help: custom store listings for specific user groups, the in-app review API to ask at a moment of demonstrated value, and replying to reviews (Google states that "on average, users update their rating by +0.7 stars when developers respond to their feedback"). An accurate title, honest screenshots and a short, specific description prevent more uninstalls than any post-install prompt.

What Play Console cannot tell you about retention

Honest limits save you from optimising the wrong number.

• There is no day-1 / day-7 / day-30 cohort report in today's Play Console. Google's acquisition and retention help page documents the old cohort report as "no longer available in Play Console as of November 2, 2020", and the current user-base documentation does not restore a day-N retention view. Cohort retention has to come from your own analytics SDK; Play gives you loss, loss rate and DAU/MAU instead. (For subscriptions, Google does publish a subscription retention report.) This is our reading of the current documentation, not a Google statement.
• Loss is not uninstall. Because 30 days of device silence counts as loss, markets with older handsets, secondary phones or high device turnover will show worse loss rates than markets with the same behaviour and newer hardware. Do not benchmark your loss rate against an app with a different device economy.
• Small apps are under-powered. Google warns that when there is not enough data, "your app doesn't have enough data points within the specified filters to identify any issues." Below a few thousand active users, expect wide swings and resist reacting to weekly noise.
• A closed test cannot measure retention. In the 1,500+ closed-testing campaigns in our records, the pre-launch window is far too short and far too small — a dozen testers over 14 days — to say anything about 30-day retention. Treat the closed test as a stability and compliance gate, not a retention signal. Based on our own campaign records and analysis, not Google data.

A four-week sequence that follows the data

1. Week 0 — establish the baseline. Record user loss rate, DAU/MAU, crash and ANR rates, and app size versus peers. Note the date. Everything later is compared to this snapshot.
2. Week 0 — split the loss number. Break user loss down by Loss mechanism and by country. If inactivity dominates, skip the code fixes and go to engagement; if uninstalls dominate, continue.
3. Week 1 — clear the stability thresholds. Fix the largest crash and ANR clusters, prioritising the per-model problems. This is the only step with a published threshold attached.
4. Week 1–2 — cut size. Move to the bundle, drop unused assets, and shrink the update. Google ties app size directly to its own uninstall suggestions.
5. Week 2–4 — do not touch anything else. Because Play evaluates a 28-day average, one change per window is what makes the result readable. Ship, annotate the release date, and wait for the average to move.

What you see in Play Console	Likely cause	Metric that should move after the fix
Crash rate near or above 1.09%, one model at 9%	Device-specific instability	Crash rate (overall and per model), then user loss rate
Loss rises within days of a release	Regression in the new version	Device loss after update
Total loss up, "Uninstalls" mechanism flat	30-day device inactivity, not rejection	User loss (re-engagement), DAU/MAU
DAU/MAU stuck below 8%	No reason to return within a 28-day window	DAU/MAU
Loss concentrated on low-storage devices	App too large; Play's uninstall suggestions	User loss rate, app size versus peers

Frequently Asked Questions

What is a good user loss rate on Google Play?

Google's published threshold is 5%. Its wording is that if your user loss rate "exceeds Play's threshold of 5%, a warning may be shown on your store listing, and your app may not be eligible to appear on certain surfaces on Google Play." Below 5% you are inside the bar Google states; Google does not publish a stricter target than that, and any "industry average" quoted elsewhere is not a Google figure.

How long does it take for a retention fix to show up in Play Console?

About four weeks for metrics evaluated on a 28-day average. Google checks key performance indicators daily, so each day the improved data replaces an older bad day. Store listing warnings "may be removed faster if Play's system detects improvement", so those can clear before the underlying vitals average fully recovers.

Do uninstalls affect my app's visibility on Google Play?

Indirectly, yes. A user loss rate above 5% or DAU/MAU below 8% can produce a store listing warning and make the app ineligible for certain Play surfaces. Separately, exceeding the core vitals bad behaviour thresholds (1.09% crashes, 0.47% ANRs overall) means Play "may reduce the visibility of your title". These are two different systems with two different metrics.

Where do I find uninstall data in Play Console?

Statistics > Users > user loss and loss rate, with the Loss mechanism dimension to separate true uninstalls from inactivity; Devices > device loss after update for release-related churn; Android vitals > Core value for the user loss rate and DAU/MAU thresholds. All three are described on Google's View app statistics page.

Is Play's uninstall number the same as the one in my analytics tool?

No. Play's user loss includes users who stopped using the device for over 30 days and only counts users who removed the app from every device, while analytics SDKs count package removals from their own population and installation source. Expect the numbers to disagree, and always compare a Play metric to the same Play metric over time rather than to a third-party figure.

What should I fix first if I can only fix one thing?

Stability, if you are near a bad behaviour threshold — it is the only area with published numbers and a documented visibility consequence. If your stability is already clean, fix size: Google ties app size directly to the storage-cleanup prompts that recommend uninstalling apps. Engagement work comes after those two, because it needs the longest window to show.

Sources

• Monitor your app's technical quality with Android vitals — Play Console Help
• View app statistics — Play Console Help
• User metrics on Google Play — Android Developers
• Android vitals — Android Developers
• What great technical quality looks like — Android Developers
• Engage and retain your users — Google Play Console
• Measure your app's acquisition and retention — Play Console Help
• Understand and grow your app's user base — Play Console Help

All policy claims above were checked against these Google pages in October 2026. Campaign observations are TesterBee's own analysis of its records and are labelled as such.