User Onboarding Process: 5 Stages, Fix Map, Template

People sign up, look around for a minute and never come back. If that is your dashboard, you probably have a list of fixes: add a tour, add a checklist, add tooltips.

User onboarding is the guided path from signup to the first outcome your product exists to deliver. The useful way to improve it is to find where your own users stall, then apply the one pattern that fits that stall.

In this guide:

• What user onboarding is, and which "onboarding" frameworks belong to HR instead
• Five stages, each ending in one event you can count
• A table that maps each stall point to one pattern, with measured limits
• A one-page spec and a way to read your numbers without fooling yourself

The guided path from signup to first value, the first outcome the product exists to deliver, is user onboarding. It applies wherever a new person must do something before value appears: a mobile app, a SaaS workspace or an e-commerce account.

Three terms get mixed up, so here is the split:

• User onboarding: self-serve, in-product guidance for an individual who signed up on their own.
• Customer onboarding: implementation led by a customer success manager, usually for larger deals where a person is worth the cost.
• Employee onboarding: an HR process for new hires, with its own frameworks.

The "five C's of onboarding" and "stages of onboarding" in HR guides describe employees.

SHRM's summary of Talya Bauer's work names four levels of employee onboarding: compliance (legal and policy issues), clarification, culture (organizational values and norms) and connection.

Guides that stretch those four to five C's are still talking about new hires.

None of the four levels maps one to one onto a product user, who has no policy to learn and no culture to absorb.

What you can borrow is the test of whether onboarding worked: a defined outcome is reached. For a product, that outcome is the activation event, the first action that proves someone got value. If you can't name yours yet, the template section below makes you.

The 77% figure quoted in onboarding advice matches Andrew Chen's 2015 analysis of Quettra data on Google Play apps. It counts the share of an install cohort no longer active on day 3.

The Quettra data covers anonymized usage of apps on over 125M Android devices over five months from January 2015, limited to apps with over 10,000 installs, with Google and preinstalled apps excluded. In it, the average app loses 77% of its daily active users within 3 days of install and 90% within 30 days.

That is a daily-activity curve. Chen himself notes that a "lost" user may simply use the app once a week or a few times a month. So the number describes a missed day of use and says nothing about quitting, and it was never a measure of onboarding.

Here is what each number in circulation measures, and how to word it safely:

Does onboarding still matter, then? Yes, and the same analysis shows where. Top apps had higher day 1 retention and much stronger absolute day 30 numbers than the average app, so they are ahead from the first day, which is where onboarding acts.

Chen reads most of the room to improve these curves as sitting in how the product is described, the onboarding flow and the triggers you set up afterward.

So the case for onboarding is that the first day is where the curve is won or lost. Quote it that way and skip the scary percentage.

Five stages, signup, setup, first value, habit and expansion, make up a user onboarding process, and each ends with one event you can count. Put the boundary at an event, because a screen can be viewed without anything happening. The same stages are the skeleton of your onboarding flow.

Here is the process with its exit events:

1. Signup. The user creates an account. Exit event: account created.
2. Setup. The user connects data, invites a teammate or picks a goal. Exit event: the minimum setup is complete.
3. First value. The user does the thing the product exists for. Exit event: the activation event.
4. Habit. The user returns and repeats the action. Exit event: the second and third use inside your chosen window.
5. Expansion. The user adopts a second feature or invites others. Exit event: the second use case is live.

The activation event is the anchor for the rest. If you haven't defined it, the user activation guide covers the event, its rate and the three points where users leak after signing up, so this guide doesn't repeat them.

Speed is bounded by relevance. Measure it as the median time from signup to the activation event, and read the time to value guide for how long that should take.

Where the sign-up gate sits is the most testable decision in the first two stages. Ask for the account after the first value moment where you can, and let users dismiss the request before it turns into a wall.

Duolingo's VP of Growth described the sign-up delay in a July 2017 First Round Review interview: moving the sign-up screen back a few steps led to about a 20% increase in DAUs.

The more useful finding is the second one. Hard sign-up walls performed significantly worse without soft walls priming the request, meaning optional prompts users could ignore. Optimizing both walls later added an 8.2% increase in DAUs, about three years after the original test.

So introduce a hard wall only after soft walls have come first. The caveats belong to the rule: these are one consumer-app company's tests from an interview that is years old, and the speaker says the first test predates her time at the company. Whether it transfers to B2B SaaS is a hypothesis for you to test. Form fields, auth methods and single versus multi-step forms belong to signup flow optimization.

Match the pattern to the stall point: move the sign-up gate if users leave before acting, seed the workspace if they stall in setup, guide in context if they stall after setup, and reorder the checklist if steps complete but activation does not.

The signals below are our reading of event data, the measured limits come from the benchmarks named in the last column:

Pick one pattern per stall point. That is the short version of user onboarding best practices: you don't need a dozen tips, because your data tells you which one applies. Stacking a tour, a checklist and tooltips on the same step hides which one worked.

Tours. Keep a tour to five steps or fewer and let the user start it. A 2025 benchmark of the tours one product-tour vendor's customers ran found that self-triggered tours doubled engagement compared with automated, blanket-triggered ones. User-triggered or smartly timed tours beat delayed ones by 2-3x.

Length matters as much as timing. Tours beyond five steps lost more than half of users' attention, and the top 1% of tours by completion never went past five. That corrects the common advice to run five to seven steps. Tours opened from a launcher reached 67% completion, the highest in that data, and progress indicators improved completion by 12%.

Checklists. A user onboarding checklist has low completion. One product-adoption vendor's customer data shows 22.1% for sales-led companies and 19% for product-led companies, and the source does not say who is in the denominator.

Either way, most users do not finish, so a checklist can be abandoned before the step that matters. Put the activation action first, and check whether users complete the whole list without ever activating. If they do, the list rewards the wrong steps.

Seeded workspaces. Seed a workspace when users create one and then stall without adding data. A sample project they can edit beats a blank page, but only if users can replace the sample data with their own. The user's first edit then becomes the activation event.

Personalization. Fork the path only when segments need different first actions. If every segment's first action is the same, one path serves everyone, and the activation guide linked above has the rule in full. AI setup and smart defaults fall under the same test: use them where they remove a manual step on the way to the first action.

The human layer. High-value accounts plausibly need a person on setup, because a deal that size justifies one. That is our inference. The higher sales-led completion rate (22.1% against 19%) is consistent with it but does not prove it. For the self-serve side of the model, see product led growth.

Let users skip. Every tour, checklist and survey needs a way out. A user who already knows the product will skip anyway, and forcing a walkthrough only adds a step before the first action.

Ask one question. A one-question survey in the flow is cheap. Users answer more readily when the question is short and the moment is theirs. Place the survey after the user's first action, not before it, so the answer comes from experience.

Too many steps is the most common mistake across all of these. If a step does not move the user toward the activation event, cut it or defer it.

A one-page user onboarding template is a spec that names the activation event, its time window, who enters, each stage's exit event, the triggers and the denominator of every metric. Work backward from the activation event: every step that does not move a user toward it gets cut or deferred.

Here is the spec filled in for an illustrative invoicing app. It uses placeholders and words, no real results:

To use it, fill the activation event and window first, then write the exit events backward from there. Any tour in your user onboarding flow stays at five steps or fewer. Review the onboarding spec on the date you wrote down, because a spec nobody reopens turns into a screen inventory.

User onboarding is working when a rising share of eligible new users reach the activation event inside a fixed window and the cohorts that do reach it keep retaining. Pick the denominator before you pick the metric, because "completion" with no base can mean anything.

Four metrics cover it:

For the activation rate and its formula, the activation rate section of that guide is the reference, and cohort analysis covers how to read the curve.

State the retention method every time. Amplitude's documentation defines two.

Return On counts the users who came back on exactly that day, so day 7 is the share who returned on day 7. Return On or After counts users who came back on that day or any later day, so day 7 is the share who returned seven days or more after first use. One cohort reads as two different numbers under these definitions.

That is why a published benchmark is a poor yardstick for your onboarding. The 2015 curve leaves 10% of an average app's daily active users still active at day 30 (the 90% lost subtracted from the whole cohort, our arithmetic).

A 2025 push-platform study reports 3.10% on iOS and 2.82% on Android at day 30 but states no retention definition, sample or denominator on its page. The populations and measures differ, so we compute no ratio between them.

Instead, compare your own cohorts before and after a change, using the same method both times. Then decide which problem you have:

• Few users reach the event, those who do retain like healthy cohorts: you have an onboarding problem. Fix the stall point with the table above.
• Most users reach the event and still leave: you have a product problem, or you picked the wrong activation event. More onboarding will not help.

If you do one thing this week, write the spec above for your product and read last month's signup cohort against it. The stall point will show up in the exit event with the biggest drop, and that is the one pattern to ship first. Judge your onboarding on that drop, not on the 77% number.