Mobile App Onboarding Drop Off: Fix the Flow Before the Paywall

Most subscription app funnels I review have the same shape. Take a typical case: a language learning app where about 6 in 10 installs finish the 8 onboarding questions, 2 in 10 reach the paywall, and fewer than 2 in 100 start a trial. That is mobile app onboarding drop off in 1 chart, and it is the most common shape I see.

In a mobile app, onboarding and the paywall are 1 flow. The paywall converts or does not convert because of what happened in the 90 seconds before it. So I do not redesign paywalls on their own. I redesign the path from first open to first result to first price, as 1 user flow.

In this post I explain where app onboarding loses people, how to measure it, what a paywall needs to convert, how I redesign the flow in 3 weeks, and what to measure before and after.

Why mobile app onboarding drop off is different from web

On the web a new user arrives with intent. They searched for something, read a page, decided to sign up. In an app store the user tapped install because of 3 screenshots and a rating, and they open the app with almost no idea what it does. Onboarding has to build the intent that the web already had.

The second difference is patience. A web user gives a new product 3 to 5 minutes. An app user gives it about 90 seconds on the first open, on a phone, often while doing something else. Every screen between the first open and the first real result costs 5 to 15% of the remaining users.

The third difference is the platform. iOS and Android interrupt your flow with system dialogs for notifications, tracking and sign in. You do not control the dialog, only when it appears and what the user saw before it.

How to measure where the onboarding leaks

Before I touch a screen I want 8 events, in order: app opened, each onboarding step completed, permission dialog shown and answered, account created, first result reached, paywall shown, trial started, subscription paid. Most apps I audit have 3 of these. Adding the rest takes a developer 1 day, and we wait 2 weeks for a clean baseline.

Session recordings fill in the why. I watch 20 to 30 sessions of users who dropped before the paywall and 20 to 30 who closed it. Then I read 3 months of app store reviews and tag every 1 that mentions the trial, cancelling or "I did not know". Reviews are blunt in a way analytics never is.

The last input is retention. Day 1 and day 7 retention split by whether the user reached the first result. If users who reached the result retain 3 times better than users who did not, the activation moment is confirmed and everything in the flow should serve it.

The 4 places an app onboarding loses people

1. The question screens
Personalisation questionnaires are the most common onboarding pattern in consumer apps and the most common leak. 8 to 12 screens asking goals, age, level and reminders before the app has shown anything. I keep the 2 or 3 questions that change what the user sees next and move the rest to after the first result. If the answer does not change the next screen, it is not a question, it is a form.

2. Permission prompts
Notification and tracking prompts placed on screen 1 or 2 get refused by 60 to 80% of users, and on iOS you get 1 chance. I put a plain screen before the system dialog that says what the notification is for, with the real wording, and I place it after the moment the user has something worth being reminded about. Acceptance is usually much higher when the user knows what they are saying yes to.

3. Account creation
Asking for an email or a social login before the first result loses 20 to 40% of users, and most of them did not need an account yet. The app can store progress on the device and ask for an account when there is something to save. Apple and Google sign in reduce the friction, but the better fix is moving the step.

4. The paywall placement
This is the largest leak. The paywall appears at the end of the questionnaire, before the user has done 1 real thing in the app. Conversion at that point is typically 1 to 4%. When the same paywall appears after the first result, with a summary of what the user did, conversion is usually 2 to 3 times higher and refunds go down, because the people who paid know what they bought.

App paywall conversion design: what converts and what only annoys

A paywall is 1 screen with 1 decision, and cognitive load is the enemy. These are the things I check on every paywall I redesign.

1 recommended plan
3 plans in a row with the yearly plan highlighted is the standard, and it works only when the difference is obvious. I show the recommended plan first, with the price per month written the way the user thinks about it, and the alternative as a secondary choice. The user should be able to decide without reading a comparison table.

The trial explained in 1 line
When the trial starts, when it ends, what happens then, and how to cancel. Apps hide this because they fear it lowers conversion. In practice it usually does the opposite, because the user is less afraid of tapping.

The value from the last 90 seconds
The paywall should reference what the user just did. "You finished lesson 1" is stronger than any feature list. That is why paywall placement and paywall content are the same design problem.

A visible close button
A paywall that hides the close button for 5 seconds gets more accidental trials, more refunds and more 1 star reviews. A soft paywall, where the user can continue with a limited version, converts lower today and higher over 30 days.

States
Purchase pending, purchase failed, restore purchases, already subscribed on another device, trial expired. Most paywalls have 1 state designed and 5 states left to the payment library. Those 5 are where the support tickets come from.

A 10 point first pass you can run yourself

Delete the app, reinstall it, and go through it on your own phone with this list. It takes 30 minutes.

How many screens are there between first open and the first real result? Count them.
Which onboarding questions change what the user sees next? Which are only stored?
When does the notification prompt appear, and what did the user see right before it?
Is an account required before the first result?
Does the paywall appear before or after the first result?
Can a user say from the paywall alone when the trial ends and what it costs after?
How many plans are shown, and is 1 recommended?
Is the close button visible immediately?
What does the paywall show when the purchase fails or the user is already subscribed?
Do you know day 7 retention for users who reached the first result and for users who did not?

If the answer to question 5 is "before", start there. In most consumer apps I review it is the single change with the largest effect.

What to measure before and after

I set 1 primary metric and 3 secondary ones in week 1, before a wireframe exists.

The primary metric is install to trial started, or install to paid for apps without a trial. That is the number the redesign is judged on. It includes every step, so it cannot be gamed by moving the drop off from 1 screen to another.

The secondary metrics are activation rate, meaning install to first result, paywall shown to trial started, and day 7 retention. A paywall change that raises trials and lowers day 7 retention is a refund problem waiting 4 weeks.

We compare 30 days before with 30 days after on the same acquisition mix. App store experiments and remote config make a proper A/B test possible in apps with more than 20,000 installs a month, and I use them when the volume is there. Below that, a before and after comparison with a written baseline is enough for a decision. I explain the wider method in conversion rate optimization for digital products.

Where AI tools help and where they do not

They help with the volume work. Tagging 2,000 app store reviews by topic in 1 hour. Drafting 30 variants of paywall copy to react to. Summarizing 40 session recordings into a list of the screens where users paused.

They do not help with the sequence. An AI does not know that your users open the app on the metro with 1 hand, or that in your market a yearly plan is a large decision. It cannot watch a person hover over the close button for 4 seconds. The order of screens is the whole design, and that still comes from watching people.

Mistakes I see in mobile app onboarding drop off

Redesigning the paywall without moving it. A better looking paywall in the wrong position moves the number a little. The same paywall after the first result moves it a lot.

Copying the questionnaire pattern from a bigger app. That app has 50 million installs and a growth team running 30 experiments. You have neither, and the questionnaire is costing you 40% of your installs.

Asking for permissions on screen 1. On iOS you cannot ask twice.

Hiding the trial terms. It raises accidental trials, which raises refunds and 1 star reviews, which lowers installs. The loop takes 2 months to show up.

Designing for iOS and forgetting Android. Different back button behaviour, different keyboard, different payment sheet. The Android flow needs its own walk through on a real device.

FAQ

Why is my mobile app onboarding drop off so high?
Usually because the app asks for setup, permissions, an account and money before it shows a single result. Count the screens between first open and the first real result. If there are more than 4, that is the reason, and the fix is reordering the flow rather than polishing the screens.

Where should the paywall be in app onboarding?
After the first real result, with a reference to what the user just did. Paywalls placed at the end of the questionnaire, before any value, convert at 1 to 4 percent in the apps I audit. The same paywall after activation usually converts 2 to 3 times better with fewer refunds.

What is a good onboarding completion rate for a mobile app?
It depends on what you call completion. Install to first real result above 40 percent is healthy for a consumer app, and above 60 percent for a utility app. Install to trial started between 5 and 12 percent is typical for subscription apps with a well placed paywall.

Hard paywall or soft paywall?
A hard paywall converts more on day 1 and a soft paywall converts more over 30 days, because users who did not pay come back. For an app with strong retention, I test soft first. For a single purpose app with 1 session of value, hard is often right.

How long does it take to redesign app onboarding and the paywall?
3 weeks for both platforms: audit and baseline in days 1 to 4, wireframes by day 8, usability test with 5 recent installers by day 12, dev ready Figma screens by day 15.

Can I fix onboarding drop off without a designer?
The first change, moving the paywall after the first result and cutting the questionnaire to 3 questions, you can do with your developer this week. The states, the copy, the permission screens and the plan selection are where a designer earns the fee, and where the second half of the improvement comes from.

Working with us

We redesign onboarding and paywall flows for iOS and Android apps with traction. 1 flow takes 3 weeks: audit findings on day 4, wireframes tested with 5 recent installers by day 12, dev ready Figma screens for both platforms by day 15. We work async in Figma, Slack and Loom, across timezones.

We also say when you do not need us. If your paywall sits before the first result, move it first and measure for 2 weeks. If the app has under 5,000 installs a month, the numbers will not tell you much yet, and the better investment is 10 conversations with users who cancelled.

If you know that installs are fine and trials are not, and nobody can say where the users go, send us the funnel. Book a free 15 minute intro call and we will tell you what we see, even if your team fixes it themselves afterwards.