Drop-off Analysis
From 'where users leave' to 'why they leave'
Finding the biggest drop-off is step one; explaining it is the craft — time-between-steps, error events, exit reasons and segment splits turn a leak location into a fixable cause.
What you will learn
- Quantify drop-off per funnel step and find the largest
- Use dwell-time, error events and exit analysis to explain a leak
- Propose a testable fix from evidence, not vibes
Drop-off analysis chains three questions: which step leaks the most (shape), who leaks there (segments), and why (time-in-step, errors, exit paths). The 'why' decides the fix.
What is this?
Drop-off analysis is the deep read of a funnel's losses. After locating the step with the largest relative loss, it explains that loss with: time-in-step distributions (users stuck 2 minutes on a 10-second step), error and validation events around the step, exit-tracking (which actions preceded leaving), and segment splits (the leak may live entirely in one segment). The output is a falsifiable hypothesis about the friction — ready for a fix and an experiment.
Why do you need it?
- Largest-drop reasoning shortcuts prioritization: fix the step that leaks most users.
- Where + who + why turns a chart into an action plan.
- Time-in-step reveals cognitive load — long dwell on a short step = confusion.
- Error events convert UX hypotheses from guesses into measurements.
Mental model
A highway bottleneck investigation
Drop-off analysis
Finding the traffic jam location is step one. The DOT then measures flow speed before it, checks for merging-zone signage, splits by lane and exit destinations — location, mix and cause — before repainting lanes.
How it works
- Compute step-by-step conversion; rank the relative drops to find the largest leak step.
- Measure time-between-steps for users who passed vs those who stalled, plus dwell within the leak step.
- Pull error events and validation failures around the step (form errors, API 4xx, blank screens).
- Split the leak by platform, channel, device, geography and cohort.
- Synthesize a cause hypothesis with evidence and pre-register the funnel metric it should move.
The drop-off investigation flow.
In production
- A checkout leak at 'payment method' traced to a slow 3DS redirect; dwell time and a support query spike made it obvious before a single user interview.
- A registration funnel's drop-off was isolated to iOS Safari by segment splitting; the cause was a cookie partition blocking the OAuth popup.
- A B2B trial funnel showed address-form dwell of ~6 minutes — a fax-era form with 22 fields; trimming to 6 fields lifted completion 30%.
Best practices
- Prioritize by absolute loss (users), not just relative rates — a 10% leak on a million-user step beats 80% on a hundred.
- Attach dwell-time baselines per step to spot 'normal' durations before diagnosing.
- Instrument error events at every step; UX-friction is mostly server errors wearing a UX costume.
- Write the fix as a testable prediction ('reduce checkout dwell by creating fewer form fields') and verify with the funnel.
Common mistakes
- Analyzing the funnel of an era without annotating the deploy/design changes that era.
- Confusing correlation of dwell with causation — long dwell can be multi-tab users, not confusion.
- Treating 'users left before step X' as a single cause when the exit is a mix of intent (comparison shopping) and friction.
- Fixing the largest relative step while a bigger absolute leak sits just upstream.
Debugging tips
- If dwell balloons at a step, pull the step's activity trail — form error count and scroll position often tell the story.
- 4xx/5xx spikes at a step are bug leaks; alert on them as their own metric.
- For mobile leaks, reproduce on the affected device class in a simulator before shipping the 'fix'.
- Cross-check with exit events: did users bounce elsewhere or stay engaged on an error toast?
Interview checkpoint
Hands-on lab
- Compute step conversion and rank the leaks
- Measure dwell-time signaling for the leak step
- Correlate errors with abandonment to build the hypothesis
Find and Explain the Biggest Leak with Dwell and Errors
35 min · intermediate
Quick quiz
Two steps leak: A loses 40% of 10,000 users; B loses 80% of 300. Which do you fix first?
A long time-in-step always proves users are confused.