Find the onboarding that actually activates
How many steps, in what order, asking what — and how the flow should adapt to what the user just told you. Today each of those questions costs a frontend rebuild, so most teams answer them once a year.
The problem
Onboarding is where drop-off compounds, and where iteration is slowest.
Every step in a signup flow loses people. That makes onboarding the highest-leverage funnel in the product — and the one teams touch least, because changing the order of two screens means rewiring a state machine, updating validation, and shipping through review on three platforms.
So instead of ten small experiments, teams do one big redesign a year. The redesign moves several things at once, activation shifts by a few points, and nobody can say which of the twelve changes did it.
Personalization makes it worse. "Show the team-invite step only to users who said they work
with others" starts as a reasonable if, and ends up as a thicket of branches nobody can measure — because each branch is code,
not configuration.
// before — a rebuild per experiment const STEPS = [ 'account', 'company', 'role', 'invite_team', 'connect_data', 'pick_template', 'tour', ]; if (answers.role === 'solo') { // one more branch nobody measures STEPS.splice(3, 1); } // after — order and inclusion are values, // resolved per user from one parameter set
What you put under control
The flow becomes data. Declared once, then governed centrally.
| Parameter | Type | Default |
|---|---|---|
| onboarding.step_order | json | 7 steps |
| onboarding.required_steps | json | 4 of 7 |
| onboarding.ask_role_first | boolean | false |
| onboarding.defer_data_connect | boolean | false |
| Surface | Kind | Role |
|---|---|---|
| Signup web | frontend | render |
| Mobile onboarding | frontend | render |
| Flow orchestrator | backend | decision |
Those bindings are what compute the risk class — medium: backend surface · decision binding.
| Variant | step_order | ask_role_first |
|---|---|---|
| control | 7 steps | false |
| short-path | 5 steps | false |
| role-first | 5 steps | true |
One change moves the order and the length together, so you are testing a coherent flow rather than an isolated screen.
Risk class: medium
A person approves the measurement plan before traffic, and again before the winning flow becomes the default. Signup is the one funnel you cannot quietly break.
Adapt to what the user just told you
Answers from step two are context for step three — and context is measurable.
The context you already pass to the SDK — plan, referral source, company size, and the answers collected so far — is what the flow adapts on. Because that context is an input to resolution rather than a branch in your code, each adaptation is a policy you can measure and roll back.
Start with targeted overrides where you already have a hypothesis. Move to a contextual bandit when you would rather have the system learn which sequence suits which kind of user, within the guardrails you set.
The important part is that "solo users skip the invite step" stops being an assumption buried in a component. It becomes a policy with an effect size attached.
| Context signal | Learned sequence | Lift |
|---|---|---|
| role = solo | short-path, no invite | +8.4% |
| role = team lead | role-first, invite early | +5.1% |
| company > 200 | defer data connect | +3.7% |
| referral = partner | control | no effect |
Segments you did not think to test
A bandit surfaces where the effect actually lives. "Partner referrals behave like the control" is a finding worth having — it stops you personalizing something that does not need it.
How it runs
The mechanism is configuration. The application code is already done.
Onboarding has a long feedback loop: the thing you care about is activation a week later, not whether someone clicked "next". The experiment phase runs to a sample sized on the real outcome, and measurement progress tells you how far off a verdict you are.
Users are assigned once and stay assigned. Someone who begins signup in the short-path arm finishes in it, even if they abandon and return the next day on a different device.
What you get back
A verdict on activation, not on click-through.
The secondary metric is the one that matters politically. Someone will argue a shorter onboarding produces less committed users — here the 30-day retention number answers it directly, and it was in the plan before the change ran rather than requested afterwards.
On completion the winning step order becomes the parameter default, and the whole record is retained: what was asked, which sequences were tried, the interval at the moment of the call, and who approved it.
5 steps beat 7 on activation by 6.8% with retention flat. A later attempt at 3 steps regressed activation — the floor is 5. Do not re-run without a new hypothesis.
Keep reading
The mechanics behind this page.
Make the flow a value, not a rebuild
Parameterize the step order this week. The first measured change usually pays for the integration.