A funnel is a question with counting rules
A SaaS conversion funnel measures how an eligible group progresses through a defined sequence of actions. Its usefulness depends on the rules: who can enter, which actions qualify, whether order matters, how long completion may take and which identifier represents a person or account.
A chart containing homepage views, signups and payments from the same month is not automatically a funnel. The payments may belong to last month’s signups. Pageviews may include repeat visits by one person. Begin with the actual journey you want to understand rather than the events most convenient to plot.
Choose a small sequence tied to value
For a fictional reporting product, a sensible activation funnel could be account created, data source connected, first useful report viewed. Payment can be a separate final outcome. A menu click is usually a diagnostic event, not the definition of success. If users can reach value without connecting a source, make that alternate path explicit rather than silently treating it as abandonment.
Choose whether the question is account-level or person-level. A team account may have one person install a tool and another purchase it. Combining them requires a documented, authorized account association. If your implementation only recognizes a browser session, call it a session funnel and do not pretend it measures people across devices.
Write down entry, order and time
A closed funnel requires entry through the first step. An open funnel admits people at later steps. Google’s funnel exploration documents this distinction and ordered-step behavior. Use a closed funnel when asking what happens to newly created accounts. Use an open view when exploring where people enter an existing journey.
Decide whether unrelated actions may occur between steps, whether repeated attempts qualify and whether a person is counted once or more than once. “Connected a source within seven days of signup” is reproducible. “Eventually activated” becomes a moving target as older cohorts receive more time. Store the definition beside the chart and version it when the product changes.
Example contract — synthetic reporting product
Unit: account ID, counted once
Entry: first successful account creation
Sequence: account_created -> source_connected -> report_viewed
Order: required; unrelated events may occur between steps
Window: 7 days from account creation
Exclusions: internal, test and known automated accountsCalculate step rates and total conversion separately
Suppose a completed, fictional weekly signup cohort contains 100 accounts. Within seven days, 60 connect a source and 30 subsequently view a useful report. Signup-to-connection conversion is 60 / 100 = 60%. Connection-to-report conversion is 30 / 60 = 50%. Overall activation is 30 / 100 = 30%.
The first transition loses 40 accounts; the second loses 30. That does not mean the first problem is automatically more important. The second step might be a severe bug affecting qualified buyers, while the first includes casual signups. Prioritize using reproducible failures, user intent, effort and expected impact—not only the tallest red bar.
Do not divide this month’s 30 payments by this month’s 100 signups unless those payments belong to that signup cohort. For a paid-conversion report, associate each first qualifying payment with its eligible cohort, deduplicate it, and preserve the defined observation window.
Give every cohort the same chance
If accounts created yesterday have seven days to activate, their result is unfinished. Comparing them with accounts created three weeks ago biases the newest cohort downward. Either wait for the observation window to finish or label immature cohorts and compare equal elapsed time.
A useful table shows cohort start, eligible accounts, accounts with a complete observation window, qualifying outcomes and the latest data refresh. When follow-up time differs, report that limitation rather than filling missing outcomes with zeros. Likewise, a deleted or inaccessible measurement identifier is missing evidence, not proof of abandonment.
Debug the measurement before redesigning the product
Run one authorized test account through every supported signup route. Check email login, social login, invitation acceptance and any upgrade shortcut that can bypass the path you first tested. Verify the events exist in the intended project and carry the correct timestamp and account association. Test a failed action too: clicking Connect must not count as a successful connection.
Then inspect a small set of real, appropriately accessible cases. Was the prerequisite actually completed? Did the user receive a useful result? Did the event arrive late? A sudden funnel break immediately after an instrumentation release is a reason to inspect instrumentation first. It is not proof that customers suddenly dislike the product.
Turn the finding into one test
Choose a specific hypothesis: “Accounts abandon connection because the required permissions are unexplained.” Improve the permission explanation, record the release date and compare mature, similarly acquired cohorts. Small numbers may justify usability feedback before an elaborate experiment.
Report what changed and what was observed separately. An improved rate after a release is not, on its own, proof the release caused the change. The related analytics-plan guide helps choose the business question; the revenue-attribution guide covers the separate join between a journey and verified money.