Funnel Analysis: Finding Where People Actually Drop

Funnel analysis is the practice of counting how many people reach each step of a defined sequence, and where they stop. It sounds like arithmetic. It is mostly definitions. Two analysts can pull the same events from the same database and report conversion rates that differ by twenty points, and both can be technically correct, because they made different choices about who enters the funnel, how long people get to finish it, and whether the steps must happen in order.

This guide is about those choices. Getting them right is the difference between a funnel that tells you where to spend next quarter and a funnel that sends a team to rebuild a checkout page that was never the problem.

What funnel analysis actually measures

A funnel is four decisions, not one query.

The entry population. Who is in the denominator? Everyone who hit the site, everyone who started a session on a specific page, everyone who created an account in a specific month, everyone from paid search? The moment you change the entry criteria, every downstream rate changes. A funnel that starts at "landed on the pricing page" will always look healthier than one that starts at "landed on the site", and neither number is wrong. They answer different questions.

The step definitions. What event counts as "reached step 3"? A page view, a button click, a backend record, or a state change?

The ordering rule. Must the steps happen in sequence, or does any occurrence of each step count?

The conversion window. How long does a person have to finish before you call them dropped?

Write these four down at the top of every funnel you publish. Most funnel disagreements inside a company are not disagreements about the product. They are two people using the same word for two different definitions.

Define the steps before you define the funnel

Step definition is where most funnels go wrong, and the damage is invisible because the chart still renders.

Measure intentions, not pages

A page view is a weak step. Someone can land on /checkout by accident, by refresh, by back button, or because your app redirects there after login. Prefer steps that represent a commitment: "submitted email", "added payment method", "clicked place order". Backend events are stronger than client events for anything that creates a record, because they survive ad blockers, flaky mobile connections, and analytics scripts that fail to load.

A practical rule: if a step can fire without the user deciding anything, it is not a step. It is context.

Kill steps that everyone passes and steps that anyone can skip

If 99.6% of people who reach step 2 reach step 3, step 3 is not a step. It is noise that makes your funnel look longer and your drops look smaller. Remove it or merge it.

The opposite failure is worse. If a step is optional, for example an onboarding survey some users skip entirely, including it in a strict funnel makes your conversion rate collapse for a reason that has nothing to do with revenue. Optional steps belong in a separate analysis, not in the main sequence.

Watch for double-firing and renamed events

Two classic instrumentation bugs quietly destroy funnels. The first is an event that fires on component render rather than on interaction, so it counts users who never acted. The second is an event that gets renamed or versioned during a release, so the step goes to zero on a Tuesday and someone spends a week investigating a product problem that is a tracking problem.

Before you interpret any drop, check whether the step's raw event volume changed shape at the same moment as a deploy. If it did, fix the instrumentation first.

Name steps so a non-analyst can audit them

"Step 3" tells nobody anything. "Payment method saved (backend, first occurrence per user)" tells everyone exactly what they are looking at, including the ordering and occurrence rules. If your event taxonomy is inconsistent across sources, that is a modelling problem before it is an analysis problem, and the fix lives in your definitions layer. Our guide to data modelling tools covers how teams keep those definitions in one place instead of six dashboards.

The time window trap

Every funnel has a clock, whether or not you set it deliberately.

If you do not set a window, you are implicitly using "as of the moment I ran the query", which introduces right censoring: recent cohorts have had less time to convert than older ones, so the most recent weeks always look worse. Teams see the last three bars sloping down, panic, and start a redesign. Then the numbers fill in over the following month and the slope disappears.

There are three defensible approaches.

The way to pick N is empirical, not aesthetic. Take historical converters, measure the distribution of time from entry to completion, and set the window near the point where additional time stops adding meaningful volume, commonly around the 90th percentile. If half your paid conversions happen more than seven days after signup, a seven day window is not a measurement, it is a decision to ignore half your revenue.

Then apply the maturity rule: only compare cohorts that have fully passed the window. If your window is 14 days, the last 14 days of cohorts are provisional. Mark them as provisional in the chart, or exclude them.

The attribution traps that quietly break funnel analysis

Funnel analysis and attribution answer different questions. A funnel asks where people stop inside a journey. Attribution asks which touch deserves credit for the journey happening at all. Mixing them produces confident nonsense.

Identity stitching creates fake drops

The most common phantom cliff in a product funnel sits exactly at the login or signup step. Before it, you are tracking anonymous identifiers. After it, you are tracking user IDs. If the two are never joined, everyone appears to vanish at authentication and reappear as brand new users on the next step.

Check this before believing any drop at an identity boundary. Ask what fraction of known users have a linked pre-signup anonymous identifier. If that fraction is low, your top of funnel and your product funnel are two disconnected datasets wearing one chart.

Cross-device does the same thing more subtly. Someone researches on a phone and buys on a laptop. Device segmented funnels will show mobile as a research surface with terrible conversion, which is true only in the narrow sense that the purchase happened elsewhere.

Channel labels are usually last touch in disguise

When you segment a funnel by acquisition channel, ask which touch the label came from. Most default setups stamp the last non-direct source. Retargeting and branded search sit near the end of the journey by construction, so they inherit credit for conversions that other channels created. The funnel then says "retargeting converts brilliantly", and someone moves budget into a channel that mostly intercepts people who were already coming.

If you are using funnels to allocate spend, say plainly which attribution model produced the labels, and treat channel level conversion rates as directional rather than as truth.

Users, sessions, and accounts are three different funnels

Session funnels answer "does this flow work in one sitting". User funnels answer "do people eventually get there". Account funnels matter in B2B, where five people from one company each start a trial evaluation and the buying decision is made once. Counting users in a B2B funnel makes multi-stakeholder deals look like mass abandonment. Roll up to the account and the picture inverts.

Pick the unit that matches the decision you are about to make, and label it in the chart title.

Segments: the average funnel is nobody's funnel

An aggregate funnel is a weighted average of populations that behave nothing alike. That average can move for reasons that have nothing to do with the experience.

This is Simpson's paradox in its most practical form. Suppose mobile converts worse than desktop at a given step, and both improve slightly after a release. If the same release coincides with a traffic campaign that shifts your mix heavily toward mobile, the blended conversion rate falls. Every segment improved and the headline number got worse. If you only look at the aggregate, you will roll back a change that worked.

Always cut a funnel at least four ways before drawing conclusions:

• Device and platform. Mobile web, desktop web, and native app usually have different failure modes, particularly around forms and payment sheets.
• Acquisition source. Intent differs enormously. Comparing a comparison-shopping visitor to someone arriving from a referral is comparing two products.
• Geography and locale. Payment method availability, currency display, address formats, and translation gaps produce sharp local drops that are invisible in the global number.
• New versus returning. Returning users skip steps and have saved state, which flatters any funnel that includes them.

For B2B products, add company size or plan intent. For marketplaces, add supply side and demand side separately.

When you build the segment comparison, resist the tapered funnel graphic. The classic funnel shape encodes value in area, which distorts the differences you actually care about, and it makes two segments almost impossible to compare side by side. A grouped bar chart of step level conversion rates, or a set of small multiples with one panel per segment, communicates the same data far more accurately. If you are choosing a format, examples of charts and different types of charts both cover which shapes hold up when you need to compare rates rather than admire them.

Choosing which leak to fix first

The biggest percentage drop is rarely the best thing to fix. Three factors matter more.

Absolute users lost. A 60% drop at a step only 800 people reach loses fewer people than a 12% drop at a step 40,000 people reach.

Downstream value. A user lost at step 2 would have had to survive steps 3, 4 and 5 anyway. The recoverable value of fixing a step is roughly the users lost there, multiplied by the historical conversion rate from that step to the end, multiplied by the value of a conversion. A large drop early in a funnel with a weak tail is worth less than it looks.

Tractability. Some drops are structural. People who land on your pricing page from an unrelated search were never going to buy. You cannot fix intent with copy.

Score candidates in a table before anyone opens a design file.

Fill this in with your own numbers and the argument usually settles itself. Note the third row: an optional step with a huge apparent drop and a weak tail, which is a strong candidate for removal from the funnel definition rather than a redesign.

One more filter before you commit. Ask whether the drop is a measurement artifact. Run the same funnel from backend records instead of client events. If the cliff shrinks, you were looking at tracking, not behavior.

The SQL side of it

Most funnel queries reduce to the same pattern: for each entrant, find the first occurrence of each step event after entry and inside the window, then flag whether it exists. Window functions and conditional aggregation do the work. Long chains of nested conditionals are where these queries become unreadable and slow, and the patterns for keeping them clean are covered in SQL CASE WHEN.

Two implementation details worth stating explicitly in the query: use the first occurrence per user per step unless you have a reason not to, and enforce ordering with timestamp comparisons rather than assuming event tables arrive sorted.

Making funnel analysis a habit instead of a quarterly project

Funnels decay. Definitions drift, events get renamed, a release changes a step's meaning, and the analysis that took three days in March is wrong by June. The teams that get value from funnel analysis are the ones who look at it weekly, cheaply, and notice movement early.

Two honest notes about where Skopx fits here.

First, Skopx is not a BI tool. It does not build drag-and-drop dashboards or funnel visualizations. If you want a maintained visual funnel with segment filters that a whole team browses, a dedicated product analytics or BI tool is the right purchase, and this article is not going to pretend otherwise.

Second, a lot of funnel work is not visualization. It is asking a specific question against a database, checking whether a step moved, and telling someone when it does. Skopx does that part in chat. It queries PostgreSQL, MySQL and MongoDB directly, pulls context from your other connected tools across nearly 1,000 integrations, and cites where each answer came from.

A concrete example. In Skopx chat you would type:

Query the analytics Postgres. For signups in the last 10 weekly cohorts, show the share who verified email within 3 days, connected an integration within 7 days, and ran a workflow within 14 days. Split by device. Mark the last two cohorts as not yet mature and list any cohort where a step is more than 5 points below its 10 week average.

What comes back is a cohort table with the three step rates by device, the immature cohorts flagged rather than silently included, and a short written note naming the cohorts that fell below trend, with the query it ran so you can check the definitions yourself.

From there you can describe a recurring version in plain English and Skopx builds it as a scheduled workflow: run the query weekly, compare against the trailing average, and post to Slack only when a step moves beyond your threshold. Workflows are built by describing them, not by dragging boxes, and every run is inspectable step by step. They also have real limits worth knowing: a maximum of 20 steps, no loops, no custom code steps, no human approval gates, and AI steps run on your own provider key. Details are on the workflows page.

Skopx is paid from day one, with no trial tier: Solo is $5 per month and Team is $16 per seat per month with no seat cap, listed on pricing. You bring your own AI provider key and Skopx adds no markup on model usage.

Skopx catches what falls between your tools. Funnel drift is exactly that kind of thing: visible in a database nobody opens on a Tuesday, invisible in the tools where the work happens.

Frequently asked questions

What is the difference between funnel analysis and cohort analysis?

Funnel analysis measures progression through an ordered sequence of steps. Cohort analysis measures how a group defined by a shared starting point behaves over time, usually retention. They combine well: run your funnel by entry cohort so you can see whether the drop at step 3 is getting worse for people who arrived recently, or whether it has been constant for a year.

How long should my conversion window be?

Derive it from your own data rather than picking a round number. Measure time from entry to conversion for historical converters and set the window near the 90th percentile of that distribution. Then treat any cohort that has not fully passed the window as provisional, and mark it that way in every chart so nobody reads censored data as a decline.

Should a funnel count users or sessions?

Count sessions when the flow is meant to be completed in one sitting, such as checkout. Count users when the decision spans days, such as onboarding or trial evaluation. Count accounts when the buying decision is made by a group rather than an individual, which is the normal case in B2B. Using the wrong unit is the single most common cause of a funnel that contradicts what sales and support observe.

Why did my funnel conversion rate drop when nothing changed in the product?

Check mix shift first. If traffic composition moved toward a lower converting segment, the blended rate falls even when every segment improved. Then check instrumentation: an event renamed or moved in a release will produce a cliff on the deploy date. Then check censoring. Only after those three should you look for a real behavioral change.

Can Skopx build a funnel chart or dashboard?

No. Skopx does not build dashboards or visualizations, and a dedicated BI or product analytics tool is the right choice for a maintained visual funnel. What Skopx does is query your databases and connected tools in chat, return the numbers with their sources, surface changes in a daily brief, and run scheduled workflows that alert you when a step moves.

Do the steps have to happen in strict order?

Not always, but you must decide and state it. Strict ordering is correct for genuinely sequential flows like checkout, where reaching payment without a cart is a data problem. Any-order counting is more honest for exploratory product journeys where users legitimately do things in different sequences. Reporting an any-order funnel as though it were sequential will systematically overstate how well your intended path performs.