A systematic six-step process for moving from a funnel drop-off data point to a prioritised experiment. It exists because the gap between seeing a drop and fixing it is where most teams stall.
▸ Try the interactive toolThe funnel drop-off diagnostic is a systematic process for moving from a funnel drop-off data point to an actionable, prioritised experiment. It exists because the gap between seeing a drop-off and fixing it is where most teams fail: they collect funnel data, spot the drop, and then either guess at the cause or do nothing.
The diagnostic is a disciplined sequence: quantify the drop and its value, segment it (is it everyone, or one group?), form hypotheses about why, gather qualitative evidence (watch users hit the drop), prioritise the likeliest/highest-value cause, and design an experiment to fix it. The crucial discipline is resisting the leap from 'users drop here' straight to 'so let's change X' — the diagnostic forces you to understand the why (often through segmentation and qualitative research) before committing to a fix, because the obvious cause is frequently wrong.
Quantify the drop (users + value) → segment it (who drops?) → hypothesise the why → gather qualitative evidence (watch users) → prioritise the cause → design the experiment. Understand why before fixing.
Analytics shows where users drop but is silent on why — so teams either freeze (data with no action) or leap to an assumed cause that's often wrong.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Drop seen, never acted on | Funnel data collected but the gap to a fix never crossed. | The diagnostic provides the path from data to experiment. |
| Guessing the cause | Leaping from 'drops here' to an assumed 'why' that's often wrong. | Segmentation and qualitative evidence find the real cause. |
| Fixing the obvious thing | Changing what seems wrong without verifying it's the cause. | The diagnostic verifies the why before committing a fix. |
| Not segmenting the drop | Treating a drop as uniform when it hits one group hardest. | Segmentation reveals who drops, narrowing the cause. |
Measure the drop-off at the step — in users and in business value (per Tool 11). This confirms it's worth diagnosing before you invest effort.
Is everyone dropping, or one group (a channel, a device, a segment)? A drop concentrated in one group narrows the cause dramatically — often the most clarifying single step.
Brainstorm plausible causes — confusion, friction, a technical issue, a mismatch of expectations. Hold these as hypotheses to test, not conclusions to act on.
Watch real users hit the drop-off (usability testing, session replay, interviews). The analytics says where; only watching reveals why. This is the step teams most often skip.
Identify the likeliest, highest-value cause, then design an experiment (with a falsifiable hypothesis) to fix it. The output is a prioritised experiment, not a guess shipped as a fact.
A team saw a sharp drop at a funnel step and leapt to the obvious cause: the form was too long. They shortened it — and the drop barely moved. They'd skipped the diagnostic and acted on an assumed why.
Running the diagnostic properly, they segmented the drop (it was concentrated in one user group), then watched those users hit the step. The real cause wasn't length at all — users were confused about what one field meant and abandoned rather than guess. Segmentation plus qualitative observation found the true why, which the 'obvious' fix had completely missed. The right experiment — clarifying that field — moved the drop.
The deliverable is a drop-off taken from data through segmentation and qualitative evidence to a prioritised, hypothesis-driven experiment.
| Step | Answers | Method |
|---|---|---|
| Quantify | How big / valuable? | Funnel analytics |
| Segment | Who drops? | Cohort segmentation |
| Hypothesise | Why might they? | Team brainstorm |
| Observe | Why do they really? | Usability, replay, interviews |
| Experiment | Does the fix work? | A/B test |
The drop-off diagnostic bridges the gap where most funnel work dies — between knowing where users leave and actually fixing it. Its core discipline is refusing to act on the obvious cause until segmentation and observation have found the real one.
This is the funnel-specific application of analytics' fundamental limit: the numbers show where and how much, and are silent on why. The two steps teams skip — segmenting the drop and watching real users hit it — are precisely the ones that reveal the why, and they're skipped because the 'obvious' cause feels like knowledge. It isn't; it's a hypothesis wearing the costume of a conclusion, and acting on it produces fixes that don't move the metric. The diagnostic forces the cheap, decisive investigation (who's dropping, and what happens when you watch them) before any expensive fix, then ends in a falsifiable experiment rather than a shipped guess. It's the structured cure for the most common funnel failure: confident, wrong fixes.
The obvious why is often wrong. Segment and observe before fixing.
Analytics shows where, not why. Watch real users hit the drop.
A drop concentrated in one group reveals the cause. Always segment first.
The output should be a falsifiable experiment, not an assumed solution.
Funnels (Tool 11) find the drop worth fixing; the diagnostic explains and fixes it.
It's the funnel version of Module 3's 'analytics shows what, not why' (Module 3, Tool 09).
The observation step draws on usability testing and interviews (Module 3).
The output is a falsifiable hypothesis tested via A/B (Tool 17, Module 3 Tool 12).
AI helps work a funnel drop-off faster — generating the queries and proposing hypotheses — within the same systematic discipline.
The judgment that stays yours: The diagnostic discipline is unchanged: verify the drop is real, segment, then test hypotheses. AI accelerates each step but will also confidently propose a wrong cause — it's a hypothesis generator, not a verdict.
Imagine a sharp drop at a checkout step. Write down the 'obvious' cause that springs to mind — then treat it as just one hypothesis.
Describe the two diagnostic steps that would verify it: how would you segment the drop, and what would you watch real users do?
If your investigation could plausibly reveal a different cause than your first obvious guess, you've understood why the diagnostic insists on the why before the fix — the obvious cause is so often wrong.
Related · The Metric-Drop RCA →