Funnel Drop-Off Analysis: Find the Step Losing Users

You have 400 signups and 12 people who used the product this week. You know both numbers. You know nothing about what happened between them.

Your analytics dashboard shows totals: users, sessions, events. Totals tell you how many. Funnel drop-off analysis tells you where — which single step is losing people, so you fix that one instead of rebuilding the onboarding you guessed was the problem.

Most founders never get there, and it is usually not because the analysis is hard. It is because the analytics setup is quietly broken in one of three specific ways, and the resulting numbers look plausible enough to act on.

Who has this problem

You shipped a product, wired up Google Analytics or Firebase or PostHog on launch day, and have not opened it properly since. You can see traffic. You can see signups. You cannot see the journey.

When retention comes up you say "activation is probably the issue" — which is a guess, and it is the same guess every founder makes, because it is the only stage anyone can name without data.

If you have ever rebuilt an onboarding flow without knowing whether onboarding was where people left, this is the gap.

Why your analytics shows totals but not journeys

Three reasons, and all three are setup problems rather than analysis problems.

A funnel needs stages mapped to events, and nobody maps them. Analytics tools collect events; they do not know that sign_up is your stage two and first_project_created is your stage three. Until you declare that sequence, every tool can only ever show you totals.

The events you need were never defined. You get whatever the SDK sends automatically — page views, sessions, first opens. None of those correspond to a moment that matters in your product.

The setup produces numbers that are wrong in a believable direction. This is the dangerous one. Three failures show up constantly:

• Only first_open is marked as a key event. Every user who opens the app "converts", so your conversion rate is 100% and you conclude the funnel is fine.
• A login_start event exists with no matching success event. Every login appears to be abandoned, so the funnel shows 100% drop-off at a step that is working correctly.
• Custom event parameters were never registered as dimensions. The data is being sent and is invisible in reports — and registration is not retroactive, so the months you waited are gone.

There is a fourth, specific to paid: a Meta pixel that fires page views but has never once received a conversion event. The pixel looks installed. It looks healthy in the browser. You cannot see this state by inspecting your website, and it is what stops conversion campaigns from ever leaving the learning phase.

All four are believable in the same direction — they make a broken setup look like a working one:

How to run a funnel drop-off analysis that survives scrutiny

Step 1: Write the stages before you open analytics

List the sequence a customer actually moves through, in your own words: visited pricing → started signup → verified email → created first project → invited a teammate → paid.

Do this from the product, not from the analytics tool. If you start in the tool you will build a funnel out of the events that happen to exist, which is how people end up measuring page views and calling it activation. This is the same sequence you should already have from mapping your sales funnel.

Step 2: Map each stage to one real event

Every stage needs exactly one event name that fires when a user reaches it. Where an event does not exist yet, that is a small engineering task — and it is the highest-leverage instrumentation work you will do this quarter.

The Mark Platform will suggest an event for each stage based on what your analytics is already emitting, then store the mapping on the funnel so the measurement is repeatable rather than re-derived each time.

Step 3: Audit the setup before you believe a number

Run this before the analysis, not after it disappoints you. You are checking for the three failure modes above: which events are marked as key events, whether every _start has a matching success, and whether your custom parameters were registered as dimensions.

The platform scores this and names the exact fix per gap, including the four possible pixel states — no pixel, installed but silent, page views only, or genuinely tracking conversions. The third of those is the one nobody finds by hand.

Step 4: Read the biggest leak, not the whole chart

A funnel report shows a drop at every stage, because some drop at every stage is normal. Find the one that is disproportionate.

If 90% leave between "started signup" and "verified email", that is not an onboarding problem or a positioning problem. It is an email deliverability problem, and it is fixable this afternoon.

Step 5: Break the leak down before you fix it

The same drop can have different causes for different people. Split the funnel by device, country, traffic source, or app version. A stage that converts at 40% on desktop and 4% on mobile is a broken mobile layout, not a messaging failure — and those two conclusions lead to completely different weeks of work.

Step 6: Fix one step, then measure the same funnel again

One change at a time. Two changes at once and you learn nothing about either, which is the same discipline that makes an experiment worth running.

Why this framework holds up

Because it puts the audit before the analysis. Most funnel advice starts at "read your funnel report" and assumes the numbers underneath are sound. In small products they usually are not, and a confident chart built on an unregistered dimension will cost you a month.

The Mark Platform reads per-stage counts, conversion rates and abandonment from Firebase, Google Analytics or PostHog, then states the biggest leak in plain language rather than handing you a chart to interpret. It refuses to run the analysis at all until the stages are mapped to events, because a funnel built on guessed events produces numbers that are wrong and confident.

Where this will not help: a funnel tells you where people leave and never why. The why comes from the people who left. When you find the leaking step, go and ask five users who dropped at it what happened — customer interviews are the other half of this, and no amount of analytics substitutes for them.

Key takeaway

Map every funnel stage to a real event, audit the setup for the three failures that fake your numbers, then fix the single most disproportionate drop. One step, measured before and after.

Frequently asked questions

How much traffic do I need before this is worth doing? Enough that a stage has a few hundred entries over your window. Below that you are reading noise. The instrumentation is still worth doing early, because dimension registration is not retroactive.

Which analytics tool should I use? The one you already have. Google Analytics, Firebase and PostHog all support this. Switching tools is a much larger project than mapping six events, and it resets your history.

My conversion rate says 100%. Is that good? It means your only key event is one that every user triggers, usually first_open. Mark the events that represent real progress instead.

What window should I read? 28 days is a sensible default. Shorter windows swing wildly on small samples, and longer ones blur the effect of a change you just shipped.

Do I need a separate tool for the Meta pixel? No, but you do need to check it separately from your product analytics. A pixel that has never received a conversion event is invisible until something queries its event history.

---

You have the framework. The Mark Platform maps your funnel stages to real events, audits the setup for the failures that fake your numbers, and names the biggest leak in plain language. See how it connects to your analytics, or start your marketing journey →