5.Downloads but no paying users: what to check

In this chapter: how to tell whether "fewer paying users" is an acquisition problem, an activation problem, a paywall problem or a payment problem — using the data you actually have. You will build a diagnostic tree that never asks you to judge a paywall nobody can see.

The problem

Revenue is the number that hurts most when it falls, so it attracts the most dramatic fixes: a new paywall design, a new price, a new trial length, a lifetime option. These are among the hardest changes to evaluate and to reverse. Existing subscribers see prices change, reviews mention it, and every later comparison has a before-and-after split running through it.

Many revenue drops are not paywall problems at all. Fewer people arrived. Fewer new users got far enough into the app to see the paywall. A payment step failed after a release. Or the people arriving were different — returning users, a new country, a new traffic source — and behaved differently.

What is going on

Four places revenue can break

Think of them in this order, because each one limits the next. In practice, check the payment step for errors first — it is quick, and a broken payment step can look like any of the others — then walk from acquisition down:

1. Acquisition — how many new people start using the app. Covered in chapters 2–4.
2. Activation — how many of them reach the moment the app is useful and, in most apps, the moment they are shown an offer.
3. Paywall — of those who see the offer, how many start a purchase or trial.
4. Payment and renewal — of those who start, how many complete payment, convert from trial to paid, and keep paying.

The counts multiply. If acquisition fell 20% and everything else held, paying users fall about 20% and the paywall is innocent.

Which data sees which step

Two rules follow:

• If you do not log "paywall shown", you cannot evaluate the paywall. You can only evaluate the whole path from install to purchase. Add the event before you redesign anything.
• No one outside your app can evaluate your paywall either. A public store page does not show it. Any tool, consultant or template that "reviews your paywall" from the listing is guessing. Next Move follows the same rule: from public data alone it can point at acquisition or positioning questions, and for revenue questions it asks for a check that needs your private data.

Composition changes are a common hidden cause

The people who arrive can change without the count changing. Examples:

• More returning users (redownloads) after a feature in a newsletter. On the App Store, a customer can redeem one introductory offer per subscription group [S09], so many returning users are not eligible for your free trial and will see a different offer.
• A new country where prices are relatively higher or purchasing habits differ.
• A new traffic source — a community post or an ad — bringing curious visitors rather than people with the problem your app solves.

Before you blame the paywall, split the paying-user drop by first-time vs returning, by country and by source.

Payment problems look like persuasion problems

If a release broke the purchase flow for some devices, the paywall "converts worse" — but no design change will fix it. Chapter 6 covers how to connect a release, error evidence and a business metric. That is why the diagnostic tree starts with payment errors, before anything else.

Platform rules to keep in mind

On the App Store, unlocking features, subscriptions or premium content inside the app generally has to use in-app purchase [S06]. Apple's current §3.1.1(a) also permits specified external-purchase links; entitlement and storefront conditions apply, and US storefront apps have a broader no-entitlement rule for buttons, external links and calls to action [S06]. Check the current guideline text for your case before you plan a pricing experiment that depends on an external checkout.

Worked example

Fictional example · E5 · Pantrio · tags: ios, monetization

Situation. Pantrio is a meal-planning app with a monthly subscription and a 7-day free trial, available on iOS and Android, built by a solo developer. In August, new paying subscribers on iOS fell to 96 from about 130 in each of the previous three months. Android was stable. The developer is preparing a new paywall with an annual plan up front.

Walking the tree (iOS, August vs May–July average):

Observation. The drop is in trial starts, and it coincides with a jump in returning users. A food blog had featured Pantrio in early August, and many readers were former users.

Hypotheses.

1. The paywall became less persuasive. Weak: nothing on it changed, and Android — same design — is stable.
2. Returning users see no free trial, because they already used their introductory offer in this subscription group [S09], and fewer of them subscribe at full price. Plausible and checkable.
3. Seasonality. Possible; summer months were not lower last year, though.

Check performed (45 minutes). The developer split trial starts by whether the device had installed the app before (own backend flag). First-time users started trials at the same rate as in May–July. Returning users started almost none — consistent with not seeing the trial.

Decision: No paywall redesign. Note the August drop as a composition effect from one referral, not a paywall regression. Keep the planned annual-plan idea on the list for a proper test later (chapter 4 rules apply to paywalls too). Separately, consider an offer aimed at returning users — for example, Apple's win-back or promotional offer types [S09] — as its own small test with its own measurement card (chapter 8), after checking eligibility rules in the current documentation.

Do this now

1. Write your four counts for the last full period: new users, activated users, users shown the offer, paying users. Mark any you cannot fill.
2. Add the missing events before any redesign: "paywall shown", "purchase started", "purchase completed", "purchase failed" with an error reason.
3. Split the paying-user change by first-time vs returning, by country and by source.
4. Check payment errors around your last release (chapter 6) before you judge persuasion.
5. Compare platforms if you have both. A drop on one platform with the same paywall on the other points away from the paywall's design — though platforms differ in audience, prices and offer rules, so it is a hint, not a control group.
6. Only then write a paywall or pricing test brief (chapter 4), with a stop rule and a plan for existing subscribers.

Don't change anything yet when…

• You do not log paywall views; you would be changing a step you cannot measure.
• Acquisition or activation changed in the same period.
• The mix of users (returning, country, source) changed.
• A release in the same period touched the purchase flow and you have not checked errors.
• Your monthly count of new paying users is small enough that the change is inside its normal range (chapter 8 has a rough check).
• The change would affect existing subscribers and you have not decided how to treat them.

Worksheet

Monetization diagnostic tree — the four steps in order, the data source for each, and the branch you end up on, including "can't tell yet — add this event".

Optional: if your goal is paying users, Next Move can look at your public listing for positioning issues that affect who arrives. It will not claim anything about your paywall, trial or payment flow, because public data cannot see them.

Sources

• S05 — Metric definitions, App Store Connect Analytics (Apple Developer Help) — https://developer.apple.com/help/app-store-connect-analytics/reference/metrics-definitions/
• S06 — App Review Guidelines (Apple Developer) — https://developer.apple.com/app-store/review/guidelines/
• S09 — Auto-renewable subscriptions (Apple Developer) — https://developer.apple.com/app-store/subscriptions/