Session replay for SaaS onboarding

- 0:00 session start · /signup · viewport 1512×982
- 0:14 typed in a field (value masked at source)
- 0:31 click button "Create account"
- ⚠ 0:32 POST /api/signup · 422
- 0:39 typed in a field (value masked at source)
- 0:44 click button "Create account"
- ⚠ 0:45 POST /api/signup · 422
- ⚠ 0:47 rage click ×3 · button "Create account"
- ⚠ 1:12 typed into a form but left without submitting (heuristic)
- 1:18 session end · total 1:18

Activation is the metric everyone tracks and nobody can debug. You can see the drop between signup and first action. You cannot see what happened in the ninety seconds where it went wrong.

Why funnel analytics cannot answer this

A funnel tells you 100 people started signup and 61 finished. It cannot tell you whether the 39 were tyre-kickers, hit a validation error, never got the verification email, or gave up on a form that asked for a company VAT number before letting them see the product.

Those four require completely different fixes. The funnel treats them identically.

Worse, the people who dropped out are precisely the ones who will never tell you. Your feedback comes from activated users — the survivors of whatever the problem is. You are systematically getting product feedback from the group that did not experience it.

The signal that matters most

Of everything on an onboarding flow, form abandonment is the one to watch.

UserTapes marks a session where someone typed into a form and the session ended without a submit. It is a heuristic, and it is the closest thing to a direct report of frustration you will get without asking.

Someone who typed and left did not bounce. They tried. They filled in fields, formed an intention to sign up, and something between that intention and the submit button stopped them. That is a much stronger signal than a bounce, and it is completely invisible to analytics because no event fired.

The transcript above is the canonical version: two 422s on the same endpoint, three rage clicks, then typing and leaving. Eighteen of twenty-three sessions that week had the same shape. The cause was password complexity enforced server-side with no client-side hint — the form said nothing about what was required and nothing about what was wrong.

That is a ninety-minute fix that had been silently costing most of a week’s signups.

What to look at, in order

1. Sessions that ended on the signup URL without reaching your post-signup route. These are your failures, by definition. Start here.
2. Of those, the ones with form abandonment. People who tried and stopped.
3. Of those, the ones with a failed request. Now you have the cause, not the symptom.
4. Then the ones with no failed request at all. These are the interesting ones — nothing broke, and they still left. That is a design problem, and watching two of them properly is worth more than reading a hundred transcripts.

Most teams start at step four because it feels like the real research. Start at step three: fix the things that are actually broken first, then look at the design once the noise is gone.

The verification-email dead end

Worth calling out separately because it is common and completely invisible.

A user signs up, lands on “check your email”, and waits. The email is in spam, or delayed, or never sent because of a provider issue that did not raise an alert. They reload the page a few times. Then they leave.

Nothing in your system records this as a failure. The signup succeeded. The send succeeded. Your funnel shows a user who created an account and did not activate, which looks like disinterest.

In a transcript it looks like ⚠ reloaded the page ×3 on the verification screen, which is unambiguous. If you see that pattern more than occasionally, your deliverability is the activation problem, not your onboarding design.

Turning it into a standing question

The workflow that makes this stick is not opening a dashboard weekly. It is asking once and then getting told.

Connect UserTapes to Claude Code or Cursor over MCP, ask the question in the example above, and let the agent set an alert on the signup URL so it comes to you. The agent that finds the 422 is the same one that can go add the client-side validation.

$ claude "why are people dropping out of signup this week?"

▸ usertapes list_tapes(url_contains: "/signup", has_errors: true)
  ← 23 tapes · 18 ended without reaching /welcome
▸ usertapes read_transcript(7b02e5d1)
  ← 0:32 ⚠ POST /api/signup · 422 (×2)
▸ 18 of 23 hit 422 on password complexity. The rule is enforced
  server-side only — the form shows no requirements and no error.

<script src="https://usertapes.com/tapes.js"
        data-token="YOUR_SITE_TOKEN" async></script>