∴ Use case · Onboarding & activation
Turn onboarding ideas into live experiments without waiting on engineering.
Onboarding attracts plenty of opinions and very few clean tests. Trevo reads the forms, redirects, empty states, and gates you actually shipped, then writes the approved variant as a pull request.
export function SignupForm() { return <AllSixFields onSubmit={submit} />; const variant = useExperiment(EMAIL_FIRST); if (variant === "progressive") { // step 1: work email · step 2: the rest return <TwoStepSignup onSubmit={submit} />; } return <AllSixFields onSubmit={submit} />;
How do you A/B test onboarding and activation?
Onboarding experiments change the first-run experience — the signup form, the post-signup redirect, the empty states, the activation checklist — and measure whether more new users reach the product’s value moment. With Trevo, each change arrives as a pull request in your own repository: the variant is real code behind a feature flag, new-user cohorts are assigned consistently, and activation and retention events are evaluated with always-valid sequential statistics. Ideas stop dying in the backlog because implementation is no longer the bottleneck — review is.
How it works
From “we should really test that” to a decided change in the first-run experience.
Trevo maps the first-run path
The scan follows what a new user hits: the signup form fields, the verification step, the redirect target, the empty dashboard. Proposals cite the components involved.
Ideas become reviewable variants
Progressive disclosure, a different first screen, a checklist instead of a blank state — each is a diff you can read, behind a flag, on a trevo/* branch.
New users are the cohort
Assignment happens at first touch and sticks, so each new user experiences one coherent flow from signup through activation.
Activation metrics decide
Signup completion, first key action, week-one retention — evaluated with mSPRT so you can look daily without invalidating the result. Cleanup is automatic.
The whole funnel, not just the form
Activation problems hide behind the form: the email-verification wall, the empty first screen, the moment the product asks for a credit card. Because Trevo works in the repo, the entire path is testable — including the server-side gates.
- ✓Signup, verification, redirect, and empty states in one loop
- ✓Server-side gates (trial rules, verification requirements) testable too
- ✓Every proposal cites the code it read
route /signup → /verify → /appfields 6 on one screenempty /app renders blank state for new usersfound 3 proposals for this path
Cohorts and honest measurement built in
Onboarding tests are easy to fool yourself with: mixed cohorts, peeking, novelty effects. Trevo assigns at first touch, tracks the events it wired in the same PR, and uses statistics that stay valid however often you check.
- ✓First-touch assignment — no mixed cohorts
- ✓Exposure and activation events wired in the experiment PR
- ✓Always-valid stats: peeking is safe by construction
cohort new signups since launchprimary first_project_createdguard week-1 retention, support contactsstatus peek anytime — mSPRT
What this looks like in practice
Illustrative onboarding proposals of the kind Trevo writes — yours come from your own first-run code.
Δ signup form
Work email first, the rest later
Two-step disclosure: one field to commit, the remaining fields after — the classic form-length test, actually run.
measures → signup_view → trial_started
Δ empty state
Checklist instead of a blank dashboard
Replace the empty first screen with the three actions your activated users all took, in order.
measures → first_key_action → week-1 retention
Δ activation gate
Defer the verification wall
Let new users reach the product before verifying email, and move the wall to the first save.
measures → signup → activated within 24h
Frequently asked questions
What should an onboarding A/B test measure?
A completion metric alone is not enough — a shorter form always “wins” signup completion. Pair it with an activation metric (the first meaningful action in the product) and a guardrail like week-one retention. Trevo wires all three kinds of events in the experiment pull request.
How long do activation experiments take to conclude?
It depends on signup volume, not calendar time. Sequential statistics conclude as soon as the evidence justifies it, and tell you honestly when it does not — there is no fixed two-week rule.
Can Trevo test flows that involve the backend — verification, invites, trials?
Yes. Trevo edits code, so server-side gates are ordinary experiments: when verification is required, how invites behave, what a trial includes. Proposals carry a surface tag — frontend, server-side, or full-stack — so reviewers know the blast radius.
Will experiments confuse users who signed up mid-test?
No — assignment happens at first touch and sticks. A user who saw the progressive signup keeps the matching first-run experience; nobody flips between arms mid-flow.
We already know our onboarding is bad. Why test instead of just fixing it?
Because a redesign is also a bet, just an unmeasured one. Running the fix as an experiment costs one code review, keeps the rollback trivial (the flag), and tells you what the redesign was actually worth — which is what makes the next one easier to argue for.
Keep reading: Trevo for growth teams · Trevo for startups · Pricing experiments · PostHog + Trevo · Trevo vs VWO
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.