Why Do Users Sign Up and Never Come Back?
A SaaS activation problem is rarely a funnel leak. It is a promise the landing page made that the first screen did not keep, and you can usually name the exact sentence.
On This Page
Ten people signed up on Tuesday. Two opened the product again on Wednesday. By the following Monday there is one, and nobody on the team can say what the other nine actually saw before they stopped. That is the shape of a SaaS activation problem, and sending more people to the sign-up page does not touch it.
The usual response is to treat the whole thing as a funnel: a leak somewhere between step three and step four, patchable with a tooltip and a progress bar. That framing is wrong often enough to be dangerous. What actually happened is simpler and harder to fix. The product made a promise it did not keep in the first session, and the people who left were being reasonable.
The promise is not vague, either. You wrote it down. It sits on the landing page in a headline that says something like "see every broken link on your site in a minute". Someone believed it, signed up, and arrived at a screen asking them to name a workspace, invite two colleagues and connect a repository. Nothing on that screen is broken. It is simply not the thing. We have argued before that activation deserves the attention teams give to acquisition, and this is the mechanism sitting underneath that argument.
The activation problem is a promise problem
Every sign-up is a small transaction. The visitor hands over an email address and a few minutes of attention, in exchange for a specific outcome somebody described to them. The first session either delivers a recognisable instalment of that outcome or it does not. There is no partial credit, and the visitor is not grading generously.
So the question worth asking is not "where do users drop off". It is what did we promise, and how many screens stand between the sign-up button and the first sight of it. Count them. The number is nearly always larger than the team believes, because the team stopped seeing those screens about eleven months ago.
The reframing does real work. Drop-off tells you where; a broken promise tells you what to change. A funnel chart pointing at step four invites you to redesign step four. The promise view asks the better question, which is whether step four should exist at all.
The gap between the landing page and the first screen
Marketing writes the landing page. Product writes the first screen. They are usually written months apart, by people who were not in the same meeting, and the seam between them is visible to everybody except the two teams responsible for it.
The verb mismatch
The landing page uses outcome verbs: see, find, fix, send, publish, report. The first screen uses setup verbs: create, configure, connect, invite, name, choose. Write both lists on one page. If they do not overlap anywhere, you have found the gap without any instrumentation at all. It is a five-minute exercise, and it is the first thing we run in a product design review.
The vocabulary break
The second seam is language. The page sells "campaigns" and the product has "sequences". The page says "site" and the app says "property". Each rename costs the new user a translation step, and translation steps in the first three minutes are paid out of the same attention budget that was supposed to carry them to the payoff. A tone of voice document that actually changes copy earns its keep here, because it makes one vocabulary binding across both surfaces instead of leaving each team with its own.
None of this needs a redesign. Renaming three objects so the product speaks the language of the page it came from is roughly a day of work, and it removes the most common reason a first session goes quiet.
The empty state is the first screen that matters
Most products are designed full. The mockups carry twelve projects, a chart with a pleasing curve, four teammates with avatars. Then a real new user arrives and sees none of it, because they have not done anything yet. The empty state is the one screen every single user encounters, and in most products it is the least designed screen there is.
An empty state that says "No projects yet" under a grey illustration is not neutral. It is a small, well-lit announcement that nothing has happened, delivered at the precise moment the visitor is deciding whether anything ever will.
What an empty state owes the user
- A demonstration, not an instruction. Show the filled version, built on sample content the user can poke at, edit or throw away. Seeing the outcome once beats three sentences describing it.
- One action, not five. A screen offering five equally weighted buttons is a screen that does not know what the visitor came for.
- The shortest route to the promise. If the page promised a report, the empty state offers to produce one on sample data before it asks for any connection.
- A reason the screen is empty. "You have not imported anything yet" reads differently from "No data", because the first one names the next move and the second one describes a void.
- A way out that is not the back button. Where somebody goes if they cannot complete the task right now, and how they find their way back to it tomorrow.
The cheapest version of all of this is a demo workspace: pre-populated at sign-up, clearly labelled as sample content, deletable in one click. It costs a seed script and a routing rule. It removes the empty state from the first session entirely, and it lets a stranger reach the promised screen before they have made a single decision on your behalf.
Setup cost, and who pays it
Every onboarding step is a bill handed to the visitor. Some bills are fair. Asking for a working email address is fair, because nothing can be delivered without one. Asking somebody to invite three colleagues before they have seen a single result is not a bill at all; it is a favour requested by a stranger.
The test we use is blunt. Does this step make the next screen better for the person completing it, or better for us? Workspace names, team invitations, role selection, "how did you hear about us", industry pickers and use-case quizzes are almost always for us. Every one of them can be asked later, of somebody who by then has a reason to answer.
Connections deserve their own paragraph. Asking a new user to install an app, grant OAuth scopes or paste an API key inside the first session is the most expensive request in the whole product, because it is a decision with security consequences taken on behalf of an employer by somebody who has known you for ninety seconds. Occasionally it is unavoidable. Where it is, the fix is not a friendlier modal; it is a route that proves the value on sample data first, and asks for the connection at the moment the user wants more of what they have just seen.
| What you observe in session one | The promise that broke | Where the fix belongs |
|---|---|---|
| Sign-up completes, no real view is ever loaded | Speed | Sample data, or a demo workspace |
| Settings is opened, then the session ends | Simplicity | Defaults that work before configuration |
| The integration screen is the last event | Independence | A route to value that needs no connection |
| One item is created, nobody returns | Payoff | The result screen, not the creation screen |
| The invite screen is the last event | Solo usefulness | Make the product useful for one person |
| Pricing is visited repeatedly mid-trial | Fit | Plan shape, not onboarding |
Read the middle column rather than the left one. The observed behaviour is only interesting because it points at the sentence you failed to keep. Take the first row literally, too: a first screen that renders slowly and responds slowly breaks the speed promise before a single word of your copy is read, which is why load and interaction latency belong in this audit alongside the wording.
A first session is not a tour of the product. It is the shortest honest route to the thing the landing page promised.
A first-session audit you can run this week
This takes a day. It needs no research budget and no statistical power, which is convenient, because most products in this position do not have the volume to run an experiment either. That constraint is the same one we describe in conversion work without the traffic to test.
- Write the promise down, word for word. Copy the exact headline and subhead from the page most sign-ups arrive on. One sentence. If nobody can find that sentence, that is already the first finding.
- Create a genuinely new account. Real address, no internal flags, no seeded organisation, on whichever plan a stranger lands on. Do it on a phone if that is how people arrive.
- Screenshot every screen until the promise appears. In order, numbered. Stop when the promised outcome is visible, or when you have run out of product.
- Mark each screen delivery or setup. Delivery moves the user toward the promise. Setup moves them toward your data model. Then look at the ratio and resist the urge to defend it.
- Time the whole path honestly. Not the demo route. The route with email verification, password rules, and the load you stopped noticing eight releases ago.
- Watch five real sessions end to end. Recordings or live, it makes little difference. Do not narrate and do not explain. Note the first hesitation, because that is the sentence to rewrite.
- List the findings, then order them. Severity and priority are not the same property, and treating them as one is how a list of thirty items produces no change whatsoever.
That last step is where most internal audits quietly die. A findings list with no ordering is a document, not a plan. Every entry needs what broke, how badly, and what to do about it, which is the discipline set out in the anatomy of a finding. A tool such as Prooflin exists for exactly that shape of work: findings, severities, priorities and recommendations resolved into a report somebody can review and act on.
Watch five sessions without speaking. Teams that skip this step rewrite the screen they already suspected and leave the screen that is actually losing people, because the screen that loses people rarely looks broken to the person who built it.
What your instrumentation will not tell you
Event tracking answers "where" with great precision and "why" not at all. It will tell you the integration screen is the last event in most abandoned sessions. It will not tell you whether the user could not find the button, did not hold the credentials, or decided the request was unreasonable for a product they met four minutes ago. Three causes, three different fixes, one identical chart.
This is also why an audit delivered as a dashboard tends to change nothing. A number tells you a thing is true; it does not tell you what to do on Monday. Our parent company has written about reading an audit you were sold, and the same scepticism applies to the ones you produce internally about your own product.
There is an honest limitation in all of this, and ignoring it wastes months. A share of every sign-up cohort was never going to stay: competitors reading your pricing, students, the merely curious, and people evaluating for a project that was cancelled the same week. No first screen converts them. Chasing them distorts the whole exercise. The cohort worth studying is narrower, and it is the group who match the description of a customer, completed sign-up, and left without ever reaching the outcome. If your analytics cannot isolate that group, isolating it is the more useful project this quarter.
When the plan is the problem, not the product
Sometimes the first session is clean and people still do not come back, because the shape of the offer does not fit what you sell. A trial that expires before the work it supports can realistically be finished is not a trial, it is a deadline. A free tier generous enough to solve the entire problem is not a funnel, it is a product you are giving away. That decision is set out in free trial or freemium, and it deserves a deliberate answer rather than an inherited one.
The related failure is a price nobody can place. When a visitor cannot work out whether you are the cheap option or the serious one, they postpone the decision, and postponement looks precisely like churn in your charts. That is a positioning question wearing a pricing costume, which is why we treat pricing a product nobody has compared yet as a brand exercise as much as a commercial one.
One diagnostic separates the two failures cleanly. If people reach the promised outcome and still do not return, the problem lives in the offer, the price or the frequency of the underlying need. If they never reach it, the problem lives in the first session, and no pricing change rescues it.
Bringing back the ones who left
Lifecycle email is where most teams reach first, and it is the right instrument applied at the wrong moment. A sequence that says "you have not finished setting up" is a reminder of the exact failure that caused the exit. A sequence that says "here is the report we ran on your sample data" delivers the promise late, which is an entirely different message. That distinction is the part of lifecycle marketing worth paying for.
Send fewer messages. Make every one of them carry a finished thing rather than a request for more effort. If a message cannot contain a result, it can probably wait until you have one to send.
Where we would start
If you can only do one thing this month, do this: remove the setup steps standing between sign-up and the first sight of the promised outcome, and replace the empty state with a sample workspace that already contains it. In most products that is a seed script, a routing rule and a week of nerve. It changes the first session more than any amount of tooltip copy ever will.
If you can do two things, add the vocabulary pass. One object, one name, on the page and on the screen. It is unglamorous work that nobody puts on a roadmap, and it removes friction the team can no longer perceive.
And if the audit shows a first session that is already short, clear and honest, and people still leave, then stop working on onboarding. The promise itself may be one nobody needed kept. That is a harder conversation and a far more useful one, and it belongs with whoever owns the product roadmap rather than with the onboarding backlog. If you want a second pair of eyes on a first session, send us the sign-up link and tell us what the page promised before it.
Common questions.
What counts as activation in a SaaS product?
Activation is the moment a new user reaches the specific outcome your marketing promised, not the moment they finish signing up or tick off an onboarding checklist. A useful activation definition names one observable event, happens inside the first session wherever possible, and would embarrass you if somebody hit it without getting real value. Teams that define activation as completed onboarding end up optimising the checklist instead of the outcome.
How many onboarding steps are too many?
Any step that does not make the next screen better for the person completing it is one step too many. Email verification usually earns its place. Workspace naming, teammate invitations, industry pickers and use-case questionnaires usually do not, because they serve your data model rather than the visitor. Move them behind the first result, where a user who has seen value now has a reason to answer.
Should a new account start with sample data?
In most products, yes. Sample data removes the empty state from the first session and lets a new user see the promised outcome before making a single configuration decision. Label it clearly as sample content and make it deletable in one action. The exception is a product whose value depends entirely on the customer records themselves, where shortening the import path is the better investment.
How do I find out why users leave without asking them?
Watch complete session recordings instead of reading funnel charts. Analytics reliably tells you which screen was last; it cannot tell you whether the person missed a button, lacked the credentials, or found the request unreasonable, and those three causes need three different fixes. Five sessions watched end to end, without narrating or excusing anything, will usually name the sentence that needs rewriting.
Is poor retention after sign-up a marketing problem or a product problem?
It is a product problem when users never reach the promised outcome, and a marketing problem when they reach it and still do not return. The first case means the first session is too long, too abstract, or aimed at the wrong task. The second means the offer, the price or the frequency of the underlying need does not match what you built. Diagnose which one before changing anything.
Do onboarding emails bring inactive sign-ups back?
Sometimes, but only when each message delivers a result rather than requesting one. A reminder that setup is incomplete simply repeats the failure that caused the exit. A message containing the report, summary or finding the product would have produced hands over the promised outcome late, which is a different proposition entirely. Send fewer messages, and make every one of them carry something finished.
How small a sample is useful for a first-session audit?
Five sessions is enough to find the largest problem, and one honest run through your own sign-up on a fresh account is enough to find several. Small samples are unreliable for measuring how big an issue is and quite reliable for finding what causes it, which is what an audit needs. Save the statistical questions until after you have fixed what five people all tripped over.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.