Downloads dropped — what to actually check

“Downloads dropped” isn’t one cause

ASO Lens’s diagnosis logic (src/core/diagnosis/diagnose.ts) doesn’t treat a change in downloads as a single metric — it breaks the App Store acquisition funnel into stages and identifies which stage actually changed. That classification is typed as BottleneckStage (src/core/types.ts): exposure, interest, download, and revenue. Every comparison here is the app against its own immediately preceding period — never an external industry-average benchmark (this is stated explicitly in src/core/diagnosis/thresholds.ts).

Exposure: fewer impressions

ASO Lens’s primary classification logic flags the exposure stage as the bottleneck (Case B) when unique impressions have dropped significantly versus the previous period, or sit at a structurally low absolute level. The finding in that case points at keywords, localization, and keyword ranking— the levers that affect whether the app shows up in search or browse listings at all.

There are also finer-grained findings about the impression source mix (App Store Search / App Store Browse / App Referrer / Web Referrer) in src/core/diagnosis/signals/sourceQuality.ts. For example, if App Store Search’s share of total impressions has dropped significantly versus the previous period, that’s treated as a possible sign of declining keyword ranking or search visibility. Conversely, if Browse accounts for a large share of impressions and its conversion rate is clearly lower than Search’s, that’s flagged as “Browse traffic converting poorly” — not itself an ASO failure, but a reason to treat Search’s numbers as the more reliable signal. And if App/Web referrer traffic makes up a large share, there’s a separate finding noting that ASO changes will only move a minority of your traffic.

Download: people who saw the page stopped installing

When impressions are flat or up but Apple Conversion Rate (impressions → downloads) has dropped significantly versus the previous period, or sits at a structurally low absolute level, the diagnosis logic flags the download stage as the bottleneck (Case A). The finding here points at the product page itself — icon, screenshots, and title/subtitle — ahead of keywords.

A more specific finding exists for Page Download Rate — the share of product-page visitors who go on to download (src/core/diagnosis/signals/pageToDownload.ts). Because App Store lets users download directly from a search result without opening the product page, this rate can exceed 1.0, so there is no absolute “too low” threshold for it — it is compared only against the app’s own previous period, never as a standalone benchmark.

Interest: fewer people opened the page

For sources like App Store Browse, when Page View Rate — the share of impressions from that source that actually led to opening the product page — drops significantly versus the previous period, or sits at a low absolute level, an interest-stage finding fires (src/core/diagnosis/signals/exposureToPageView.ts). That finding points at the icon, screenshots, and subtitle — the elements that determine whether someone taps through from a listing. For App Store Search specifically, the equivalent conversion (search results → product page) is folded into the download-stage Case A classification described above, rather than handled separately.

Cross-referencing releases

Separately from the primary stage classification, ASO Lens compares a trailing window of recent days within the period against the earlier days in that same period, checking whether impressions or downloads have suddenly dropped or spiked (src/core/diagnosis/signals/recentShift.ts). When it finds such a shift and an app version release falls within that recent window, it notes the release’s version and date alongside the finding. This is not a claim that the release caused the shift — the code’s own comments describe it explicitly as a correlation worth checking, not a causation claim. A sudden drop is surfaced as info-level context prompting a check of the change log; a sudden spike is surfaced the same way, noting it may reflect featuring or seasonality — neither is presented as a confident conclusion.

Separating seasonality and overall trend

As noted above, every comparison ASO Lens makes is the app against its own immediately preceding period — never a fixed external industry benchmark. That doesn’t automatically strip out seasonality, but grounding every comparison in the app’s own history (rather than “how do you compare to other apps”) avoids importing a misleading external reference point. The trailing-window shift detector described above works the same way: it compares “recent” days against “earlier” days within the same period, which is again a relative comparison within the same app. There is no dedicated seasonality-detection logic — when a sudden spike or drop is found, the finding simply notes that featuring or seasonality may be a possible explanation, as context rather than a determination.

Summary

When downloads drop, the first question is which stage it happened at: fewer impressions (exposure), a shift in where those impressions come from or how well they convert, fewer people opening the page after seeing it (interest), or fewer people downloading after opening the page (download). ASO Lens’s diagnosis logic separates these using only the app’s own history as the baseline, and surfaces any release that falls within a detected recent shift as context to check — never as a settled cause. Going from “downloads dropped” to “what to actually fix” requires exactly this kind of stage-by-stage separation.