Most funnels measure the product, not the user
Open a typical analytics tool and the funnels are built from whatever events the engineering team happened to instrument: route_loaded, account_created_v2, modal_opened. They're technically accurate and almost useless for product decisions, because they describe what the software did, not what the user was trying to do. A funnel that measures your codebase tells you when a component rendered; a funnel that measures intent tells you where someone gave up.
The fix is to build funnels backward from observed behavior — and to validate every step against real recordings before you trust a single number. Here's the workflow.
Name steps by user intent
The best funnels read like a user story: lands on pricing → starts signup → creates workspace → installs snippet → sees first recording. Each step describes progress from the user's point of view. Internal labels like account-created-v2 or dashboard-route-loaded are useful for code, but they hide intent from product review.
When a funnel is named in user language, everyone can spot the gap faster. If many users create a workspace but don't install the snippet, the next question is obvious — and you don't need an analyst to translate. A simple test: if a new hire can't read your funnel steps aloud and understand the user's goal, the steps are named for engineers, not for decisions.
Validate every step with recordings
Before treating a funnel as truth, watch sessions around each transition. The most common funnel bugs aren't in the chart — they're in the event definitions feeding it:
- Fires too early: the event triggers when a component renders or a route loads, not when the user actually completes the action — inflating that step and hiding the leak below it.
- Fires too often: a retry, re-render, or double-submit counts the same user twice, so conversion looks better than it is.
- Fires for the wrong reason: the event captures a side effect rather than the intended success state.
Session recordings are the fastest way to catch event definitions that look correct in a dashboard but fail in context. Watch three sessions per transition; if the event lines up with what the user clearly intended, trust the step. If not, fix the definition before you act on the data.
Read the drop-off, then go watch it
A funnel's job isn't to display a number — it's to point you at the recordings that explain the number. When a step leaks, don't redesign from a hunch. Filter to users who reached that step and abandoned, watch five of their sessions, and you'll usually find one of a small set of causes:
- A validation error or disabled button with no explanation.
- A required field or permission the user didn't have and couldn't resolve.
- A moment of confusion — the next action wasn't where they looked.
- Nothing wrong at all: they got what they needed and left satisfied (a “leak” that isn't one).
That last case is why funnels alone mislead. The number says “drop-off”; the recording says “success.” Only the pair tells the truth.
Keep one activation funnel sacred
Small teams should maintain one core activation funnel and review it weekly. Resist the urge to create a dozen overlapping funnels — they fragment attention and let everyone pick the chart that flatters their project. A focused funnel creates a shared operating rhythm: what changed this week, where did conversion move, and which sessions explain the movement?
Around that one sacred funnel you can spin up short-lived, disposable funnels for specific investigations, then archive them. The discipline is having a single number the whole team trusts and returns to, not maximizing the count of dashboards.
Frequently asked questions
Should funnel steps be page views or events?
Events, almost always. Page views describe navigation, not accomplishment — a user can load the “success” page without succeeding, or succeed inside a single-page app without a navigation. Define steps as the events that represent real user intent.
How many steps should a funnel have?
As few as tell the story — typically four to six. Each step should be a meaningful decision point. If two adjacent steps always convert together, merge them; the gap between them isn't teaching you anything.
Why does my funnel conversion look worse than reality?
Usually a step fires too early or counts the same user more than once, or you're not deduplicating by user. Validate each event against recordings, and confirm you're measuring unique users, not raw events.
Do I need session replay to use funnels well?
You can run funnels without it, but you'll be guessing at causes. Pairing each drop-off with the recordings behind it is what turns a funnel from a status report into a source of fixes. See session replay without the noise.