2.Why is my app not getting downloads?

In this chapter: a plain map of the path from "someone sees your app" to "you get paid", using the platforms' own definitions. You will find the step that actually changed, and list what you cannot see — before anyone, including you, starts guessing.

The problem

If your app is not getting downloads, first separate too few people reaching it from people reaching it but not choosing it. If downloads are steady but revenue is flat, follow the next steps of the funnel instead. Rewriting a listing cannot fix every step.

A quick diagnosis before you change anything

Pick one market and comparable dates. Keep observations separate from explanations. A listing review can help you inspect the public message, but it cannot supply your private traffic or revenue figures.

"Growth is flat" is not a diagnosis. Flat revenue can come from fewer people finding the app, fewer visitors downloading, fewer new users getting to the point where the app is useful, fewer trial users paying, more subscribers cancelling, or a payment failure. Each of those has a different fix, and most fixes for one step do nothing for the others.

Indie developers often look at the step they are most comfortable with. Designers look at screenshots. Engineers look at crashes. Marketers look at keywords. The result is a lot of work on a step that was never broken.

What is going on

The funnel, one step at a time

Think of five steps. Each step has a count and, between steps, a rate.

1. Seen. People see your app somewhere in the store: search results, browse lists, a product page.
   • App Store: an impression is counted when your app is viewed for more than one second in the Today, Games, Apps or Search tabs; product page views are included [S05].
   • Google Play: Play Console reports store listing visitors — unique users who visited your listing without already having the app installed on any device [S12]. The default report includes new and returning users, and a user is counted once per day per dimension, so this is not simply "product page views by new people" and does not map directly to Apple's impressions.
2. Downloaded. People install.
   • App Store: first-time downloads and redownloads are separate; total downloads is their sum [S05]. Apple's conversion rate is total downloads and pre-orders divided by unique-device impressions [S05] — so it includes redownloads and it starts from "seen", not from "visited the page".
   • Google Play: the page says that from June 2026 primary metrics are based on unique clicks and that from July 2026 store listing reports focus on intent clicks on Install, Open or Pre-register [S12]. The click-through rate (clicking visitors ÷ store listing visitors) replaces the older "conversion rate". A click is intent, not a finished install. The older acquisition figures are still available in Play Console's Statistics page and CSV exports [S12].
3. Activated. New users reach the moment the app is useful to them: the first journal entry, the first budget, the first completed workout. No store console measures this for you. It lives in your own analytics, backend or database — if you have it.
4. Paying. Users start paying: a purchase, a subscription, or a trial that converts. On the App Store, paying users are unique Apple Accounts that paid for the app or an in-app purchase, and proceeds are the estimated amount you receive after taxes and Apple's commission [S05]. Subscription apps also have introductory offers such as free trials; a customer can redeem one introductory offer per subscription group [S09].
5. Staying. Users keep paying or keep coming back: renewals, retention, repeat purchases. Store consoles offer some of this (for example Apple's subscription cohort views [S09]); much of it requires your own data or a subscription analytics tool.

Read the rates, not only the counts

A count can fall because the step before it fell. If fewer people see the app, fewer people download it even if your product page is as persuasive as ever. So for each step, ask two questions:

• Did the count change?
• Did the rate from the previous step change?

If the count fell and the rate held, the problem is upstream. If the rate fell, look at that step.

The step you cannot see is still a step

Every developer has blind spots. Common ones:

• You have no analytics inside the app, so step 3 is invisible.
• App Store Connect usage figures only include users who opted in to share data with developers [S05]. They describe that group, not everyone.
• Your subscription tool shows revenue for a whole project that contains several apps.
• You changed the price and the paywall in the same release.

A blind spot is not a reason to guess. It is a line on your missing-data map: which step, what you would need to see it, how long it would take to get, and whether the decision can wait.

Definitions change, and charts do not warn you

Consoles rename and redefine metrics. Google Play's June/July 2026 change from "conversion rate" to click-through rate [S12] is a recent example: a chart that spans the change can show a step that no user caused. Before you compare two periods, confirm that the metric meant the same thing in both — and where the platform keeps the old metric (Play still offers store listing acquisitions in Statistics and exports [S12]), use it to keep one continuous series.

Worked example

Fictional example · E2 · Brightmoss · tags: android, measurement-change, no-intervention

Situation. Brightmoss is an Android flashcards app for language learners, built by two developers. Goal: more paying users. In early August they look at Play Console and see that the headline rate on their store listing report is noticeably higher than in May. One of them wants to credit the new feature graphic uploaded on 1 July; the other wants to put the saved effort into a paywall redesign.

Step-by-step funnel check (Play Console, all countries, May vs August):

Observations. Visitors, store listing acquisitions (the continuous series), first opens and trials were stable. The "improvement" on the listing report coincides with Play replacing an outcome metric (acquisitions) with an intent metric (clicks) [S12]. Paid starts fell.

Hypotheses.

1. The feature graphic improved the listing. Not supported: store listing acquisitions and first opens did not rise.
2. The listing rate rose because the definition changed. Supported by the platform's own note.
3. Something between trial and payment got worse. Plausible; it is the only step where the rate moved.
4. Noise. With 71–88 paid starts per month, a swing of 17 is not large. As a rough guide — assuming independent sign-ups and a stable underlying rate — two monthly counts around 80 can differ by about ±25 (roughly three times the square root of 80) from chance alone (chapter 8 explains the rule). This is a sanity check, not a significance test.

Missing-data map entry. Trial-to-paid by trial start week is not tracked; the team only has monthly totals. They cannot tell whether the drop is concentrated in one week (a bug, a billing issue) or spread evenly (noise, a seasonal pattern).

Decision: Check, then wait. Do not credit the feature graphic, do not redesign the paywall. Keep the continuous series from store listing acquisitions in Statistics and exports [S12], and start a new baseline only for the click-through chart. Add a weekly "trials started → paid" cohort to the backend (about one hour of work). Revisit in four weeks; move to chapter 5's diagnostic tree only if the weekly cohort rate stays below May's monthly trial-to-paid rate (88 ÷ ~530 trials, about 17%) for three consecutive weeks.

Do this now

1. Draw your five steps for one app, one market: seen, downloaded, activated, paying, staying.
2. For each step, write where the number comes from (console, your backend, a subscription tool) and its exact definition. Copy the definition from the platform's help page, not from memory.
3. Fill the last two comparable periods for counts and rates. Use the same length and, if you can, the same weekdays.
4. Mark the first step whose rate changed. That is where you look next. If none changed, the problem is upstream of your data (seasonality, the market) or it is noise.
5. List your blind spots on the missing-data map: step, what's missing, how to get it, effort, and whether the current decision can wait for it.
6. Check for definition changes in the period: console notes, SDK updates, a new analytics event name.

Don't change anything yet when…

• The first changed rate is in a step you cannot see — fill that gap first.
• A console renamed or redefined the metric inside your comparison window.
• Counts are small enough that your normal range covers the change.
• Several steps moved together in a way one event could explain (a release, an outage, a holiday).
• You would need to change more than one step at once to act on your theory.

Worksheet

Missing-data map — the five steps, their sources and definitions, the rates for two periods, and a list of blind spots with effort and urgency.

Optional: Next Move works from public listing data only, so it cannot see steps 3–5 either; when a move depends on them it says so and suggests a check instead. That is the same rule this chapter asks you to follow.

Sources

• S05 — Metric definitions, App Store Connect Analytics (Apple Developer Help) — https://developer.apple.com/help/app-store-connect-analytics/reference/metrics-definitions/
• S09 — Auto-renewable subscriptions (Apple Developer) — https://developer.apple.com/app-store/subscriptions/
• S12 — Acquisition reports, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9859173