THE PM’S GUIDE TO Funnel Drop-Off Analysis

Revenue Leakage · Segmentation · Root Cause Analysis

A practical, no-fluff field guide for product managers who want to stop guessing and start fixing the right problems first.

Why Most PMs Analyse Funnels Wrong

Picture this: it’s Monday. Your weekly product review opens with someone pulling up the analytics dashboard, pointing at the payment screen, and saying, “Our conversion rate dropped 3 points this month. We need to fix the payment page.” The team nods. A Jira ticket gets created. A designer is pulled in for a week. Two months later, the number barely moves.

Here’s what probably actually happened: the payment page was fine. The real problem was upstream , a confusing address form killing new users at Checkout, or a delivery ETA that wasn’t visible until far too late in the journey. Nobody looked far enough, and nobody calculated how much each drop was costing per day. So the team fixed the wrong thing.

Funnel analysis looks deceptively simple , pull step counts, draw a bar chart, declare a winner. Done rigorously, it tells you:

• Where in the journey you are losing users
• How much money each drop-off costs you, in rupees, every single day
• Which problem is statistically the most important to fix first
• Why users are dropping , Root Cause Analysis, not a list of guesses
• What to build as your first experiment, and what to ship without testing

This guide walks through all five. The worked example is a quick commerce platform , groceries delivered in 10 minutes. Every concept applies to any digital product.

Goal: By the end, you should be able to take any funnel dataset, identify revenue leakage at each step, segment it meaningfully, write a defensible Root Cause Analysis, and recommend experiments ranked by actual impact , not gut feel.

Part 1 , Understanding the Funnel Structure

What Is a Conversion Funnel?

A conversion funnel is the sequence of steps a user must complete to reach a desired outcome , placing a grocery order. At every step, some users continue. Others leave. Your job as a PM is to understand the shape and severity of those departures.

Figure 1: A typical quick commerce funnel shape. Width represents relative user volume at each step. The visible cliff between Checkout and Payment hints at our LATE-HEAVY pattern.

The Three Numbers You Must Calculate at Every Step

Before drawing any conclusions, you need three numbers per step: CVR, Drop %, and Revenue Lost per Day. Without all three, you’re telling half the story.

1. Conversion Rate (CVR)

CVR = (Users at Step N ÷ Users at Step N−1) × 100

Example: 1,54,000 ÷ 2,20,000 × 100 = 70.0%

2. Drop-off Count and Drop %

Drop = Users(N−1) − Users(N)

Drop % = (Drop ÷ Users(N−1)) × 100

Example: (2,20,000 − 1,54,000) ÷ 2,20,000 × 100 = 30.0%

3. Revenue Lost per Day

This is the number that turns a percentage into a business cost every stakeholder understands immediately. For a quick commerce platform: AOV ≈ ₹520, gross margin ≈ 8%.

Revenue Lost / Day = Drop × AOV × (Margin ÷ 100)

Example: 66,000 × 520 × 0.08 = ₹27,45,600 / day

Revenue Lost / Month = Rev Lost/Day × 30

Example: ₹27,45,600 × 30 = ₹8,23,68,000 / month

Decimal alert: Margin 8% means multiply by 0.08 , not 0.8 or 0.008. Misplacing the decimal overstates or understates the result by 10×. Quick commerce margins are thin; always verify your decimal.

Part 2 , A Full Funnel in Numbers

The Dataset: Quick Commerce App, March 2026

B2C quick commerce , groceries and daily essentials delivered in 10 minutes. Primarily urban, mobile-first. ~70% Android volume. AOV: ₹520. Gross margin: 8%.

Step 1: Pull raw step-level data from CleverTap / GA4 / Mixpanel:

Figure 1

Figure 1: Raw data for 1–25 March 2026. Unique users per step. Pulled from CleverTap Funnel Report, deduplicated by user ID.

Step 2: Calculate CVR, Drop, and Revenue Lost

Apply the three formulas to every step. All values below are computed from the raw data above , you can verify each with the formulas in Part 1.

Figure 2

Funnel average drop % (non-first steps) = (30.0 + 31.2 + 30.2 + 39.2 + 46.7 + 10.4) ÷ 6 = 187.7 ÷ 6 = 31.2% | End-to-end CVR = 21,500 ÷ 2,20,000 = 9.77%

Figure 2: Fully computed funnel. The ‘vs Avg’ column shows deviation from the 31.2% funnel average. ANOMALY threshold: +8pp above average (≥39.2%). ELEVATED: +3pp to +8pp (34.2%–39.1%). NORMAL: within ±3pp (28.2%–34.1%).

How the funnel average is calculated: Add the drop % for every step except the first (Home): 30.0 + 31.2 + 30.2 + 39.2 + 46.7 + 10.4 = 187.7. Divide by 6 steps = 31.2%. This average is the benchmark every step is measured against. It is not a target , it is a baseline for identifying which steps are performing abnormally.

Step 3: Classify the Funnel Shape

Before jumping to root causes, look at the pattern of drop percentages. This shapes your entire investigation.

Figure 3

Our funnel is LATE-HEAVY: Category, PDP, and Cart are all NORMAL (within ±3pp of the 31.2% average). The anomaly is concentrated at Checkout (ELEVATED, +7.9pp) and especially Payment (ANOMALY, +15.4pp). Users are opening the app, searching, adding to cart , they want to buy , but they hit something late that stops them.

Why LATE-HEAVY is recoverable: Users who reach Checkout and Payment have already invested significant intent , they opened the app, searched, browsed, and added items. Fixing one or two specific late-funnel blockers can recover disproportionate revenue compared to top-of-funnel optimisation where intent is lower.

Part 3 , Priority: What to Fix First

The Two Lenses You Need

Here is a mistake many PMs make: they try to produce a single ranked list of ‘most important things to fix’, and they expect it to put the highest-severity step at the top automatically. It doesn’t always work that way , and understanding why is a key part of mature product thinking.

You need two separate lenses, not one combined ranking:

• Revenue Lens: Which step loses the most money in absolute terms? This is driven by volume , more users dropping = more revenue lost, even if the drop rate is not unusual.
• Anomaly Severity Lens: Which step is performing worst relative to the funnel average? This is driven by deviation , a step with a high drop rate compared to every other step signals something specific is broken there.

These two lenses often point in different directions, and that’s not a problem , it’s information. Our funnel is a perfect example:

Lens 1 , Revenue Ranking

Figure 4

Figure 4: Revenue ranking: steps sorted by absolute margin loss per day. Category/Search ranks #1 because it has the highest volume of users dropping , 66,000 per day. Payment ranks #5 despite being the most severe anomaly because fewer users reach it.

Lens 2 , Anomaly Severity Ranking

Figure 5

Figure 5: Anomaly severity ranking: steps sorted by deviation from the funnel average (31.2%). Payment is the clear outlier. Category/Search , despite ranking #1 by revenue , has a drop rate actually slightly below average, meaning it is performing normally for this funnel.

The practical implication of two lenses: Category/Search losing ₹27,45,600/day does not mean something is broken there , it just has lots of volume. Payment’s ANOMALY status does mean something specific has gone wrong there recently. In practice, you would investigate Category to find organic improvement opportunities, while treating Payment as an urgent bug-hunt. Different problems, different responses.

The Combined Priority Score , Worked Calculation

To produce a single ranked list that accounts for both lenses, we use a formula that multiplies drop severity by revenue weight, then adjusts late-funnel steps upward to reflect their high-intent users:

Step 1 , Raw Score = Drop% × (RevDay ÷ MaxRevDay in Funnel)

Step 2 , Adj Score = Raw Score × 1.2 (if Checkout/Payment/Confirmed)

Step 3 , Final Score = Adj Score ÷ Max Adj Score × 100

Max RevDay = ₹27,45,600 (Category/Search)

Full working , every step shown:

Figure 6

Figure 6: Priority Score working table. Raw Score = Drop% multiplied by Revenue Ratio. Checkout, Payment, and Order Confirmed get ×1.2 multiplier. Final Score is normalised so the highest score = 100. All arithmetic verified.

Important nuance: Even after the ×1.2 late-funnel multiplier, Category/Search still scores 100 (highest) because its revenue volume dominates. Payment scores 59. This does NOT mean Category is a bigger problem than Payment , it means Category loses more money due to sheer volume, while Payment is the more severe anomaly. Use priority scores alongside anomaly classification, not instead of it.

Final Priority Summary , Two Lenses Together

Figure 7

Figure 7: Reading this table: the Combined Priority Score blends both lenses into a single number, but always cross-reference with the Anomaly Rank. Category/Search scores 100 due to revenue volume but is NORMAL , no anomaly. Payment scores 59 but is the only ANOMALY and is actively deteriorating vs baseline. In practice, Payment gets the first urgent sprint, and Category gets a planned optimisation workstream.

Part 4 , Segment Your Data Before Drawing Conclusions

Why Averages Lie

An overall 46.7% Payment drop is alarming. But it’s an average across very different users. A returning user with a saved address and saved UPI method converts at ~85%. A first-time Android user in a Tier 2 city trying to type a new address and complete a UPI redirect on 4G might convert at 15%. If you design a fix for the average, you’ll solve neither problem properly.

Four dimensions worth segmenting every quick commerce funnel by:

• Device OS: Android vs iOS , surfaces payment gateway and UPI compatibility issues
• User recency: New vs Returning , reveals address/payment friction that returning users have already solved
• Payment preference: COD vs Prepaid , reveals availability and trust gaps for cash-on-delivery users
• Geography: Tier 1 vs Tier 2/3 cities , reveals ETA credibility, COD preference, and last-mile trust gaps

The Segment Analysis (Hypothetical numbers assumed)

Figure 8

Figure 8: Segmented funnel view. The 46.7% aggregate Payment drop masks a 31pp gap between returning users (29%) and COD users (62%). The COD finding points to a silent failure mode rather than a UX problem.

How to Read Segment Data , 3 Steps

1. Find the biggest gap between segments

Look for the pair with the widest gap at your highest-priority step. Here, COD users drop 62% at Payment vs prepaid users at 31% , a 31pp gap. That’s not a UX problem. It’s a structural availability problem: COD is either disabled for many pin codes, or failing silently with no error message. A very different fix than redesigning the payment page.

2. Ask if the gap is consistent with your hypothesis

If you suspected Checkout drop was caused by a confusing address form, you’d expect new users (no saved address) to drop far more than returning users (address saved). Data confirms: New users drop 58% at Payment vs 29% for returning users, a 29pp gap. That 29pp is nearly impossible to explain with anything other than payment friction.

3. Use segments to decide who to fix for first

Fix the segment with the most users and the largest gap first. For this platform, that’s Android users (~70% of volume) and new users (highest abandonment, highest growth potential). A fix that improves Android Payment CVR by 10pp will do more than a broadly-applied redesign moving every segment by 3pp.

💡 Segment tip: In CleverTap, create compound segments , e.g. ‘New User AND Android AND Tier 2 City’ , and run the funnel for that specific population. If that group shows a 70%+ Checkout drop, you have a very narrow, high-confidence target. Narrow targeting means faster experiments and cleaner reads.

Part 5 , Root Cause Analysis (RCA)

What RCA Is (and Isn’t)

Root Cause Analysis is the process of going from “the number dropped” to “here is the specific, testable reason why, with evidence.” It is not a brainstorm. It is not a list of possibilities prefaced with “could be…”.

The most common RCA mistake: generating hypotheses before looking at the data. You get generic, low-confidence ideas that could describe any funnel failure anywhere. Good RCA does the opposite: the data pattern tells you what to investigate first, and you state each hypothesis after citing the number that points to it.

The 4-Step RCA Framework

1. Identify anomaly steps , steps where drop% exceeds funnel average by 8+pp
2. Classify funnel shape , CONCENTRATED, DISTRIBUTED, PROGRESSIVE, or LATE-HEAVY
3. Write data-triggered hypotheses , each must open with the specific data point that justifies it
4. Assign confidence levels , CRITICAL (supported by multiple data points), HIGH (supported by segmentation), MEDIUM (plausible, unverified), LOW (structural guess)

RCA for Payment and Checkout , the Two Highest-Severity Steps

Payment: 46.7% drop, +15.4pp above avg, ANOMALY, baseline +9.7pp DETERIORATING. Checkout: 39.2% drop, +7.9pp above avg, ELEVATED, baseline +8.2pp DETERIORATING. Segment: Android 51%, COD 62%.

Payment: 46.7% drop

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Out of the 45,000 users who reached Checkout, only 24,000 proceeded to place an order. That means 21,000 users dropped at Payment.

Drop % = 21,000 ÷ 45,000 × 100 = 46.7%

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

15.4pp above avg

The funnel average drop % across all non-first steps is 31.2%. Payment’s drop % is 46.7%.

Deviation = 46.7 − 31.2 = +15.4 percentage points above average

This means Payment is performing dramatically worse than every other step in the funnel. It’s not just high in absolute terms — it’s an outlier relative to the funnel’s own norm.

Get Aman Singh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

ANOMALY

The classification rule is: if a step’s deviation exceeds +8pp above the funnel average, it is flagged ANOMALY. Payment’s deviation is +15.4pp, which clears that threshold by a wide margin. This is the strongest signal in the entire funnel — something specific and likely fixable is wrong at this step.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Baseline +9.7pp DETERIORATING

The prior period baseline for Payment drop was 37.0%. The current period is 46.7%.

Delta = 46.7 − 37.0 = +9.7pp

Since this delta exceeds +5pp, it is flagged [DETERIORATING]. This is critically important because it tells you this is not a structural problem that has always existed — it is a recent regression. Something changed in the last 30–45 days that made Payment worse. That narrows your investigation considerably: look at your product changelog, gateway changes, and app release notes for that window.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Checkout: 39.2% drop

Out of 74,000 users who reached Add to Cart, 45,000 proceeded to Checkout. So 29,000 dropped.

Drop % = 29,000 ÷ 74,000 × 100 = 39.2%

+7.9pp above avg

Deviation = 39.2 − 31.2 = +7.9pp above the funnel average of 31.2%

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

ELEVATED

The classification rule is: deviation between +3pp and +8pp = ELEVATED. At +7.9pp, Checkout sits just under the ANOMALY threshold of +8pp. It is performing meaningfully worse than the funnel norm, but is not as sharp an outlier as Payment. It still warrants investigation — just with a slightly shorter RCA than a full ANOMALY step.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Baseline +8.2pp DETERIORATING

Prior period baseline for Checkout drop was 31.0%. Current is 39.2%.

Delta = 39.2 − 31.0 = +8.2pp

This also crosses the +5pp DETERIORATING threshold. And notice — both Checkout and Payment are deteriorating at the same time, while Category, PDP, and Cart are all stable. That pattern strongly suggests a single recent change affected the late-funnel steps specifically. A new address form, a payment gateway update, or an app release are the most likely suspects.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Segment: Android 51%, COD 62%

These are the Payment drop % figures for specific segments:

• Android users drop at Payment at 51% vs iOS users at 38% — a 13pp gap. This points to a UPI redirect or app-level failure specific to Android builds.
• COD users drop at Payment at 62% vs prepaid users at 31% — a 31pp gap. This points to a structural availability problem: COD is either not enabled for many pin codes, or failing silently without showing the user any error message.

Both of these are cited as data triggers in the RCA hypotheses. The segment gap is what elevates those hypotheses to CRITICAL confidence — a 13pp or 31pp gap between two groups is very hard to explain with anything other than a specific, structural difference between how those groups are being served.

Figure 9

Figure 9: RCA hypothesis table. Every hypothesis opens with the data observation that triggered it. Confidence level follows from data strength , not from subjective opinion.

How to Validate Each Hypothesis

Figure 10

Tools for validation: CleverTap for funnel + segment event queries. Mixpanel / Amplitude for event sequencing. Hotjar / UXCam for session replay at problem steps. Firebase Crashlytics for payment failure error codes. BigQuery for custom SQL on raw event logs when no tool gives the exact slice needed.

Part 6 , Experiment Recommendations

How to Rank Experiments

Rank by anomaly severity first, then by revenue impact within each severity tier. Within a step, prefer lower effort for equal expected impact. If segment data surfaced a specific population, run the experiment on that group first , cleaner reads, faster decisions.

Figure 11

Figure 11: Experiments ranked by anomaly severity of the step they address. The native UPI in-app flow and COD visibility experiments rank first because Payment and Checkout are the only ANOMALY/ELEVATED steps.

What a Good Experiment Definition Looks Like

Hypothesis

If we [specific change], then [specific metric] will improve because [root cause being addressed]

Primary Metric

Exactly which event, at which step, for which segment , e.g. ‘Payment step CVR for Android new users’

Guardrail Metric

What must NOT regress , e.g. ‘AOV must not drop >5%; payment failure rate must not increase’

Effort

Low (<1 week) / Medium (1–2 sprints) / High (2+ sprints) , be honest about build time

Segment Read

If segment data surfaced a gap, measure the experiment separately for each relevant segment

Part 7 , Quick Wins (Ship Without Testing)

What Qualifies as a Quick Win?

A Quick Win is deployable in under two weeks without A/B test infrastructure , when the root cause is confirmed or regression risk is low:

• Hypothesis confidence is CRITICAL or HIGH
• Issue is a confirmed bug, config problem, or missing basic feature
• Change adds information or removes friction without replacing core experience
• Regression risk is low , you are adding something, not replacing something

Figure 12

Figure 12: Quick wins ranked by estimated revenue impact per day. All deployable in under 5 working days. Revenue estimates are indicative, not guaranteed.

Quick Win vs Experiment: A Quick Win fixes something clearly broken or absent. An Experiment tests an assumption about what would perform better. Showing a COD badge on the product card is a Quick Win , invisible COD availability is simply missing information. Testing whether showing the badge near the price vs near the CTA drives more Cart additions is an Experiment.

Part 8 , Using Baseline Data to Detect Regression

Why You Need a Baseline

A current funnel in isolation tells you where you stand. A funnel compared to a prior period tells you whether things are getting better or worse , and critically, whether a problem is structural (always been there) or recent (something broke). Those two diagnoses lead to completely different responses.

Baseline Drop% = (Baseline Prev − Baseline Current) ÷ Baseline Prev × 100

Delta (pp) = Current Drop% − Baseline Drop%

If Delta ≥ +5pp → flag as [DETERIORATING]

If Delta ≤ −5pp → flag as [IMPROVING]

Baseline vs Current , Verified Numbers

Figure 13

Figure 13: Baseline deltas verified. The top of funnel is completely stable (+2pp or less). The deterioration is concentrated at Checkout (+8.2pp) and Payment (+9.7pp) , both crossing the [DETERIORATING] threshold of +5pp. This pattern tells you something changed recently at those specific steps.

When you see DETERIORATING at two consecutive late-funnel steps like this, check your product changelog for the last 30–45 days. Likely suspects: a new address form, a payment gateway migration, an app update that broke UPI on Android, or a change to COD pin code availability.

Part 9 , The Full Report Structure

Seven Outputs, in Sequence

When you complete a funnel analysis, you are not just producing a table of numbers. You are building a structured argument that moves from observation to action. Each of the seven outputs serves a specific role in that argument — skip one and the analysis has a gap.

A — Pattern Summary is where you establish context before anything else. You state what the funnel average drop rate is, which steps are anomalies and why, and what the overall funnel shape is. This is the lens through which every subsequent output is read. Without it, a reader cannot tell whether a 39% drop is alarming or routine.

B — Funnel View is the full step-by-step table — every step, with users, CVR, drop count, drop %, revenue lost per day, deviation from average, and status badge. This is the single source of truth for the entire analysis. Every claim made later in the report must be traceable back to a number in this table.

C — Revenue Ranking takes the same steps from the Funnel View and re-sorts them by revenue impact per day, highest first. Its purpose is deliberate: it forces you to see the business cost of each drop in isolation, without the distraction of funnel order. The step losing the most money is not always the most anomalous step — and this table makes that tension visible.

D — Root Cause Analysis is where you explain why the anomaly steps are behaving the way they are. Every hypothesis must open with a specific data observation that justifies it. This output is what separates a PM who can read data from one who can act on it.

E — Experiment Recommendations translate the RCA into testable interventions. Each experiment is ranked by the anomaly severity of the step it addresses, not by funnel position. Each must have a hypothesis statement, a primary metric, a guardrail metric, and an effort estimate. This is what goes into your sprint planning conversation.

F — Quick Wins is the subset of fixes that do not require an experiment because the root cause is already confirmed or the risk of regression is negligible. These are deployable in under two weeks. Ranking them by estimated revenue impact per day helps the team sequence the work.

G — Next Steps closes the report with a three-horizon action plan: what to instrument or investigate in the current week, what to ship and test in Sprint 1, and what follows in Sprint 2. This is the output that turns an analysis into a calendar.

Figure 14

The Executive Summary , 3 Sentences, 4 Facts

• End-to-end CVR as an actual percentage
• Total revenue lost per day and per month in ₹
• Funnel shape classification and what it implies
• The single highest-priority action, named owner, timeline

Example Executive Summary

The quick commerce app converted at 9.77% end-to-end (Home to Order Confirmed) in March 2026, with combined daily margin loss of ₹82,57,600 across all drop-off steps , approximately ₹24.77 crore per month. The funnel shape is LATE-HEAVY with both Checkout (+8.2pp vs baseline) and Payment (+9.7pp vs baseline) in active deterioration, pointing to one or more recent changes rather than a structural baseline problem. Highest-priority action: Tech team to diagnose and fix UPI redirect failure on Android at Payment, targeting a patch within 5 working days, with COD pin code availability surfaced at product card level as a parallel quick win by the Product team.

Part 10 , Tools and Workflow

Where to Pull Funnel Data From

Figure 15

A Practical 5-Step Workflow

1. Define funnel step events , agree with engineering exactly which event = ‘user reached step X’. Ambiguity here corrupts every downstream number. Use a shared tracking spec document.
2. Pull unique user counts per step , always unique users, not sessions or page views. Session inflation makes a broken funnel look healthy.
3. Apply the three formulas , CVR, drop%, and revenue lost per day for every non-first step. Don’t stop at percentages.
4. Segment at your highest-severity steps , device, user type, payment preference, city tier. Understand the aggregate first; go wide only once the top story is clear.
5. Write the RCA in data-first order , pattern → hypotheses → validation path. Never brainstorm first and find data to support it second.

Conclusion , What Separates Good PM Analysis from Great

There are a lot of product managers who can look at a funnel and say, “Payment drop-off is high, let’s fix the payment page.” What separates a genuinely useful analysis from that is the discipline to keep asking: “How high compared to baseline? Why specifically , what does the segment data say? What changed recently? And what is the highest-ROI thing to do first?”

The framework in this guide gives you a structured answer to each of those questions:

• Revenue at every step , because a drop% without a rupee figure has no business weight
• Funnel average and anomaly classification , because a step dropping 30% might be perfectly normal or deeply broken, depending on what every other step is doing
• Two-lens prioritisation , because revenue rank and anomaly rank tell different stories and both matter
• Segmentation before conclusions , because the aggregate number almost always hides the real story
• Data-triggered hypotheses , because RCA written before looking at the data is guessing with a label
• Quick wins vs experiments , because some things are broken and some things are uncertain, and conflating the two wastes sprints

The goal is not perfect analysis. It is directional confidence , enough signal to know you’re working on the right problem, in the right order, with a clear owner and a clear success metric.

The one thing to take away:

Every day you don’t analyse your funnel, you’re leaving a specific, calculable amount of money on the table. Today, you know exactly how to calculate it.

Appendix , Verified Cheat Sheet

Every formula in this appendix has been verified against the funnel dataset in this guide. You can reproduce every number in the document using only the formulas below and the raw step data from Part 2.

All Formulas and Verified Examples

Figure 16

Status Classification , With This Funnel’s Actual Thresholds

Thresholds are always calculated from the specific funnel’s average drop% , they are not fixed constants. For this funnel, avg = 31.2%, so:

Figure 17

Quick Commerce Context Reference