When purchase outnumbers begin_checkout — an inverted funnel

Symptom

You chart the funnel and the order is upside down. begin_checkout reads 800, purchase reads 950. The step conversion cell shows a number above 100%. Sometimes it is add_to_cart that comes in under purchases.

In that state the question "where do people drop off?" cannot be asked at all. Show the funnel in a meeting and the discussion turns into an argument about whether the numbers are real.

Cause

An inversion is itself evidence of a defect: within the same period on the same site, a later step cannot exceed an earlier one. Four causes come up in real scans.

1. The purchase event fires more than once. The most common one by far. If purchase fires on the order confirmation page, it fires again every time a visitor refreshes it or navigates back to it. A GTM tag and a hardcoded gtag snippet both left in place will also send two at once.
2. The upper step is tagged on only some paths. begin_checkout was added to the desktop site and forgotten on mobile web, or checkout opens on the payment provider's domain where your tag does not run.
3. Some purchases never pass through the funnel. Buy-now buttons, phone and manual orders pushed to GA4 from the server, app purchases sent into the web property. Here the inversion is a definition problem, not a tagging bug.
4. Date-range edges. Someone who started checkout yesterday and bought today only shows the purchase inside today's range. This effect is worth a handful of events. If the numbers are inverted by a multiple, look at causes 1 to 3.

AnalyticScan compares view_item → add_to_cart → begin_checkout → purchase pair by pair and takes points off when a later step outnumbers the one before it.

If the upper step is at zero, this check does not flag it. That is not an inversion but a gap in collection, and a different item covers it. In practice the gap is the worse state to be in — data never collected cannot be recovered later.

How to check in GA4

1) Write the four numbers down side by side. Reports → Engagement → Events, last 28 days, and note the counts for view_item, add_to_cart, begin_checkout and purchase. Establish which pair is inverted before hunting for a cause.

2) Test for duplicate firing yourself. Turn on Admin → DebugView, run one test checkout, then refresh the confirmation page. A second purchase means cause 1. Two purchase events on the same single click means a double installation.

3) Split by path. Break the numbers down by device category or landing page and a path with an empty upper step usually surfaces. If step 2 found no duplicates, the answer is normally here.

How to fix it

Duplicate firing ends only when "count this order once" is written into the code. Skip the event when the order number has already been sent, and if you use GTM, prefer a data layer push the server writes exactly once over a confirmation-page view as the trigger. A tag's once-per-page firing option only prevents a second fire within the same page load, so it does not cover a refresh that loads the page again.

A missing upper step is an implementation request. begin_checkout should fire just before the handoff, while the visitor is still on your page. If checkout lives on an external domain, do not try to tag that screen — fire before leaving.

Purchases outside the funnel need a definition first. Decide whether manual orders belong in GA4 at all and, if they do, which steps get sent with them; writing that decision down is part of the fix. Skip it and the same argument returns in six months.

Once fixed, put the four numbers side by side again a few days later. GA4 does not recompute past data, so the period that was inverted stays inverted.

In one line

A later step larger than an earlier one is not good news; it is proof the numbers are wrong. Start by refreshing the confirmation page and watching for a second purchase — that settles it more than half the time.