Funnel Analysis

You find where people drop out on the way to buying or activating, which drop costs the most money, and why it happens. The output is a short ranked list: fix these three things first, here is the evidence, here is what each is worth. Numbers come from the owner's own data with clear definitions; benchmarks from other companies are context at most.

When to use

• "Where are we losing customers?"
• "Conversions dropped last month. Why?"
• "What should we fix first on the site / in onboarding?"
• "Our trial-to-paid rate is low."
• Before a growth or conversion sprint.

What you need

• The funnel's steps and the event or record that marks each one: for a shop, session, product view, add to cart, checkout start, purchase; for SaaS, visit, signup, activation action, paid; for B2B, visit, lead, qualified lead, opportunity, won.
• Data access: Google Analytics, PostHog or Mixpanel (connected apps) for site and product events; HubSpot, Salesforce or Pipedrive for sales stages; Stripe or the store backend for orders. Otherwise the owner's signed-in browser or CSV exports.
• Value per conversion (order value and margin, or customer value) to put money on each leak.
• Qualitative sources if they exist: session recordings or heatmaps from a free tool the owner already uses, on-site survey answers, support tickets, sales call notes, user test videos.
• Known changes: releases, price changes, campaigns, tracking changes, with dates.

Method

1. Define the funnel precisely. Write each step's event name, counting unit (user, session, account) and the time window allowed between steps (for example purchase within 30 days of first visit). Use the same unit throughout or the rates mislead.
2. Check data quality first. Look for steps with more people than the step before (tracking duplication), sudden zeros (broken tags), bot spikes, internal traffic, and sampling in reports. Compare purchases in analytics with the store's real orders; a gap of more than about 10 to 20 percent means the analytics funnel is undercounting and needs a caveat.
3. Build the funnel table. For each step: count, step conversion (step / previous step), cumulative conversion (step / first step), and drop-off count. For a period of at least 4 weeks to smooth weekly noise; compare with the previous period and the same period last year if seasonal.
4. Segment. Repeat the table by traffic source and medium, device type, new versus returning, landing page, country, and weekly signup cohort. A leak that only appears on mobile or in one channel tells you where to look. Keep segments large enough to be meaningful (hundreds of users at the step, not dozens).
5. Value each leak. For each step, estimate the money from a realistic improvement: people reaching the step x (target step rate - current step rate) x downstream conversion from the next step x value per conversion. Use as target the rate of your own best segment or best recent period, not an outside benchmark. Code in references/funnel-template.md.
6. Diagnose the top leaks. For the 2 or 3 most valuable leaks, gather qualitative evidence: watch 10 to 20 session recordings of people who dropped at that step, read survey answers and tickets that mention it, walk the step yourself on mobile and desktop with browser_navigate and browser_snapshot, check speed and errors. Write each cause as an observation with evidence, not a guess.
7. Generate fixes and tests. For each cause, list fixes. Obvious bugs and broken steps get fixed straight away (no test needed). Uncertain improvements become test hypotheses (see also ab-test-design). Score each idea with ICE (impact, confidence, ease, 1 to 10 each).
8. Report. One page: funnel table, segment findings, top 3 leaks with money value, causes with evidence, ranked fixes. Put the funnel and the top leak values on a show_card.
9. Monitor. Set a cronjob to rebuild the funnel weekly and flag any step whose rate moves more than an agreed threshold (for example 20 percent relative) against its 4-week average.

Output

• Funnel definition table (step, event, unit, window).
• Data quality notes and caveats.
• Funnel table overall and by key segments (template in references/funnel-template.md).
• Top 3 leaks: value in money, evidence, likely causes.
• Ranked fix and test list with ICE scores and owners.
• Monitoring set-up.

Checks before you finish

• Every step's definition and counting unit is written down and consistent.
• Analytics totals were reconciled with real orders or records, and the gap stated.
• Segments used have enough volume to support a conclusion.
• Each leak's value is calculated from the owner's data, with the formula shown.
• Causes are backed by evidence (recordings, tickets, walkthrough), not assumption.
• Bugs are separated from hypotheses that need testing.

Pitfalls

• Mixing units. Sessions at the top and users at the bottom produce nonsense rates. Pick one unit.
• Chasing the biggest percentage drop. The largest drop is often at the top of the funnel where intent is low. Rank leaks by money, not percentage.
• Benchmark anxiety. Industry averages hide huge variation. Compare with your own best segment and best period.
• Trusting broken tracking. Fix or caveat data issues before concluding anything.
• Averages hiding segments. A stable overall rate can conceal mobile collapsing while desktop improves.
• Jumping to solutions. Watch what people do at the leak before proposing fixes.
• Changing the live site without approval. Recommend fixes; the owner and developers decide and ship.