Drop-off Analysis

Quantifying and diagnosing the users who exit between funnel steps —not just the rate, but the reason, so the drop-off is fixable.

Why

A funnel that shows '40% drop at step 3' is a symptom, not a diagnosis. The 40% is a number; the fix depends on why those users dropped. Some dropped because the step was confusing (fixable with UX), some because the step was slow (fixable with perf), some because they were not the right users (fixable with acquisition targeting), and some because they simply did not want the product (not fixable, and not a problem). Treating all 40% the same leads to generic 'improve step 3' efforts that move the rate by 2% when the fixable subset was 15% and the fix would have moved it by 10%. Drop-off analysis is the discipline of segmenting the dropped users by reason: looking at their last action, their session replay, their form errors, their device/browser, and their cohort attributes, to identify the dominant reason and the fixable subset. This turns '40% drop' into '15% hit a validation error on the email field, fixable by relaxing the regex', which is an actionable finding.

When

When a funnel step shows a drop-off rate > 20% and you need to decide whether to fix it. After any funnel definition change.

How

1. Identify the step with the highest drop-off rate (or the one that changed most vs. last period)
2. Pull the users who reached step N but not step N+1 (the dropped users), with their session data
3. Segment by last action: what did they do right before leaving? (clicked back, closed tab, idle timeout, error)
4. Segment by error: did they hit a form validation error, a 500, a payment decline? Group by error type and count
5. Segment by device/browser/OS: is the drop-off concentrated on Safari iOS? (likely a compat bug) or uniform? (likely a UX issue)
6. Segment by cohort attributes: are they from a specific source (e.g., a paid ad with misleading copy)? are they on a specific plan?
7. Watch 10-20 session replays of dropped users —this is the highest-signal step; you will see the confusion, the rage-click, the misread instruction that the numbers cannot show
8. Quantify the fixable subset: "of the 40% drop, 15% hit error X (fixable), 10% were on iOS Safari (fixable), 15% left idle (not fixable, possibly not a problem)" —the fixable subset is the target

Example

# Drop-off analysis: step 3->4 (project create -> first deploy)
Drop-off: 50% (3,224 of 6,448 project creators never deploy)
Period: 2026-09-01..2026-09-30

Segment by last action (n=3,224 dropped):
  clicked "Deploy" then got error:    968  (30%)
  navigated away from deploy page:   1,289  (40%)
  idle > 10min on deploy page:         645  (20%)
  other:                               322  (10%)

Segment by error (n=968 error users):
  "Build failed: missing env var":     580  (60%)  -> FIXABLE
  "Rate limit exceeded":               242  (25%)  -> FIXABLE (raise limit)
  "Payment required for deploy":       146  (15%)  -> by design

Segment by device:
  iOS Safari: 22% (vs 18% of all users) -> slight over-rep, not the main issue
  Chrome:     60% (vs 64%) -> under-rep, not the issue

Session replays (watched 15):
  8/15 users clicked Deploy, saw "Build failed", could not figure out how to
    add the env var, and left. The error message links to docs but the docs
    do not show the exact setting location.
  4/15 users were on the free plan, hit "Payment required", and left.
  3/15 users navigated away (possibly returned later, outside the 1h window)

Fixable subset: 580 users (60% of error) hit "missing env var" with a
  confusing error message. Fix: improve the error message with a direct
  link to the env var setting. Expected impact: recover 40% of these
  = 232 users = 3.6% of the 6,448 = 1.8pp funnel conversion lift.

Common Problems

⚠Reporting the drop-off rate without segmenting by reason —'40% drop at step 3' triggers a generic 'improve step 3' project that moves the rate by 2%, when 25% of the drop was fixable and the fix would have moved it by 10%.
⚠Skipping session replays and relying only on aggregate numbers —the numbers tell you 'users hit an error'; the replays tell you 'users hit the error, could not find the setting, and the error message links to the wrong docs'; the replay is the difference between knowing and understanding.
⚠Treating all drop-off as a problem —some users drop because the product is not for them (wrong plan, wrong use case), and 'fixing' their drop-off means acquiring users who will churn later; the fixable subset is the target, not the total drop.
⚠Analyzing drop-off once and never re-checking —the dominant reason changes over time (a bug is fixed, a new error appears), and the 6-month-old analysis leads the team to fix a problem that is no longer the main one.

Best Practices

✓Always segment the dropped users by last action, error type, and device —the segmentation is what turns '40% drop' into '15% hit error X, fixable by Y', and the fixable subset is what you target.
✓Watch 10-20 session replays of dropped users for every drop-off analysis —the replays surface the confusion and rage-clicks that numbers cannot, and they are the fastest path from 'users drop here' to 'users drop because X'.
✓Quantify the fixable subset and the expected impact before starting the fix —'580 users hit this error, fix expected to recover 40% = 1.8pp lift' is a prioritized, sized fix; 'improve the error message' is not.
✓Re-run the drop-off analysis quarterly —the dominant reason shifts as bugs are fixed and new features ship, and the analysis must reflect the current drop-off, not the one from 6 months ago.