Onboarding in App: How to Design Flows That Convert

Onboarding in an app is the first-run experience that takes a new user from install to the first moment they get value. It usually covers a welcome screen, a few questions, permission requests, a short product tour and, for subscription apps, a paywall. The goal is simple: get the user to the core action (a workout, a lesson, a meditation, a first AI answer) as fast as possible, and ask for money at a point where the value is clear.

For subscription apps, the practical answer is to keep it short, personalize it with a few questions, show the paywall after the user sees a tailored result, and measure every step. You can build this inside the app, or you can run the same flow on the web before the install. The rest of this article covers both approaches, what to include, how to test, and which mistakes to avoid.

What is in-app onboarding?

In-app onboarding is every screen and prompt a user sees between opening the app for the first time and reaching the main experience. It has three jobs:

• Orient: explain what the app does and what the user should do first.
• Collect context: ask for goals, level, preferences or schedule so the product can be personalized.
• Convert: ask for an account, permissions and, in subscription apps, a trial or purchase.

It is not the same as a feature tour. A tour shows buttons. Onboarding gets someone to a result. Many apps lose most of their new users in the first session, so this flow sets the ceiling for everything that comes after it, including retention and subscription revenue.

What types of in-app onboarding exist?

Most apps use one of a few patterns, often combined.

Welcome carousel. Three to five swipeable screens that describe benefits. It is easy to build, but users tend to skip it because it asks nothing from them and gives nothing back.

Quiz or questionnaire onboarding. The app asks about goals, experience, habits or constraints, then builds a personalized plan. This is common in health, fitness, language and education apps. The answers also give you data to segment users later.

Progressive onboarding. Instead of one long flow, the app teaches features at the moment they become relevant: tooltips, checklists, empty states with a clear next step. It works well for products with many features.

Interactive or "learn by doing" onboarding. The user completes a real first task, such as recording a first entry or taking a first lesson, inside the flow. It shows value fastest but takes the most design and engineering work.

Permission and account prompts. Notification, tracking and sign-up requests. These convert better when the app explains why it is asking and asks after the user has seen some value.

What should a good in-app onboarding flow include?

There is no single correct sequence, but strong flows for subscription apps tend to follow the same logic:

1. One clear promise. The first screen states the outcome the user wants, in their words, not a feature list.
2. A few meaningful questions. Ask only what changes the experience. Every question should map to something the user will see later, such as a plan, a difficulty level or a content track.
3. A personalized result. Show a plan, a score or a recommendation built from the answers. This is the payoff that makes the user willing to continue.
4. Progress and momentum. A progress indicator and short screens reduce abandonment. Keep each screen to one decision.
5. The paywall after value. Present the offer once the user has seen their tailored result. Explain what is included, what the trial terms are, and how to cancel. Clear terms reduce refunds and support tickets.
6. A first action. End on the core action, not on a dashboard. The user should do something in the first session.

Skip anything that does not serve one of those steps. Long sign-up forms, unexplained permission requests and generic tutorials are the usual sources of drop-off.

In-app onboarding vs onboarding on the web

Some subscription teams now run the onboarding quiz and the first payment on the web, before the user installs the app. The user clicks an ad, answers the quiz in a browser, sees a personalized plan, pays, then downloads the app and logs in. This is a web2app funnel. It is one option, not a replacement for everything in-app, and the right choice depends on your product, your platform rules and your team.

Where the flow lives

• In-app onboarding: inside the iOS or Android build, after install.
• Web onboarding (web2app funnel): in a browser, before install; the app is used after login.

Speed of changes

• In-app onboarding: usually tied to a release and, on iOS, app review, unless you use remote config.
• Web onboarding (web2app funnel): edited and published in a visual builder without an app release.

Payments

• In-app onboarding: purchases normally go through the app store, where Apple charges up to 30% commission (15% under the Small Business Program).
• Web onboarding (web2app funnel): subscriptions are sold on the web with a payment provider such as Stripe, outside the app store, where allowed.

Testing and attribution

• In-app onboarding: A/B tests need a testing tool or custom code; attribution from ads is limited by what the install flow passes through.
• Web onboarding (web2app funnel): each ad click lands on a page you control, so UTM data, pixels and server events are available from the first screen.

Best fit

• In-app onboarding: products where the first value needs the app itself, such as camera, sensors or offline content.
• Web onboarding (web2app funnel): products where a quiz, a personalized plan and a paywall can run before the install.

Rules on external payments differ by region and change over time, so check them before you move revenue off the store. Our web2app funnel compliance guide is a good starting point.

How to build and test onboarding in an app

Start with the shortest version that reaches the core action, then add steps only when data shows they help.

1. Define the activation event. Pick the action that predicts retention in your app, such as a completed first lesson or workout.
2. Map the current flow. List every screen and count how many users reach each one.
3. Change one thing at a time. Test question count, screen order, paywall timing or copy separately, so you know what caused the result.
4. Segment by source. Users from different ad channels and countries behave differently. A flow that works for US Meta traffic may not work for UK TikTok traffic.
5. Localize properly. Translated onboarding that reads naturally usually beats English-only for non-English markets.

If you build onboarding in the app, you can use remote config and an experimentation tool to make changes without waiting for each release. If you move onboarding to the web, a no-code builder removes the engineering step. web2wave is one such builder: it creates quiz and onboarding flows, web paywalls, A/B experiments and attribution for web2app funnels. Its quiz builder covers the question and result screens, and its paywall builder covers the offer and payment step. Plans are a flat monthly fee on Basic, Starter and Pro, with a revenue share only on Advanced, and A/B testing is available from Pro.

As an example of what a web funnel can do, MyMental AI GURU generated over $100K in revenue with web2wave, with about 55% of subscribers still active and refunds under 5% of revenue. Results depend on the product and the traffic, so treat a case like this as a reference point, not a forecast.

Which onboarding metrics should you track?

Track a small set of numbers that tell you where users leave and whether they pay:

• Step completion rate: the share of users who move from each screen to the next. The biggest drop is your first thing to fix.
• Onboarding completion rate: users who finish the whole flow out of those who start it.
• Time to first value: how long it takes to reach the activation event.
• Paywall view to purchase rate: how many people who see the offer start a trial or pay.
• Trial-to-paid conversion and refunds: whether the flow set the right expectations.
• Day 1 and Day 7 retention: whether onboarding led to real usage.
• Cost per paying user by source: onboarding changes should be judged against acquisition cost, not only conversion.

Send these events to your analytics tool (Amplitude, PostHog or Mixpanel) and your subscription stack (RevenueCat, Adapty, Qonversion, Superwall or Apphud), so onboarding data and revenue data can be joined. The integrations page lists what web2wave connects to.

Common onboarding mistakes

• Too many screens before any value. If the user answers ten questions and sees nothing in return, many will leave.
• Questions that change nothing. If the answer does not affect the result, remove the question.
• Early permission prompts. Asking for notifications on screen one gives users no reason to say yes.
• A paywall with unclear terms. Hidden renewal or trial details lead to refunds and bad reviews.
• No tracking per step. Without step-level data you are guessing which screen to change.
• One flow for every audience. Different goals, countries and ad sources often need different paths.
• Never retesting. Onboarding that worked last year may not work after your product, pricing or traffic mix changes.

FAQ

What is onboarding in an app?

It is the first-run flow that introduces a new user to the product, collects the information needed to personalize it, and guides them to their first useful action. In subscription apps it often ends with a paywall.

How long should in-app onboarding be?

As short as possible while still collecting what you need to personalize the experience. There is no universal screen count. Test removing steps and compare completion, activation and paid conversion, not just completion.

When should the paywall appear in onboarding?

Usually after the user has seen a personalized result, so the value is clear. Some apps show it before the first session and others after a first action. Test both with your own traffic.

Can I do onboarding outside the app?

Yes. In a web2app funnel, the quiz, personalized plan and payment happen on the web, and the user then installs the app and logs in. This lets you change the flow without an app release and use web payment providers where the rules allow it.

How do I A/B test onboarding?

Change one variable, split traffic randomly, and run the test long enough to see paid conversion, not only screen clicks. In-app, use an experimentation tool or remote config. On the web, a builder with built-in experiments handles the split. For more tools, see our guide to web2app funnel builders.

Want to see how a web onboarding funnel would look for your app? Book a demo or start free.