Skip to content
Back to Analytics & Experimentation

Bottleneck Identification

Finding the single funnel step that, if fixed, would lift overall conversion the most —so effort goes where the leverage is, not where the drop is biggest.

Why

The step with the biggest drop-off is not always the step worth fixing. A 50% drop at step 3 (deploy) might be because users do not want to deploy, and no UX fix will help. A 20% drop at step 2 (email verify) might be because the email is in spam, and a one-line SPF fix recovers all of them. The bottleneck is the step where the fixable drop is largest relative to the effort, not where the total drop is largest. Identifying the bottleneck requires combining the drop-off analysis (which step, which reason, fixable subset) with an effort estimate (how hard is the fix) and a leverage calculation (fixing this step lifts overall conversion by how much). The leverage is multiplicative: in a 4-step funnel with conversions [80%, 65%, 50%], lifting step 2 from 65% to 75% lifts overall from 26% to 30% (a 4pp lift), while lifting step 3 from 50% to 60% lifts overall from 26% to 31.2% (a 5.2pp lift). The bottleneck is step 3, but only if its drop is fixable. This analysis is what prevents the team from spending a quarter on the wrong step.

When

After a full funnel + drop-off analysis, when prioritizing which step to fix first. Re-run when a step is fixed or a new step is added.

How

1. Compute the full funnel with step-to-step conversion rates: [c1, c2, c3, c4] (e.g., [80%, 65%, 50%, 100%])
2. For each step, run a drop-off analysis to identify the fixable subset and the expected recovery (e.g., step 3: 50% drop, 30% fixable, expected lift to 65%)
3. For each step, compute the leverage: if step i conversion goes from ci to ci', the new overall = c1 * c2 * ... * ci' * ... * c4. The lift = new overall - current overall
4. Estimate the effort for each step's fix: step 2 (SPF record) = 1 hour; step 3 (deploy UX) = 2 weeks; step 4 (payment) = 1 week
5. Compute the leverage per unit effort: step 2 = 4pp / 1h = 4pp/h; step 3 = 5.2pp / 80h = 0.065pp/h; step 4 = 2pp / 40h = 0.05pp/h
6. Rank by leverage per effort: step 2 (4pp/h) >> step 3 (0.065pp/h) > step 4 (0.05pp/h)
7. The bottleneck is the highest-ranked step: step 2 (email verify), not step 3 (deploy) —even though step 3 has the bigger drop, step 2 has 60x the leverage per effort
8. Fix the bottleneck, re-measure the funnel, and re-run the bottleneck identification —the bottleneck shifts after each fix, and the next-highest-leverage step becomes the new target

Example

# Bottleneck identification: signup -> deploy funnel
Funnel: [80%, 65%, 50%]  Overall: 26.0%  (n=12,400)

Step | Drop  | Fixable | Expected  | Effort | Leverage  | pp/effort
     |       |         | new conv  |        | (pp lift) |
-----|-------|---------|-----------|--------|-----------|----------
  2  | 20%   | 15%     | 75%       | 1h     | +4.0pp    | 4.00 pp/h
  3  | 35%   | 15%     | 60%       | 80h    | +5.2pp    | 0.065 pp/h
  4  | 50%   | 20%     | 60%       | 40h    | +5.2pp    | 0.130 pp/h

Leverage calc:
  Fix step 2 (65% -> 75%): 0.80 * 0.75 * 0.50 = 30.0%  lift = +4.0pp
  Fix step 3 (50% -> 60%): 0.80 * 0.65 * 0.60 = 31.2%  lift = +5.2pp
  Fix step 4 (same as step 3 here, 4th step is 100%)

Ranking by pp/effort:
  1. Step 2: 4.00 pp/h  <- BOTTLENECK (fix first)
  2. Step 4: 0.130 pp/h
  3. Step 3: 0.065 pp/h

Decision: fix step 2 (email deliverability, SPF record) first.
  1 hour of work, +4pp overall conversion, recovers ~496 users.
  Then re-run bottleneck ID: step 4 becomes the new bottleneck.

Counter-intuitive: step 3 has the biggest drop (35%) but the lowest
  priority, because its fix is hard (80h) and only 15% is fixable.
  Step 2 has a smaller drop (20%) but 15% is fixable in 1 hour.

Common Problems

  • ⚠Equating 'biggest drop' with 'bottleneck' —the team fixes the 50% drop at step 3 (deploy UX, 2 weeks of work) and ignores the 20% drop at step 2 (email SPF, 1 hour), because 50% > 20%, but the leverage per effort is 60x higher for step 2.
  • ⚠Computing leverage without the fixable subset —'step 3 has 35% drop, fixing it lifts overall by 5.2pp' assumes the entire 35% is fixable, when only 15% is; the real lift is 2.3pp, and the prioritization changes.
  • ⚠Fixing steps in parallel without re-running bottleneck ID —the team fixes step 2 and step 3 simultaneously, step 2's fix lifts overall by 4pp, and the step 3 fix now has different leverage (the funnel changed), but the team is measuring against the old funnel.
  • ⚠Ignoring effort in the ranking —'step 3 has the highest leverage (5.2pp)' is true, but at 80 hours it is the lowest leverage per effort; without the effort denominator, the team takes on the big project and defers the quick win.

Best Practices

  • ✓Rank by leverage per unit effort (pp lift / hours), not by drop size or absolute leverage —the ranking is what prioritizes, and a 4pp/h fix always beats a 0.065pp/h fix regardless of the absolute numbers.
  • ✓Always include the fixable subset in the leverage calculation —'35% drop, 15% fixable' gives a 15% expected improvement, not 35%; without the fixable subset, every step looks like the bottleneck.
  • ✓Re-run bottleneck identification after every fix —the funnel changes, the fixable subsets change, and the next bottleneck is different from the one identified before the fix; treating the analysis as one-time leads to fixing the same step repeatedly.
  • ✓Include effort estimates from the engineer who will do the work, not from the analyst —the analyst estimates '1 week', the engineer who knows the codebase estimates '2 hours', and the effort estimate is what determines the ranking, so it must be accurate.