ASO · Retention & ranking
You fixed your keywords. You redid the screenshots. Installs went up — and then rank quietly slid back down anyway. Here's the part of ASO that happens after the install, and what the stores actually say about it versus what the industry just assumes.
Most ASO advice stops at the install. Get the metadata right, get the creative right, get the install. But both app stores keep watching after that moment — what someone does in the days that follow — and that behavior appears to feed back into whether your app keeps showing up in search at all.
This matters because it changes what "winning" at ASO looks like. An app that's excellent at generating installs but bad at keeping people can look successful on a download chart while actually losing ground in search, for reasons that have nothing to do with keywords or screenshots.
Think about it from the store's side. Every time Apple or Google puts your app in front of someone — a search result, a browse placement — they're making an implicit recommendation. If a large share of the people who take that recommendation immediately regret it (uninstall fast, never open it again, hit a crash), that's a cost to the store, not just to you. A search result that reliably disappoints erodes trust in search itself.
So it's a reasonable expectation that both platforms would want some signal of "did this recommendation actually work out" feeding back into future recommendations. The open question — and where a lot of confident-sounding ASO advice overreaches — is exactly how that feedback works, how much it's officially confirmed, and how much is informed guesswork from people watching rank move around.
Apple's own developer documentation on App Store discoverability states that search ranking is influenced by text relevance (title, keywords, category matches) and "customer behavior" — specifically downloads and the quality/volume of ratings and reviews. That's the confirmed list. Uninstall rate and session frequency are not named in that page.
At the same time, Apple's own App Store Connect Analytics documentation is explicit that retention — the share of devices still opening your app N days after install — is "one of the most important indicators of long-term app health," and gives you a full day-by-day retention table to track it. Apple clearly measures this internally and clearly wants developers to care about it. What Apple's public documentation does not do is explicitly connect that retention number to search ranking.
Directionally true, unverified: that uninstall rate and session frequency feed into ranking is widely believed across the ASO industry and consistent with how rank has been observed to move in practice, but it is not something Apple has published as a confirmed, named ranking input.
Google is more explicit, at least about one specific mechanism. Play Console's Android vitals documentation defines "bad behavior thresholds" for crash rate and ANR (App Not Responding) rate, checked against a rolling 28-day average, and states plainly: if your app exceeds a bad-behavior threshold, "Play may reduce the visibility of your title" — including excluding it from some discovery surfaces and, in worse cases, showing users a warning directly on your store listing.
The published overall thresholds are a 1.09% user-perceived crash rate and a 0.47% user-perceived ANR rate, with a stricter 8% per-device threshold for either metric on any single phone model. Cross either line and Google's own documentation says your visibility drops — that's about as close to a directly confirmed engagement-adjacent ranking mechanism as either platform publishes.
Google's broader guidance also treats "retention and usage statistics" as part of what it evaluates for app quality, alongside downloads and reviews, per the same discoverability-adjacent documentation — though, as with Apple, the exact weighting isn't published.
This is where the confirmed trail runs out fastest. Neither company publishes a specific session-frequency threshold, or a formula connecting "opens per week" to rank. What both platforms do confirm is that they collect this data — Apple's Analytics dashboard surfaces Active Devices and Sessions as standard metrics, and Google's Play Console exposes engagement data through its own vitals and statistics views — which tells you the raw material for a session-based ranking signal clearly exists on both sides, even without either company stating it's used that way.
The practical reading: treat session frequency as a metric worth improving for its own sake — a habit-forming app is a healthier business regardless of ASO — rather than as a lever you can pull with confidence expecting a specific rank response. The crash-rate threshold is the one place you can make that connection with real confidence; the rest is reasonable inference.
One plausible reason, though this itself is inference rather than a stated fact: Google's crash/ANR framing is really a technical-quality gate dressed in ranking language — it's closer to "don't ship something broken" than "here's how to climb the charts," which is an easier, lower-controversy thing for a platform to publish. A fuller statement of exactly how retention or session behavior weighs into search rank would invite exactly the kind of gaming attempts covered in a companion piece on black hat ASO tactics — which may be reason enough for both companies to stay vague on the specifics even if they use the signal internally.
Search around and you'll find specific claims — "uninstalls within 24 hours trigger suppression," "engagement is 35% of the algorithm," "a February 2025 update weighted 60-day retention more heavily." These read as authoritative, but they trace back to third-party ASO tool vendors and marketing blogs making inferences from observed rank movement, not to anything Apple or Google has published. That doesn't make them wrong — some of it is probably a reasonable read of real patterns — but it's a different category of claim than Google's own stated crash-rate threshold, and worth treating that way.
Illustrative model synthesized from Apple's and Google's own documentation on discoverability, App Analytics retention tracking, and Android vitals visibility rules — not an official diagram from either company.
Red bars: Google's real, published Android vitals bad-behavior thresholds (source linked below). Green bars: the illustrative Loopline example's September figures, for comparison only — not real store data.
Illustrative example — not a real app or real store data.
Picture Loopline, a habit-tracking app. In March, Loopline runs a paid push that drives 40,000 installs in a month. Day-1 retention lands at 22%, day-7 at 9% — people try it once, most don't come back. Crash rate sits at 1.6% (above Google's published 1.09% threshold). Rank for its core keyword sits around position 38 and doesn't move despite the volume.
In September, Loopline fixes onboarding and squashes its worst crash bug. Same paid budget, but this time: 25,000 installs, day-1 retention at 38%, day-7 at 19%, crash rate down to 0.6%. Fewer installs — and rank for the same keyword climbs to position 14.
| Metric | March (higher volume) | September (lower volume) |
|---|---|---|
| Installs | 40,000 | 25,000 |
| Day-1 retention | 22% | 38% |
| Day-7 retention | 9% | 19% |
| Crash rate | 1.6% | 0.6% |
| Keyword rank | ~38 | ~14 |
Nothing about Loopline's keywords or screenshots changed between the two periods. The only real-world confirmed mechanism in that improvement is the crash-rate drop crossing back under Google's published visibility threshold — everything else in the rank change is plausible but not something either company has confirmed as causal, which is exactly the distinction this article keeps drawing.
Enter your numbers. The crash/ANR comparison uses Google's real published thresholds; the retention comparison uses rough industry-observed ranges as a sanity check, not an official benchmark.
0 of 5 checked
You don't need to watch these numbers daily, and doing so mostly just adds noise — day-to-day retention and crash figures bounce around on small sample sizes, especially for a smaller app. A more useful rhythm: check crash/ANR rate weekly, since Google's own threshold check runs on a rolling 28-day window and a single bad release can drag that average down fast if it sits unnoticed. Check retention monthly, since day-7 and day-30 cohorts need time to actually mature before the number means anything — checking more often than that mostly shows you incomplete cohorts, not a real trend.
Treating install volume as the finish line. It's the start of the part that seems to matter most for durable rank.
Assuming every ASO blog's specific percentage is an official algorithm weight. Most of the precise-sounding numbers online are informed inference from third parties, not disclosed by Apple or Google — worth using as a rough compass, not gospel.
Ignoring Android vitals because "it's a technical metric, not an ASO one." It's the one place Google has explicitly, publicly tied a technical-quality number to reduced visibility.
Fixing retention with cosmetic changes instead of the actual first-session experience. A push notification nudge doesn't fix a broken onboarding flow that's already lost the user.
Confirmed: Google explicitly reduces visibility for apps that cross published crash-rate (1.09%) and ANR-rate (0.47%) thresholds. Apple confirms it tracks retention as a core health metric but doesn't name it as a ranking input. Everything more specific than that — exact uninstall-rate windows, exact algorithm weightings — is informed industry belief, not documented fact. Either way, the practical move is the same: treat what happens in the first week after install as seriously as you treat your keywords.
Sources: Apple App Store Discoverability · Apple App Store Connect — Measure App Retention · Google Play Console — Android Vitals