Funnel optimization: how to diagnose each step and test the fix

Funnel optimization means measuring how many people stay at each step toward a goal, such as a purchase or a signup. You then find and test the change that adds the most completions. The step with the highest drop-off rate isn't automatically where your diagnosis starts. It depends on the people you lose there, how often later steps carry them to the end and how big a realistic change is.

The same work often goes by conversion funnel optimization. The step-rate arithmetic lives in the funnel analysis calculator. The definition, process and tools of conversion rate optimization (CRO) have their own guide.

Every step in the funnel should map to one event and one clear condition in your analytics tool. Instead of a page name such as "checkout page," write down what a user does to count at that step. Share that definition with everyone who reads the funnel.

For Google Analytics 4 (GA4), Google's ecommerce events documentation was last updated on October 14, 2026. It says to measure the first step of checkout with a begin_checkout event. A four-step ecommerce funnel built from those events looks like this:

1. Product page: the user views an item's details page (view_item).
2. Add to cart: the user adds an item to the cart (add_to_cart).
3. Begin checkout: the user reaches the first step of checkout (begin_checkout).
4. Purchase: the order is completed (purchase).

Next to each step, record the counting unit, the period and any time limit between steps. As of November 2026, Google's help page says GA4 funnel exploration lets a user enter the funnel only once per date range. If someone completes the steps several times, only the first sequence is reported. A shopper who starts checkout three times in a month is one user in this funnel, so counting checkout attempts needs a separate, event-level count.

You also choose how steps relate to each other in GA4. A step that indirectly follows the previous one allows other actions in between, while a step that directly follows must come immediately after it. The Within setting requires a step to happen within a set time after the previous one. With a time limit, purchases that come later don't count at that step, so give the test the same follow-up window.

Check that the events fire correctly before you read the funnel. Google's ecommerce documentation recommends enabling debug mode to see events in real time and troubleshoot them. Data checks such as open versus closed funnels, empty steps and double counting are covered separately on the calculator page.

A drop-off rate shows how much a step leaks, and a head count shows where the loss is concentrated. Neither tells you how many purchases a change would add. Some of the people who leave a product page may never have meant to buy. Someone who abandons checkout, by contrast, was at the last stage of a decision.

Each extra user you move through a step reaches purchase only at the rate of the steps after it. A person recovered at the top of the funnel therefore yields fewer purchases at the end than a person recovered near the bottom. When you compare candidates, hold two numbers for each change. One is how many extra people it moves through its step, the other how often those people reach the end.

Keep three amounts apart: the people lost at the step, the gap visible in current figures and the gain a change would bring. You read the first two from your data. The third stays an assumption until a test measures it.

Recovering a step's entire loss isn't realistic, so estimate the gain from the number of extra people you expect a change to move through. Note what that estimate rests on, such as a higher rate in one segment, user research or a similar test.

In a hypothetical store, 40,000 users view a product page in 30 days and 1,800 of them buy. Most users are lost at the first step:

The first step loses the most people, 34,000, but a user who gets past it is also the least likely to reach purchase. Users who add to cart go on to buy 30% of the time, and users who begin checkout 50% of the time.

Three candidate changes

The store has one idea for each step. How much each idea would improve its own step is an estimate, so the figures below are assumptions, not measured results:

Under these assumptions the checkout change leads with 216 extra purchases. The product page, where the largest loss sits, comes last with 120. The 400 extra users who get past the product page produce fewer purchases than the 216 extra users who get through checkout.

What the result depends on

If the product page change brings two points instead of one, extra purchases rise to 240 and overtake the checkout change. The size you assume for each change sets the order, not the step's position in the funnel.

Now suppose recovered users move through the later steps at half the rate of current users. The product page then falls to 60 extra purchases, the cart to 75 and the two-point scenario to 120. The checkout change keeps its result because no step comes after it. If people won at the top of the funnel are less motivated, the order tilts toward checkout.

This hypothetical example also shows no automatic compounding for gains near the top. With the other step rates unchanged, a 10% relative improvement at any one step brings the same 180 extra purchases. The difference comes from how much a rate moves and whether later steps react to that change.

A step rate can fall while purchases rise

One change can lower one step's rate and raise a later one. Showing the shipping cost on the product page may stop some users from adding to cart. It may also mean fewer people leave when they first see the cost at checkout. In the example store, if add to cart drops half a point and checkout completion rises 5 points, purchases go from 1,800 to 1,914.

That's why a test's primary metric is purchase among the users assigned to each group. The step rate stays a secondary metric that explains what changed. The figures in this section are hypothetical: unique users counted in one 30-day window with a closed funnel, users and purchases rounded to whole numbers.

Splitting the funnel by segment reveals differences that the total rate hides. Device, new versus returning users, traffic channel and payment method are common splits. In each segment, look at the same two numbers: the step rate and the number of people lost there. A small segment with a low rate can cost fewer purchases than a large segment with an average one.

In GA4 funnel exploration, a breakdown dimension such as device category splits every step, and segment comparisons allow up to 4 segments. With a breakdown, each user is attributed to the first value that applies to them.

In Google's example, a user who enters on mobile and completes the later steps on desktop appears only under mobile. In a store where people switch devices often, the mobile row also carries purchases completed on desktop. Read the device breakdown as the device people entered the funnel on.

Hypothetical example: the same segment rates, a lower total

In the hypothetical store, the purchase rate at checkout is 45% on mobile and 60% on desktop. In the second month, the number of users who begin checkout stays the same, but the mobile share grows:

The total rate fell 2.5 points and purchases dropped from 1,800 to 1,710, yet both devices kept their rates. The traffic mix caused the drop, and the checkout page didn't change. A hypothesis that looks for a checkout fault without this split tries to fix a problem that isn't there.

The example also points to a real candidate. Even in the first month, mobile loses 1,320 users at checkout against 480 on desktop. Mobile checkout has both the lower rate and the larger volume, which makes it the place for a hypothesis. How a change in segment mix can reverse a test result, known as Simpson's paradox, is covered in the post on A/B test segmentation.

A well-formed funnel hypothesis has four parts. It names where people are lost and how many, a likely cause, a change that targets that cause and the expected rise in purchases.

In the example store, the suspected cause is the required account form on mobile. The hypothesis: if that form drives the losses, guest checkout will raise purchases among checkout starters. Write the expected lift as a number, because it sets how long the test runs.

Test the likely cause against your data before you run an experiment. The Top 5 Next Actions card in GA4 funnel exploration shows the most common actions after each step, for a dimension you choose. The elapsed time setting shows the average time between steps.

With page or screen dimensions, Google notes that "(no next action)" doesn't always mean a drop-off. Users may have moved on while the page title stayed the same.

Event data doesn't show why a user stopped. Session recordings, user tests and surveys narrow down the cause, and the CRO guide explains when each method helps.

Reaching people after they leave the funnel is a separate lever. Reminders for users who begin checkout and don't finish are set out in the checkout abandonment journey. If the loss comes from the step itself, a reminder sends the user back to the same obstacle, so fix the step first.

A before-and-after comparison folds everything else that changed in between into the difference: season, campaigns and traffic mix. To isolate the effect, assign users at random to two groups when they first reach the changed step. The control group sees the current version and the test group sees the new one. Group size, the unit of assignment and sample ratio mismatch are covered in the guide to the control group in A/B testing.

Tie assignment to the step the change touches. For a checkout change, the groups consist of users who begin checkout. For a product page change, everyone who views a product page is assigned, because people who leave without adding to cart saw the change too. Compare results by the group each user was assigned to, with the same follow-up window in both groups.

Next to purchase, the primary metric, guardrail metrics check whether the change hurts something else. For guest checkout these could be cancellations and returns, order value and payment errors. The A/B test library's guest checkout test idea lists these metrics and what to keep the same in both groups.

A rule written in advance fixes what counts as a win and which guardrail stops a rollout at which limit. It also says how an unclear result gets recorded. Writing it afterward invites you to pick whichever metric looks most favorable once you've seen the data.

Hypothetical example: test length and the rule

Test length depends on the expected effect and the traffic reaching the changed step. In the hypothetical store, the checkout change needs about 1,086 users per group. With 3,600 users beginning checkout each month, the test takes about 19 days.

The product page change is expected to move the purchase rate among product viewers from 4.5% to 4.8%. Detecting that small difference with the same power takes about 116 days. Under these assumptions the checkout change promises more extra purchases and can be measured sooner.

These lengths come from the standard sample size method for comparing two proportions, with 80% power and a 5% significance level. They assume each 30 days brings as many new users to the step as the first table shows.

Round the length up to full weeks so it covers weekly cycles. You can find the users your own figures need with the sample size calculator. A rule written in advance for the checkout test could read:

• Primary metric: share of users assigned at checkout start who buy within 7 days of assignment.
• Win: the test group's rate is higher than control and the 95% confidence interval of the difference stays above zero.
• Guardrail: if cancellations and returns exceed control by more than 1 point once both groups complete 30 days of follow-up, the change doesn't roll out.
• Length: no reading before 1,086 users per group and 3 full weeks, and no extension after seeing the result.
• Unclear result: if the confidence interval includes zero, record the result as "unclear," not as "no effect."

The expected 6-point lift is there to plan the test's length, not to serve as a win threshold. A testing tool labeling a variant the "winner" doesn't replace the decision either. The rule above makes it.

You can do a first pass on one page. Write down four or five steps with their event names and enter unique users for the last 30 days. Note each step's loss as a number of people. Then list one change idea per step, the extra users you expect it to move through and what that estimate rests on.

Carry those users through the later step rates to purchase and the candidates become comparable on one scale. Pick the one that adds the most purchases and that your traffic can measure in a reasonable time. Write the decision rule, then start the test.