Built by Ram Kr Shukla, SEO and growth consultant, Google Analytics certified.

Private by design: nothing is uploaded. Your numbers and any file you choose are processed locally in your browser, and closing the tab clears them.

GA4 doesn’t warn you when ecommerce tracking breaks. Reports load. Charts look normal. Then somebody spots more purchases than cart adds, and every conversion rate built on that data is worth nothing. If you suspect your GA4 funnel isn’t tracking correctly, start here.

The test behind this tool comes from my Shopify GA4 funnel audit. Pull the funnel events for one window, as event counts and as users, then check that no step is bigger than the step it depends on. That post walks through a real store where cart adds came in far below purchases, and why a one day screenshot couldn’t settle the argument. This page does the arithmetic for you. It works for any platform (Shopify, WooCommerce, Magento or a custom build) because it only reads GA4’s own event names.

How to Use the GA4 Funnel Checker

You need about five minutes and Viewer access to the GA4 property. Here’s the whole routine.

Sources for those steps: Google’s help pages on the Events report and on sharing and exporting reports. For the checklist at the end, Google’s guides to monitoring events in DebugView and troubleshooting with Tag Assistant cover the setup.

The event names and their order follow Google’s Measure ecommerce guide for developers and the online sales section of its recommended events list: view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info and purchase. page_view sits on top as context. The checker leaves out select_item, add_to_wishlist and remove_from_cart, because none of them is a step every order has to pass through.

Can’t export? Type the numbers in. Two events are enough to run it, though four (view_item, add_to_cart, begin_checkout and purchase) is the minimum I’d trust.

How to Read the Results

Every finding carries one of three labels. The verdict at the top is just the worst of them.

• Fault. Something that can’t happen when the tags work. purchase above begin_checkout is the cleanest case: there’s no way to finish an order without starting checkout.
• Check. Unusual, and possible on some stores. add_to_cart above view_item happens for real when quick add buttons sit on collection pages. Confirm it before you call it a bug.
• Info. Context with no grade attached, like the share of your store’s orders that GA4 recorded.

The order rules the checker applies

Eleven pairs. Each later step is compared with a step it depends on, on event count and on total users separately.

Two more rules sit outside the table. A step that records zero while a later step records something gets its own finding, because that event isn’t firing at all. And if you enter your store’s order count, GA4 purchases above it are a fault: GA4 can’t record more orders than actually happened.

User numbers get a small allowance. GA4 estimates user counts instead of counting every one exactly (Google explains this in its note on unique count approximation), so a users gap under 2% isn’t flagged. That 2% is my own margin for the tool. Google doesn’t publish one. Event counts are compared exactly.

What to do about each finding

• A step recorded zero. The event isn’t set up, or it reports to a different measurement ID. Open Tag Assistant, run the step yourself and see where the hit goes, if anywhere.
• purchase above add_to_cart or view_item. The upper funnel is under-recorded. Add to cart from every place a shopper can: product page, quick add, cart drawer, search results, blog product blocks. The one that sends nothing is usually the one most shoppers use.
• purchase above begin_checkout. Usually a checkout on another domain, a purchase sent from the server, or a duplicate purchase. If checkout lives on a different domain, check cross-domain measurement under Admin, Data streams, Configure tag settings, Configure your domains.
• GA4 purchases above store orders. Something counts orders twice. Place a test order, reload the confirmation page and watch DebugView. Google says it deduplicates purchase events that share a transaction ID, so duplicates that survive usually mean transaction_id is missing or changes.
• begin_checkout above add_to_cart. Either lots of shoppers use Buy it now or express buttons, or cart adds go missing. Buy once through the express path and note which steps fire. Then you’ll know how much of the gap it explains.
• Steps that look fine on users and wrong on events. The same people fire the event more than once. That points at two tags or a page that re-fires on reload. If consent banners are involved, read Google’s note on consent mode: with analytics consent denied, no cookies are set, and a basic setup sends nothing.

Worked example: the Acme Outdoor sample

Click Load sample data and the checker runs on a made up store, Acme Outdoor at example.com, over 28 days. It returns two faults and two checks.

• Fault: purchase is higher than add_to_cart. 2,280 purchase events against 640 cart adds, 3.6 times. On users it’s 1,412 against 410, 3.4 times.
• Fault: GA4 has more purchases than the store has orders. 2,280 purchase events against 1,530 orders in the store admin. That’s 149%.
• Check: begin_checkout is higher than add_to_cart. 3,410 against 640 on events, 5.3 times, and 2,615 against 410 on users, 6.4 times.
• Check: purchase is higher than add_payment_info. 2,280 against 1,905 on events. On users it stays in order, 1,412 against 1,640.

Read together, those four point at two separate problems.

First, add_to_cart is under-recorded. Product views, checkout starts, shipping and payment all look plausible next to each other. Cart adds are tiny next to every one of them. That’s the shape of a cart event that’s missing from most of the places shoppers add to cart, not a store where nobody uses the cart.

Second, purchase is over-recorded. There are more purchase events than real orders, and more purchase events than payment steps, while purchase users stay below payment users. Same buyers, extra events. That’s a confirmation page firing twice or two tags sending purchase.

What Acme should do first: the reload test from the checklist, because duplicate purchases inflate revenue too. Then walk every add to cart button in Tag Assistant. Until both are fixed, its 0.90% product view to cart rate and its 120% payment to purchase rate mean nothing.

Why the checker shows rates but doesn’t grade them

The funnel chart shows each step as a share of the step before it. You won’t find a pass mark on any of those rates. Published ecommerce conversion figures mix industries, price points and traffic sources, and I don’t think one number fits your store. So the checker only judges what’s impossible or clearly broken.

Your rates are most useful against your own history. Run the checker each month on a fresh 28 days and watch for a step that suddenly moves. Once it passes, the step rates are finally worth reading, and cart abandonment fixes ranked by impact is a good place to take them next.

If page_view is enormous and every ecommerce step looks tiny beside it, check how much of that traffic is automated before you blame the funnel. Bot traffic in GA4 covers the profile, and it’s often worst on blog pages.

And after a fix ships, don’t compare the first clean month with a broken one. Every period on period arrow turns green for a while, which is explained in why GA4 comparisons show fake growth after a tracking fix. The GA4 comparison window calculator gives you the first date a comparison is honest again.

Limits of This Checker

It’s a quick test on totals. Here’s what it can’t do.

• It can’t tell you where an event went missing. Totals don’t show the template, device or browser that lost it. That’s what Tag Assistant is for.
• A pass doesn’t prove the events are right. A missing items array, a wrong value or a missing currency won’t show up in counts.
• It only sees the property you exported. If two measurement IDs split the funnel between two properties, you need numbers from both.
• It can’t know every store’s exceptions. Subscription renewals, draft orders and phone orders can create orders with no browser funnel at all. If a lot of your orders come that way, expect gaps the checker will flag.
• Explorations can be sampled or thresholded. If your numbers come from an exploration, check its data quality notice before you trust a small step.
• The order comparison needs matching dates and time zones. If your store admin and GA4 use different time zones, a day at each end of the range lands in different places.
• It doesn’t grade conversion rates. On purpose, as explained above. For the reporting side, see how to read an e-commerce SEO report without being fooled.

If the events pass and your organic numbers still look off, the problem may sit in attribution instead of events. Why your organic traffic numbers are lying to you covers parameters and untagged traffic.

GA4 Funnel Checker FAQ