Most "redesign the onboarding" tickets start with opinions and end with a flow that's shorter but unmeasured, nobody can say if the new version converts better because nobody logged the old one in a way that answers the question. Before touching copy or screen order, the instrumentation needs to exist. Here's the minimum set that makes a before/after comparison possible.
Define "first value" as an analytics event, not a UI state
"Onboarding complete" is a UI state, it fires when the last screen closes, whether or not the user got anything out of it. First value is different: it's the first time the product actually does something useful for this specific user. A photo app's first value event is library_cleaned, not onboarding_dismissed. A budgeting app's is transaction_categorized, not account_created. If you can't name the event, you haven't found it yet, go compare retained users against churned users from the first few days and find the action that separates them.
The three metrics that matter, and why completion rate isn't one of them
- Activation rate - percent of new users firing the first-value event within a defined window (7 days is common). This is the real top-line number.
- Time to value - median time from first open to first-value event. Read it alongside activation rate; a shorter median among a smaller activated cohort is a trap, not a win.
- Step-level drop-off - where people actually leave the flow, step by step. This is what tells you whether a step is disposable or load-bearing.
Completion rate (did they finish the flow) tells you almost nothing on its own. A 90% completion rate with a 40% activation rate means your flow is good at getting people through screens and bad at getting them to the thing that matters.
Sort every step with one question, logged against real data
- Keep: would the product be unsafe, non-compliant, or non-functional without this step? -> identity verification, required consent, payment auth.
- Defer: useful later, not required for first value? -> profile photo, notification prefs, invites.
- Remove: serves the team more than the user? -> unused feature tours, duplicate confirmations, long surveys.
This only works if you can see step-level drop-off per cohort, don't sort from a whiteboard, sort from the funnel.
Permission requests: timing is an engineering decision, not a copy decision
Request permissions at the moment they're needed, not in a batch during onboarding, camera access when the user starts their first scan, notification permission after they've seen a reason to want alerts, not before. This isn't just better UX, it measurably changes grant rates, because the system prompt appears with context instead of as an abstract ask. If your onboarding flow currently front-loads permission requests, that's usually an easy first fix with a clear before/after in your grant-rate logs.
Deferred registration needs a technical answer to "what happens to this session if they bounce?"
Letting users try the product before creating an account (Duolingo's well-known move, worth roughly a 20% DAU lift in an early internal test, per the company's own account) means you need anonymous-session state that can later merge into a real account without data loss. If your backend can't cleanly convert an anonymous session into an authenticated one, deferred registration will cost you more in support tickets and lost progress than it gains in completion.
Regulated flows: the identity-check step isn't a UX problem, don't instrument it like one
If you're in fintech or insurance, step-level drop-off at an identity-verification gate will look terrible compared to everything else in the funnel, and that's often expected, not a bug. Signicat's 2022 survey across 14 European countries put financial-app abandonment at 68% in the prior year, with 21% citing excessive personal-data requests specifically. The fix there isn't removing the step, it's reducing abandonment around it: save-and-resume state, clear in-flow explanations of why each field is required, and collecting only what's legally mandated at account creation rather than front-loading optional fields into the same gate.
Varmeta's longer write-up on separating load-bearing onboarding steps from the ones that just add screens covers the product-and-design side of this in more depth. The condensed table version is on GitHub if you want the keep/defer/remove criteria and cited numbers without the narrative, closer to something you'd paste into an internal doc.
Discussion: if you've instrumented an onboarding flow properly, what ended up being your actual first-value event, was it the one the product team originally assumed?
Top comments (0)