Funnel Analysis in SQL

A funnel is just a sequence of conditional counts, each one a subset of the one before it. Once you see that, funnels stop being a special kind of analysis and become an application of everything in Module 2.

Say your funnel is: signed up, completed onboarding, invited a teammate, upgraded to paid. A simple approach uses conditional aggregation:

SELECT

COUNT(*) AS signed_up,

COUNT(CASE WHEN onboarded_at IS NOT NULL THEN 1 END) AS completed_onboarding,

COUNT(CASE WHEN invited_teammate_at IS NOT NULL THEN 1 END) AS invited_teammate,

COUNT(CASE WHEN upgraded_at IS NOT NULL THEN 1 END) AS upgraded

FROM users

WHERE signup_date >= '2026-01-01';

This gives you one row with four numbers, and from there, each step's conversion rate is just division: completed onboarding divided by signed up, and so on.

THE FUNNEL MISTAKE THAT LOOKS RIGHT AND ISN'T

A funnel implies order: you can't upgrade to paid before you signed up. But nothing about the query above enforces that a user actually passed through steps in sequence rather than, say, having a data quality issue where upgraded_at is populated but onboarded_at accidentally isn't. Real funnels, especially ones built from event logs rather than clean status fields, need to explicitly define what "reaching a step" means and confirm the data reflects true sequence, not just "this field happens to be non-null." Before presenting any funnel, sanity check that the numbers only ever shrink (or stay flat) from step to step. If step three is larger than step two, something in your definition is broken, not your product.

Reporting both columns, conversion from the previous step and conversion from the very top, matters because they tell different stories. A 40% jump from "invited teammate" to "upgraded" looks strong in isolation, but if only 18.5% of signups ever reach that step, the real opportunity might be earlier in the funnel, not at that final conversion point.

YOUR MOVE THIS WEEK

Pick a three or four step funnel in your own product. Write out, in plain English first, exactly what event or field defines "reached this step." If you can't state it precisely, that ambiguity is exactly what will make your query's numbers arguable later.