Reading a funnel in context: segments, not just the aggregate

Overview

An aggregate funnel —every user mixed together, like the one you used in lessons 2 through 6— is a weighted average of all the different paths behind it. Behind Mercado's 9.0% overall conversion there could be a segment that converts very well and another that converts poorly, mixed into a single number that faithfully represents neither. This lesson teaches you to segment the same funnel (mobile versus desktop, for example) and compare them correctly — by rate, not by volume — before deciding where the problem actually is.

How this connects to the module. This is the last piece before the project: up to here you learned to read an aggregate funnel end to end (lessons 2 through 6); this lesson teaches you that aggregate can hide a different story depending on who crosses it, and gives you the discipline to compare segments without falling into the mistake of comparing numbers that aren't comparable to each other.

An everyday analogy: the average house temperature with the window open

Imagine you measure your whole house's average temperature and get 22°C, a pleasant temperature. But that house has one room with the window wide open in the dead of winter (12°C) and the rest of the house very warm from the heating (26°C) — the 22°C average doesn't describe the experience of anyone standing in either room: whoever's in the cold room is genuinely cold, and the overall average doesn't reveal it. A product's aggregate funnel can be just as misleading: a "pleasant" 9.0% overall conversion could be averaging a segment converting at 16.7% (the warm room) with another barely reaching 5.7% (the room with the open window) — and if nobody separates the two numbers, nobody ever closes that window.

Worked example: the same Mercado funnel, split by mobile and desktop

// L7: reading a funnel in context -- comparing normalized segments (rates), not raw counts
function funnelAnalysis(steps) {
  const withRates = steps.map((step, i) => {
    if (i === 0) return { name: step.name, users: step.users, conversionRate: null, dropOffRate: null };
    const prevUsers = steps[i - 1].users;
    const conversionRate = step.users / prevUsers;
    const dropOffRate = (prevUsers - step.users) / prevUsers;
    return { name: step.name, users: step.users, conversionRate, dropOffRate };
  });
  const overallConversion = steps[steps.length - 1].users / steps[0].users;
  const worstStep = withRates.slice(1).reduce((worst, s) => (s.dropOffRate > worst.dropOffRate ? s : worst));
  return { steps: withRates, overallConversion, worstStep: worstStep.name, worstDropOffRate: worstStep.dropOffRate };
}

const mobile = [
  { name: 'visit', users: 7000 },
  { name: 'view_product', users: 4000 },
  { name: 'add_to_cart', users: 1400 },
  { name: 'checkout', users: 600 },
  { name: 'purchase', users: 400 },
];

const desktop = [
  { name: 'visit', users: 3000 },
  { name: 'view_product', users: 2000 },
  { name: 'add_to_cart', users: 1000 },
  { name: 'checkout', users: 600 },
  { name: 'purchase', users: 500 },
];

const mobileResult = funnelAnalysis(mobile);
const desktopResult = funnelAnalysis(desktop);

console.log('=== Same funnel, two segments -- compared by RATE, not by count ===\n');
console.log('  Mobile:  ' + mobile[0].users + ' visits -> ' + mobile[mobile.length - 1].users + ' purchases'
  + '  |  overallConversion: ' + (mobileResult.overallConversion * 100).toFixed(2) + '%'
  + '  |  worst step: ' + mobileResult.worstStep + ' (dropOffRate ' + (mobileResult.worstDropOffRate * 100).toFixed(1) + '%)');
console.log('  Desktop: ' + desktop[0].users + ' visits -> ' + desktop[desktop.length - 1].users + ' purchases'
  + '  |  overallConversion: ' + (desktopResult.overallConversion * 100).toFixed(2) + '%'
  + '  |  worst step: ' + desktopResult.worstStep + ' (dropOffRate ' + (desktopResult.worstDropOffRate * 100).toFixed(1) + '%)');

console.log('\n  Total purchases mobile + desktop: ' + (mobile[mobile.length - 1].users + desktop[desktop.length - 1].users)
  + ' (desktop contributes fewer purchases in volume, but converts almost 3x better by rate)');

What to expect. When you run the file with Node, the output is exactly this:

=== Same funnel, two segments -- compared by RATE, not by count ===

  Mobile:  7000 visits -> 400 purchases  |  overallConversion: 5.71%  |  worst step: add_to_cart (dropOffRate 65.0%)
  Desktop: 3000 visits -> 500 purchases  |  overallConversion: 16.67%  |  worst step: add_to_cart (dropOffRate 50.0%)

  Total purchases mobile + desktop: 900 (desktop contributes fewer purchases in volume, but converts almost 3x better by rate)

Now compare this to the aggregate funnel you used in lessons 2 through 6: visit: 10000, view_product: 6000, add_to_cart: 2400, checkout: 1200, purchase: 900, with an overall conversion of 9.0%. Add up, step by step, mobile's and desktop's numbers: 7000+3000=10000, 4000+2000=6000, 1400+1000=2400, 600+600=1200, 400+500=900 — those are exactly the same numbers as the aggregate funnel. The 9.0% overall conversion you analyzed through the whole module was, this whole time, a weighted average of a segment converting at 5.71% (mobile) and another converting almost three times better, at 16.67% (desktop).

Notice something subtler: the "worst step" is add_to_cart in both segments, matching the aggregate's label — but the leak's magnitude is very different: 65.0% on mobile versus 50.0% on desktop. If Mercado's team only looked at the aggregate (60.0% dropOffRate on add_to_cart), it would conclude, correctly but incompletely, "we need to fix add_to_cart" — without knowing that problem is much more severe on mobile than on desktop, and that the cause (a cart form that's hard to use with a thumb? slower load times on 4G?) is probably different on each platform. Segmenting doesn't change which step to prioritize in this case —both segments agree on add_to_cart— but it does change how to investigate it and where to concentrate design and engineering effort.

Why compare by rate, not by volume

Look again at the result's last line: "desktop contributes fewer purchases in volume, but converts almost 3x better by rate". If someone compared the segments only by number of purchases (400 on mobile versus 500 on desktop), they might wrongly conclude "desktop and mobile perform similarly" — a difference of just 100 purchases. But that comparison ignores that mobile had more than double desktop's visits (7,000 versus 3,000) to reach those 400 purchases. The correct comparison normalizes for each segment's size —the conversion rate, not the raw purchase count— and reveals a gap of almost 3x, not "similar". Comparing raw counts across differently sized segments is one of the most common ways to unintentionally hide a real performance gap.

Common mistakes

Comparing two different segments' conversion without normalizing for their size. What happens: someone looks at mobile generating 400 purchases and desktop generating 500, and concludes "desktop performs a bit better, but not by much" — without calculating that mobile needed 7,000 visits for those 400 purchases while desktop needed only 3,000 for 500. Why it happens: absolute counts (400, 500) are right there, on any dashboard, ready to compare at a glance; calculating each segment's rate requires an extra step that's easy to skip under time pressure. How to spot it: if a comparison between segments uses only user or purchase counts, without dividing by each segment's input size, ask "how many visits did each one have?" before accepting the conclusion. How to fix it: any comparison between segments —mobile versus desktop, one country versus another, new users versus returning users— is always done with each one's conversion rate (as funnelAnalysis() does in this lesson), never with the raw count of purchases or users who made it to the end.

Reporting a single aggregate number and not noticing it hides a big gap between segments. What happens: Mercado's team reports "9.0% conversion" quarter after quarter as if it described the typical buyer's experience, with nobody asking whether that number represents mobile and desktop users equally — when in reality the 9.0% is an average dominated by the higher-volume segment (mobile, with 7,000 of the 10,000 visits), not a number representative of "how a typical user converts" on any specific platform. Why it happens: a single aggregate number is easier to communicate and track over time than a segment table, and absent an explicit alarm signal (like a sudden drop), nobody has an incentive to break it down. How to spot it: ask, about any aggregate conversion number, "is this number similar across the relevant segments (device, country, user type), or is it hiding an average of very different extremes?" — if nobody knows the answer, the number was never checked. How to fix it: at least once a quarter (and whenever the aggregate moves unexpectedly), break the funnel down by the business's most relevant segments —as you did here with mobile and desktop— to confirm the aggregate number isn't hiding a different story in each piece.

Exercises

Exercise 1 — Calculate each segment's weight in the aggregate. Of Mercado's 10,000 total visits, what percentage comes from mobile and what percentage from desktop? With that, explain why the 9.0% aggregate is closer to mobile's 5.71% than to desktop's 16.67%, even though the simple midpoint between the two would be 11.19%.

See solution

Mobile is 7000/10000 = 70% of visits; desktop is 3000/10000 = 30%. The 9.0% aggregate isn't the simple average of 5.71% and 16.67% (which would give 11.19%) — it's a weighted average by each segment's volume: (7000 × 0.0571 + 3000 × 0.1667) / 10000 ≈ (400 + 500) / 10000 = 9.0%. Since mobile contributes 70% of traffic, its lower conversion rate "pulls" the aggregate down harder than desktop's higher rate, which represents only 30% of volume. This is the exact mathematical reason the aggregate looks more like the majority segment than like a naive midpoint between the two.

Exercise 2 — Decide whether it's worth segmenting further. Mercado could also segment the funnel by country (Mexico, Colombia, Chile...) in addition to by device. Under what condition would it make sense to invest the effort of breaking it down by country, and under what condition wouldn't it be worth it, using this lesson's criterion?

See solution

It's worth segmenting by country if there's reason to suspect conversion varies significantly between countries —for example, if available payment methods, trust in buying online, or connection speed differ a lot between markets— and if each country has enough visit volume for its conversion rate to be a reliable number rather than statistical noise from a small sample. It's not worth it if every country has similar conversion behavior (the aggregate already represents them all well, as would have happened if mobile and desktop had converted almost the same) or if some countries have so few visits that their individual "conversion rate" is practically random from one week to the next. The underlying criterion is the same one that motivated segmenting by device in this lesson: segment when you suspect a real gap and have enough volume to measure it confidently, not by segmenting everything possible with no hypothesis for why those groups would differ.

Exercise 3 — Connect it to overall conversion. If Mercado's team managed, next quarter, to raise mobile conversion from the current 5.71% to 10% (with no change to desktop or to either segment's visit volume), what would the aggregate funnel's new overall conversion be? Use this lesson's same visit volumes.

See solution

With mobile converting at 10% over 7,000 visits, mobile purchases would rise from 400 to 7000 × 0.10 = 700. Desktop purchases stay at 500 (nothing changed there). Total purchases would be 700 + 500 = 1200, over the same total of 10000 visits: 1200 / 10000 = 12% overall conversion — a jump from 9.0% to 12%, without touching desktop at all. This calculation confirms, with a concrete number, why segmenting matters for deciding where to invest: since mobile is 70% of volume (exercise 1), improving its conversion moves the whole business's needle far more than the same percentage-point improvement applied to the smaller segment (desktop).

Summary and next step

An aggregate funnel is a weighted average that can hide very different segments within it — with Mercado's funnel, the 9.0% overall turned out to be a mix of mobile converting at 5.71% and desktop converting at 16.67%, almost 3 times better. This lesson's rule is firm: always compare segments by rate (normalized by each one's size), never by raw count of users or purchases.

Before moving on you should be able to: explain why an aggregate conversion number looks more like the higher-volume segment than like a simple average; and decide, for any two segments, whether it's better to compare them by rate or whether the raw count also carries relevant information (for example, for deciding where more total purchases are at stake, even if the rate is worse).

With the module's six topic lessons complete —what a funnel is, rate per step, overall conversion as a product, drop-off and the leakiest step, micro vs. macro, and segmentation in context— lesson 8's project brings it all together into a single deliverable: instrumenting Mercado's checkout funnel, finding its leakiest step, and estimating how much fixing it is worth in real purchases.

Resources

• Amplitude, "Conversion Funnel and Holding Constant" — amplitude.com/blog/holding-constant. An article on why "holding constant" a segment when comparing a funnel avoids wrong conclusions from mixing different populations. In English.
• Mixpanel, "Understanding Conversion Rate Differences in Funnels" — community.mixpanel.com/x/ask-ai/oguevc2ri7l3/understanding-conversion-rate-differences-in-funne. Explains why the same funnel's conversion rate can vary a lot across user segments. In English.
• GoodUI — goodui.org. A catalog of design patterns proven with real conversion-optimization experiments, useful as a next step once you've identified the segment and step with the most opportunity. In English.