Signup flow optimization is the work of shortening the path from “start free” to the first moment a new user gets real value, not just getting more accounts created. Ask only for the fields you need, offer SSO, verify email only where risk demands it, ask onboarding questions that change the product, and judge every change by how many visitors activate.
Mapping the signup-to-activation funnel
Everything after the “start free” click is the signup flow, and it leaks more than teams expect because each step has a different owner: marketing owns the form, engineering owns verification, product owns the first screen.
Map it as one funnel, from signup-page view to activation, the action that predicts a user will pay. Use the same definition your email program triggers on; the SaaS onboarding email sequence post covers how to pick it.
| Step | Measured as | Typical leak |
|---|---|---|
| Signup page viewed | Unique visitors to the form | Wrong traffic, unclear offer |
| Account created | Accounts ÷ form viewers | Too many fields, strict password rules, card required |
| Email verified | Verified ÷ accounts | Verification email in spam, lost tab |
| Onboarding completed | Completed ÷ verified | Too many questions, free-text fields |
| Setup done | Data connected or first item created ÷ onboarded | Integration wall, needs someone else’s access |
| First value | Core result reached ÷ setup done | Blank screen, no guidance |
| Activated | Activation event ÷ first value | No reason to return, share or invite |
Multiply the steps and you get the number that matters: visitors to activated users. Pull each step by weekly signup cohort and start where you lose the most people in absolute terms.
How many fields and which ones
The minimum to create an account is an identity: a work email plus a password, or an SSO login. Every other field needs a reason that outweighs the drop-off it causes, and most can come later from onboarding questions or enrichment.
| Field | Keep at signup? | Better alternative |
|---|---|---|
| Work email | Yes | — |
| Password | Only without SSO | SSO, magic link or one-time code |
| Full name | Usually, as one field | Pull from the SSO profile |
| Company name | Rarely | Derive from email domain, confirm in onboarding |
| Company size | No | Enrichment or one onboarding question |
| Role or use case | No | Onboarding question after account creation |
| Phone number | Only if sales calls every signup | Ask when the user requests a demo or hits a sales trigger |
| Credit card | Only in card-upfront trials | Ask at conversion |
Three details matter more than the field count:
- Password rules. Show requirements before the user types, not as an error afterward. Allow paste and password managers.
- Work email gating. Blocking gmail.com cuts noise but also real evaluators testing on a personal account. If sales capacity is the concern, route personal-domain signups to self-serve instead.
- Card upfront. A required card usually means fewer, more committed trials; no card means more trials that need a stronger first session. Choose by motion; product-led vs sales-led growth covers how that choice shapes the funnel.
SSO, email verification and friction trade-offs
Social and work SSO
“Sign in with Google” and “Sign in with Microsoft” cover the work email providers most B2B teams use, and developer tools often add GitHub. SSO removes the password step, returns a verified email and name, and keeps people on the page. Put the buttons above the email form.
Handle two edge cases: account linking, so someone who signed up with Google and later types the same email with a password lands in the same account, and personal accounts, since a gmail.com login says nothing about the company, so ask for it in onboarding. Enterprise SAML SSO is a separate admin feature and doesn’t belong in this decision.
Email verification options
| Approach | Friction | Protection | Use when |
|---|---|---|---|
| Verify before any access | Highest: user leaves the tab | Strongest | Free usage costs you real money, or abuse is common |
| One-time code in the same tab | Medium | Strong | You need verification but want to keep the session |
| Deferred verification | Low | Moderate | Gate inviting teammates, sending from the product or exporting |
| SSO | Lowest | Verified by the provider | Offer it to everyone who can use it |
My default for most B2B products is deferred verification with a persistent banner and a hard gate on abusable actions. Products that give away compute, such as AI generation, should verify first. Either way, test that the verification email arrives in seconds and lands in the inbox; one sitting in spam loses signups that never look like a form problem.
Onboarding questions that personalize without slowing
An onboarding question earns its place only if the answer changes something: the template shown, the default dashboard, the checklist, or whether sales gets involved. If you can’t name what it changes, cut it.
| Question | What the answer changes |
|---|---|
| What do you want to do first? | Which template and checklist load |
| What’s your role? | Default view and example content |
| How many people will use this? | Seat defaults; routes large teams to a sales-assisted path |
Rules that keep this fast:
- Ask one to three skippable questions, one per screen, with single-click answers.
- Avoid free-text fields except an optional “Other.”
- Ask after the account exists, so an abandoned questionnaire still leaves a user you can reach.
- Save answers as user and account properties so the product, email tool and CRM all see them.
Empty states and the first session
The first session carries much of the weight of activation, yet new users often land on a blank table built for someone who already has data.
A first-use empty state should do four things: say what belongs here, say why it matters, offer one primary action, and give a fallback for users who can’t take that action yet. The fallbacks that work most often:
- Templates matched to the use case picked in onboarding, so the first item is mostly built.
- Sample data that shows the product working, clearly labeled and easy to delete.
- “Invite someone who has access.” When setup needs an admin, developer or API key the user lacks, let them hand off that one step instead of abandoning the trial.
- A short checklist of three to five steps toward activation, with “Create your account” already checked.
Skip the ten-step tour that points at every button; many people close it early. Contextual prompts on the relevant screen do the same job without blocking the work.
One trap: if sample data can trigger your first-value event, you’ll count people as activated who never touched their own data. Tag sample-data actions and exclude them. This is why conversion rate optimization for SaaS reaches into the product: most of the leverage sits there, not on the marketing site.
Instrumenting activation in the product
Most signup funnels I audit have a blind spot: signup events fired from the browser and blocked by ad blockers, no link between the anonymous visitor and the new account, or events tied to users when the buyer is the account.
A minimal event plan:
| Event | Fires when | Where | Key properties |
|---|---|---|---|
signup_viewed | Signup page loads | Client | Referrer, UTM parameters |
signup_completed | Account is created | Server | Method (Google, Microsoft, email), plan, trial type |
email_verified | Verification succeeds | Server | Time since signup |
onboarding_completed | Last question answered or skipped | Server | Answers, skipped (true/false) |
setup_completed | Data connected or first item created | Server | Integration, sample data (true/false) |
activated | Activation criteria met | Server | Time to activate, account ID |
Before trusting the numbers:
- Critical events fire server-side, so browser blockers can’t erase them
- The anonymous ID is linked to the user ID at signup, keeping pre-signup source data
- Every event carries an account or workspace ID for account-level reporting
- First-touch source is saved on the account record, not only in analytics
- Event names match what the email tool and CRM trigger on
- Internal and test accounts are excluded
Then report weekly cohorts on signup-to-activation rate and median time to activate, split by signup method, onboarding answer and traffic source. One use case activating far below the others points straight at its template or empty state.
Experiments worth running first
Judge every signup change on visitor-to-activated rate, not signup completion. Less friction almost always raises signups, but not always activated users.
A hypothetical example: variant A turns 40% of signup-page visitors into accounts and 30% of those activate, so 12% of visitors activate. Variant B drops two fields and converts 50%, but only 22% activate, so 11% of visitors activate. B wins on the signup chart and loses on the number that matters.
Start with these. The leading metric shows whether each change did its job; the guardrail catches side effects.
| Experiment | Change | Leading metric | Guardrail |
|---|---|---|---|
| SSO first | Google and Microsoft buttons above the form | Accounts created | Share of personal-domain signups |
| Deferred verification | Let users in, gate key actions | Onboarding completed | Spam or abusive accounts |
| Field cut | Remove phone and company size | Accounts created | Sales-qualified signups, if sales uses them |
| Template empty state | Preload a template from the onboarding answer | First value in session one | Activation excluding sample data |
| Integration hand-off | “Invite a teammate to connect” option | Setup completed | Time to activate |
Most SaaS signup flows lack the volume for clean A/B tests measured at activation. If yours lacks it too, ship one change at a time, compare several weekly cohorts before and after, and log anything else that changed, such as a new campaign.
Get it built
If signups look healthy and activation doesn’t, I’ll map the funnel, fix the tracking and ship the first experiments. It starts with a Growth Audit, $1,500 fixed and credited if we continue. See pricing or get in touch.