SaaS onboarding drop-off looks the same in every report: sign-ups keep coming, yet days later the trial accounts are empty. The activation count alone will not show where people stopped. You need a few checkpoints, one event you treat as activation, and recordings from the exact place where the path breaks off. Then you look at a specific screen instead of blaming pricing or trial length.
This guide covers diagnosis with data, from defining goals to verifying a fix. Helping someone who has already written in is covered in our guide to live chat during a SaaS free trial. The example uses a fictional staff scheduling app; goal names and numbers are illustrations, not real results.
How to find where trial users stall
The stalling step is usually the first goal after the last one most trial users still reach. You find it by comparing completions of consecutive goals over one period; the cause only shows up in recordings. The process has five steps.
- Set 3–5 goals and one activation event.Each goal is an account state you can verify; activation is the first result the user signed up for.
- Find the last goal people reach.Compare completions over one date range and mark the steepest decline.
- Watch two groups of recordings.People who stopped at that step and people who passed it, on the same screen and device type.
- Name the behaviour, then the cause.Tag loops, hesitation and dead clicks, then decide: copy, a missing prerequisite or a silent error.
- Fix one thing and compare.Measure the same goal ratio in equal periods before and after the change.
A few onboarding goals and one activation event
An onboarding goal should confirm a change of state, not a screen view. "Opened the staff import" says less than "saved at least one employee". Finishing a product tour is not activation either; activation is the first result the account was created for. In the fictional scheduling app, that is publishing the first rota, because only then does the team receive something.
Scroll the table sideways to see all columns.
| Goal key | What it confirms | When to record it |
|---|---|---|
| account_confirmed | The user can log in | After email confirmation |
| company_configured | A location and opening hours exist | After settings are saved |
| staff_added | At least one person is listed | After the server responds, not on click |
| rota_published | Activation: the first rota reached the team | After publication is confirmed |
In Meetlead Analytics you first define goals in the panel, as an event or a visited URL. Your app then calls meetlead.goal with the goal key, and the widget records only keys configured in advance. Fire the goal once, on the first save the server confirms: every call counts as a completion, and firing on click also counts failed attempts. If your app switches screens without a reload, check page tracking in a single-page app first.
The last goal reached shows the place, not the cause
Pick one date range and note the completions for each goal. Fictionally: 400 confirmed accounts, 310 configured companies, 90 accounts with staff and 70 published rotas. The biggest loss sits between configuration and adding staff, so that is where you start, even if the team has suspected the rota editor for months.
Meetlead counts goal completions rather than people, and SaaS onboarding often spreads across several days and visits, so this is not a strict funnel for one person. When people skip or revisit a stage, settle the counting rules with our guide to funnel step order. If users are identified with meetlead.identify, the customer journey shows that person's later visits and the stages reached.
Compare recordings of people who stalled and people who passed
The first group is visits to the step's screen with no next goal afterwards. Filter the recordings list by that screen's address, device and date, then use the customer journey to see whether staff were saved later. The second group reached the goal; you get to their sessions through the goal drilldown in Analytics. Compare both on the same device type, because a failure on a phone next to a success on a desktop explains nothing.
PostHog's onboarding guide suggests also watching users who completed the step, since they may have pushed through the same friction. PostHog: App onboarding drop-off. Its recording counts are the authors' rules of thumb, not a threshold for your product.
Do not watch at random. Write down a question such as "what do people do after opening the import without saving anyone?" and stick to it, as our guide on how to analyse session recordings explains. Check your plan too: Starter stores no recordings, Growth keeps them for 14 days and Scale for 90. With the shorter history, review them weekly.
Tag behaviour before you name a motive
"The user lost interest" is an interpretation no recording confirms. Note what you see in a comment at the exact moment of the recording, using names the whole team shares. After a dozen sessions you can count which behaviour repeats in the group that stalled and rarely appears in the other.
- Loop: switching between two screens, such as import and settings, without saving
- Hesitation: the cursor or finger hovers over a button that is never clicked
- Dead click: a click on an element that does not respond or is disabled or is disabled
- Silent error: a save with no message, after which the list is still empty
- Exit to help: opening the docs or chat exactly at this step
You spot dead and rage clicks manually by checking how the page responded; our guide to rage clicks and dead clicks sets out the rules. Never copy values users typed into fields into comments. The action and the screen's response are enough.
Copy, a missing prerequisite or a silent error
Most onboarding stalls fall into one of three groups, and each needs a different fix, so decide which one you face before planning work. If signals point to two, start with the one covering more recordings.
Scroll the table sideways to see all columns.
| Cause | What recordings show | Typical fix |
|---|---|---|
| Unclear copy | Hovering over a button, reading and going back, picking the wrong option | New label, example or field order |
| Missing prerequisite | A loop to another screen, leaving to fetch a file or data | Announce the requirement earlier, a template, sample data |
| Silent error | Clicking save with no change of state, repeated attempts | Fix the bug and show a visible message |
In the fictional example, recordings show a loop: the user opens the import, sees it needs a CSV file with a job title column, and returns to company settings. That is a missing prerequisite, not bad button copy. Our guide to instruction prerequisites shows how to state such requirements before step one. The fix might be a downloadable template or adding one person by hand.
Help only on that step, then compare before and after
Show guidance where people stall, not on every screen. If the Meetlead widget runs inside your app, an automation can open a proactive chat after a visit to the import address and a set time on the page. Keep the message to one requirement.
The import needs a CSV file with a job title column. Don't have one? Add one person manually and publish a test rota, then import the rest of your team later.
Chameleon notes that in-app tours and prompts will not fix a broken or confusing core flow, so the product comes first. Chameleon: onboarding drop-off. It does not prove which route will work in your app.
Turn the observation into a task: in Projects you can link the recording to a task, so whoever ships the fix sees the same moment. After release, compare the ratio of staff added to configured companies in equal-length periods before and after, with no parallel campaign. Change one thing at a time, or you will not know what worked. Then watch a few new recordings of the step and check whether the loop is gone.
Questions about onboarding drop-off
How many recordings do I need before I accept a cause? There is no fixed number. Watch until you can describe a behaviour that repeats in the group that stalled and name the sessions that do not fit. If every recording looks different, narrow the device, screen or period. A conclusion from one session is a hypothesis.
Is adding a product tour enough? Only when the cause is unclear copy. A tour will not remove a missing prerequisite or a silent error, and on every screen it gets in the way of people who cope alone. Find the cause in recordings first, then pick the fix and measure it on the same goal ratio.
