WooCommerce Sales Not Tracking in GA4? We Audited 75 Stores

You sold more last week than your analytics says you did. You know because the orders are sitting in WooCommerce, paid and shipped, while GA4 shows fewer purchases than you actually fulfilled. One store owner on the WordPress.org forums put numbers on it: 11 orders in WooCommerce, 3 in Google Analytics. The gap isn't a setting you forgot to tick. It's how client-side tracking works, and once you see why, you can't unsee it.

So I audited 75 live WooCommerce stores to find out how widespread it is. The result was more lopsided than I expected.

Why WooCommerce orders go missing in Google Analytics

WooCommerce orders don't show up in Google Analytics when the GA4 purchase event fails to fire in the customer's browser. That event runs once, as JavaScript, on the order-received (thank-you) page. The order itself is already saved on your server by then. So WooCommerce always has the sale, and GA4 only has it if one fragile browser moment went perfectly.

That single dependency is the whole story. Your WooCommerce database is the source of truth for revenue. Every paid order is in it, whether the buyer used PayPal, Klarna, or a card. GA4, by contrast, only learns about a sale if the buyer's browser loads the thank-you page, runs your tracking script, and successfully sends the event to Google before anything interrupts it.

Plenty interrupts it. The buyer pays on PayPal's domain and closes the tab. An ad blocker kills the script. A consent banner holds it back. A caching plugin serves a stale version of the page. In each case the order is real, the money is in your account, and GA4 saw nothing.

The industry has a rough number for the size of this gap. A 15 to 25 percent shortfall between WooCommerce orders and GA4 purchases is common for US stores, and EU stores with consent banners routinely see 40 to 60 percent. Those figures float around vendor blogs without a clean published study behind them, so treat them as directional. The mechanism underneath them, though, is concrete and verifiable, and that's what the rest of this is about.

If you want the short version before the deep dive: the problem isn't your configuration, and no plugin setting fully fixes it. The problem is architectural, and the fix is to stop relying on the browser for the one event that matters most.

How we audited 75 WooCommerce stores

In May 2026 I pulled together 75 live WooCommerce stores and checked, for each one, how it records a sale. The method is deliberately simple so you can rerun it.

Sample. 75 stores confirmed to run WooCommerce, weighted toward the EU and UK because that's where both WooCommerce and consent banners concentrate. I confirmed WooCommerce two ways for every store: the WooCommerce Store API endpoint (/wp-json/wc/store/) returning live JSON, plus at least one HTML fingerprint (the woocommerce body class, the wc-cart-fragments script, or /wp-content/plugins/woocommerce/ asset paths). Two signals minimum, so a single false match never counts.

What I fetched. Public pages only: the homepage, one product page, and the cart. No login. No purchases. No cart actions. No personal data. The reason that matters is also the study's main limit, so I'll state it plainly: I cannot reach the order-received page without buying something. So this audit measures the tracking setup a store exposes on its public pages, not a confirmed lost order. Every finding below is "this store runs a setup with a known failure point," not "this store lost N orders."

What I looked for. GA4 measurement IDs (G-XXXXXXX), Google Tag Manager containers (GTM-XXXXXXX), legacy Universal Analytics tags (UA-XXXXX), Meta Pixel, consent-banner platforms (CookieYes, Complianz, Borlabs, Cookiebot, and others), and any sign of server-side tracking, meaning a first-party tagging endpoint (transport_url) or a known server-side host like Stape.

The 100 percent is the one to sit with. Of the 52 stores running Google Analytics or Tag Manager, every single one fired its purchase tracking from the browser. Zero had a server-side safety net I could detect. This isn't a story about some stores being careless. It's that the entire sample, including stores clearly built by competent agencies, depends on the same fragile browser moment.

The 24 percent is the headline loss vector. Nearly a quarter of these stores run a consent banner whose default setting blocks analytics until the visitor clicks accept. Pair that with what we know about how often EU visitors click accept, covered below, and a large share of orders are gone before tracking starts.

The 19 percent is the quiet one. Almost one in five stores still has a Universal Analytics tag in the page. Google turned UA off in July 2024. These owners think analytics is running. It's collecting nothing.

The GA4 purchase event is a single point of failure

Here is the exact sequence WooCommerce runs, because the failure points only make sense once you see it.

When a customer completes checkout, WooCommerce processes the order on the server in PHP, marks it as processing or completed, and reduces stock. Then it redirects the browser to the order-received page at a URL like /checkout/order-received/{id}/?key=.... On that page, a PHP hook called woocommerce_thankyou fires, and tracking plugins use it to print a dataLayer push or a gtag call into the HTML. The browser runs that JavaScript, which sends the purchase event to Google.

Notice where the money and the measurement separate. The order is saved server-side, before the redirect. The purchase event is sent client-side, after it. Everything that can go wrong lives in that gap between "order saved" and "event sent."

There's a detail in the WooCommerce code worth knowing, because it's the seed of the fix. The woocommerce_thankyou hook is PHP. It runs on your server. The only reason it ends up browser-dependent is that plugins use it to print JavaScript rather than to act server-side. WooCommerce also fires a separate hook, woocommerce_payment_complete, the instant a gateway confirms payment, before the redirect, with no browser involved at all. Hold that thought. It's section eight.

Caching, consent, and ad blockers: three ways the fire never happens

Three failure modes account for most of the everyday gap. None is exotic. All three are running on stores right now that believe their tracking is fine.

Caching plugins serve a thank-you page with no live order

Caching plugins make WooCommerce fast by serving saved copies of pages. The catch: WP Rocket, the most common one, automatically excludes the cart, checkout, and my-account pages from caching, but it does not automatically exclude the order-received page. If that page gets cached, a later buyer can be served a stale copy that carries the wrong order data, or none. The purchase event fires with an empty value, or doesn't fire at all. Stores have reported tracking going dark for days after a caching change, with no error anywhere.

Minification compounds it. When a caching or optimization plugin combines and minifies JavaScript, it can reorder or mangle the inline script that pushes the purchase data, so the event is built before the container that reads it exists. The page looks fine. The tracking is broken.

Consent banners block analytics before the sale is counted

This is the EU's structural tax on client-side tracking, and it's the headline finding of the audit. 24 percent of the stores I checked run a consent platform that, by default, blocks Google Analytics until the visitor actively accepts.

The question that turns that into lost revenue is: how many visitors accept? The best evidence we have is a 2024 study run with France's data-protection regulator, the CNIL, with 3,947 participants. When the reject button was given equal visual weight to accept, 34 percent of people rejected. When the banner spelled out the consequences of tracking, 47 percent rejected. So on a compliant banner, somewhere between a third and a half of EU visitors say no, and the purchase event never fires for any of them.

Google's answer is Consent Mode, which models some of the missing conversions. Read Google's own wording carefully: it says modeling "recovers more than 70% of ad-click-to-conversion journeys lost due to user cookie consent choices." That's specifically about Google Ads click attribution, not your GA4 revenue report, and the modeling only kicks in above traffic thresholds most small stores never reach. For a typical WooCommerce shop, rejected-consent orders simply vanish from the reports.

Ad blockers and privacy browsers stop the script cold

Ad blockers don't just block ads. uBlock Origin, the most popular extension, uses a privacy filter list that blocks Google Analytics and Tag Manager by default. The Brave browser blocks them at the browser level with no extension needed. Globally, 29.5 percent of internet users ran an ad blocker as of mid-2025. Not all of those block analytics specifically, but a meaningful slice do, and for those visitors the purchase event is simply never sent.

One correction worth making, because it gets repeated wrong everywhere: Firefox's standard tracking protection does not block Google Analytics by default. Safari doesn't block the script either, though it does cap tracking cookies at seven days, which breaks attribution for returning buyers rather than dropping the sale. Brave and uBlock Origin are the ones that actually stop the event.

Redirect payment gateways: where the most orders vanish

If consent is the EU's tax, redirect payment gateways are everyone's. This is probably the single biggest source of missing WooCommerce orders, and it has nothing to do with how well you set up GA4.

When a customer pays with PayPal Standard, Klarna, iDEAL, Sofort, or most "buy now, pay later" options, they leave your site. They complete payment on the provider's domain, where your tracking scripts cannot run. Then the provider is supposed to redirect them back to your order-received page, where the purchase event finally fires. Two things go wrong with that return trip, constantly.

First, the buyer doesn't come back. They pay on PayPal, see PayPal's confirmation, and close the tab. From their side, checkout worked. The order is in your WooCommerce admin. But the thank-you page never loaded, so the event never fired. On mobile, where PayPal often opens in its own app, this is even more common.

Second, even when they do return, the trip back is treated as a brand-new session that came from paypal.com. The original source, the Google ad or the newsletter link that actually drove the sale, is lost. So the order, if it's counted at all, is misattributed to PayPal as a referrer.

This is the part that should change how you read your own reports. If you filter GA4 purchases by payment method and your PayPal and Klarna orders are underrepresented relative to your WooCommerce admin, you've found the leak. It isn't a tag you mis-fired. It's the redirect, and client-side tracking has no answer for it.

Block checkout and custom thank-you pages: the silent breakers

Two more failure modes deserve a flag because they tend to break tracking that used to work, which makes them maddening to diagnose.

WooCommerce switched new stores to a React-based "block" checkout by default in version 8.3, released November 2023. As of early 2026, most live stores, somewhere around 88 percent, are still on the older classic checkout, but every new store starts on blocks. The block checkout changed where and how some events fire. The final purchase event on the order-received page generally still works, because both checkout types land on the same page. But the mid-funnel steps that tracking plugins relied on can go silent, and stores that customized their flow around the old behavior can lose the purchase event entirely.

Custom thank-you pages are the more common silent breaker. If you use a page builder like Elementor, Bricks, or Divi to replace the default order-received template, or a funnel plugin that redirects to a custom "thanks" URL, the woocommerce_thankyou hook may never fire on that page. The plugin that depends on it prints nothing. Orders complete, the page looks great, and GA4 records zero purchases. There's a well-documented bug in one popular tag plugin where WordPress's own text formatter inserts paragraph tags into the inline tracking script, producing a syntax error that halts the event. Every one of these looks like a configuration problem. None is fixable by configuring harder.

Why server-side GTM isn't the fix you think

When people hit this wall, the advice they get is "go server-side, set up server-side Google Tag Manager." It's reasonable-sounding advice, and for the redirect and ad-blocker problems it's only half a fix. What the advice usually skips:

Server-side GTM is a relay, not a source. Google's own documentation describes the server container as receiving requests from the browser and forwarding them on. The browser still has to send the event first. The tagging server then enriches it and passes it to GA4, Meta, and so on. That's genuinely useful for cookie lifetime and for dodging some ad blockers, because the request goes to your own subdomain instead of Google's.

But read it against the failure modes above. If the buyer closed the PayPal tab and never loaded the thank-you page, the browser never sent anything, so the server has nothing to relay. If a consent banner blocked the script, nothing was sent. If the page was served from cache without the event, nothing was sent. Server-side GTM cannot relay an event that was never fired. For the biggest sources of missing orders, it changes nothing, while adding a tagging server you now host, a custom subdomain to maintain, and a monthly bill that runs from around 17 dollars on a managed host to 120 dollars and up if you run it yourself on cloud infrastructure.

The distinction between relay and origination is the whole game. To fix missing orders you don't need a faster relay. You need to originate the event somewhere that always knows the sale happened: your server.

What 75 stores told us about server-side tracking

Which brings us back to the audit, and the number I keep returning to.

Across all 52 audited stores running Google Analytics or Tag Manager, exactly zero had a detectable server-side tracking signal. No first-party tagging endpoint, no Stape, nothing. 100 percent were relying on the browser to fire the purchase event. And remember this is a floor: a perfectly hidden server setup wouldn't show in public HTML, so the real number of stores with no server net is this high or higher.

Sit with what that means alongside the rest of the data. Nearly a quarter of these stores block their own analytics with a consent banner by default. One in five is still feeding a dead Universal Analytics tag. And not one has the server-side capture that would make the whole client-side mess survivable. The rescue architecture that every troubleshooting guide eventually points at is used by none of them.

If this sounds like your store, it almost certainly is, because it was true of every store I looked at. The good news is that the fix is real, it's free, and on WooCommerce you're allowed to do it, which is more than Shopify merchants can say. It was true of every tracked store I looked at, and it's almost certainly true of yours.

The durable fix: capture the order on the server, not the browser

Here's the reframe that makes the whole problem tractable. You're asking one fragile browser event to do two different jobs: count the sale, and attribute the channel. Split them.

Counting the sale is your WooCommerce database's job, and it never fails at it. Attributing the channel is analytics' job, and that part is captured at the start of the visit, not at checkout. The only thing you need at the end is to connect "this order ID happened" with "this session brought it," and you can do that on the server, where both facts are known and no ad blocker can interfere.

The mechanism is the woocommerce_payment_complete hook. It fires in PHP, on your server, the moment a gateway confirms payment. It does not care whether the buyer's browser loaded the thank-you page, ran your script, or accepted cookies. It fires for the PayPal order whose buyer closed the tab. It fires for the visitor who rejected consent. It fires for the uBlock Origin user. Every paid order, once, server-side. (One caveat: offline methods like direct bank transfer sit in an on-hold state until you confirm the money landed, so for those you'd hook woocommerce_order_status_processing instead. For card, PayPal, and the rest, woocommerce_payment_complete is the one.)

From that hook you send the order to your analytics over a simple server-to-server call. Here's the shape of it, sending to a custom-event endpoint:

add_action( 'woocommerce_payment_complete', function ( $order_id ) {
    $order = wc_get_order( $order_id );
    if ( ! $order ) {
        return;
    }

    wp_remote_post( 'https://clickport.io/api/event', array(
        'headers' => array(
            'Content-Type' => 'text/plain',
            'X-API-Key'    => 'ck_your_site_key',
        ),
        'body' => wp_json_encode( array(
            'type'           => 'custom',
            'name'           => 'Purchase',
            'url'            => $order->get_checkout_order_received_url(),
            'revenue_amount' => (float) $order->get_total(),
            'revenue_currency' => $order->get_currency(),
            'meta_keys'      => array( 'order_id', 'payment_method' ),
            'meta_values'    => array( (string) $order_id, $order->get_payment_method() ),
        ) ),
        'timeout'  => 5,
        'blocking' => false,
    ) );
}, 10, 1 );

That's the whole idea. The order is captured at the source of truth, with its revenue and currency, and nothing in the browser can stop it. You can run this alongside your existing GA4 setup if you want to keep client-side data for the buyers it does capture. The server-side event is the safety net underneath it.

How to audit your own store in 15 minutes

Before you change anything, measure your own gap. It takes about 15 minutes and it tells you whether you have a small leak or a flood.

Open WooCommerce, go to Analytics, and note your order count and revenue for the last 30 days. That's your truth. Now open GA4, go to the Monetization or ecommerce purchases report for the same 30 days, and note its purchase count and revenue. Divide. If GA4 shows 85 percent or more of your real orders, you have a normal client-side gap. If it shows less than 75 percent, you have an active failure mode, and the calculator below will help you guess which one.

The numbers the calculator uses are deliberately conservative, and they stack the way the real failures stack: consent first, because it happens before the buyer ever reaches checkout, then redirects, then ad blockers on whatever's left. Your real gap could be smaller if you're mostly on-site card payments, or larger if you lean on PayPal and Klarna in the EU. Either way, compare its output to the actual WooCommerce-versus-GA4 number you measured. If they're in the same neighborhood, you've found your leak.

Where Clickport fits, and where it doesn't

I build Clickport, so treat this section with the appropriate skepticism. I'd rather tell you exactly what it does and doesn't do than oversell it.

Two honest advantages for a WooCommerce store. First, Clickport is cookieless and needs no consent banner, because it doesn't use cookies or cross-site identifiers. That entire consent-rejection loss vector, the 24 percent of stores blocking their own analytics, just doesn't apply. There's no banner to reject. Second, the same woocommerce_payment_complete hook above can post the order straight to Clickport's event API, server-side, so the orders that PayPal and ad blockers hide from GA4 still get captured. The order-received page is on your own domain, not a payment provider's, so even the client-side path has fewer holes than it does on hosted platforms.

Now the limits, because they're real. Clickport is cookieless by design, which means it has no cross-session identity. It cannot tell you a buyer's lifetime value, repeat-purchase rate, or cohort retention, because it doesn't track people across visits. It captures the order and its revenue at the moment of purchase, attributes it to the session that drove it, and shows that revenue against your goals and in your data export. If you need customer-level lifetime analytics, Clickport isn't the tool, and I'd rather you know that now.

What it's good at is the thing this whole article is about: counting every sale and the channel that earned it, without a consent banner, without depending on a browser moment that fails a quarter of the time. If that's the gap you're trying to close, start a free trial and wire up the hook. If you want the conceptual version first, how Clickport works and why we're cookieless both go deeper.

For the Shopify version of this same problem, where the checkout is locked down and you can't run the server hook, see Shop Pay, Apple Pay, PayPal: Why GA4 Misses Revenue. For the broader question of what moving server-side does and doesn't solve, Server-Side Tracking: What It Fixes and What It Doesn't is the companion piece.

Frequently asked questions

Why is my WooCommerce conversion tracking not working?

Most often because the purchase event fires in the browser on the thank-you page, and that page isn't being reached or the script isn't running. The top causes are payment gateways like PayPal and Klarna that redirect customers off-site so they never return to the order-received page, ad blockers that stop the tracking script, consent banners that block analytics until the visitor accepts, and caching plugins that serve a stale thank-you page. The order is saved in WooCommerce either way; only the analytics event is lost.

How do I check if my WooCommerce purchase tracking is working?

Place a real test order and watch GA4's DebugView (Admin, then DebugView) with Google's Tag Assistant connected. You should see a purchase event appear within a minute, carrying a transaction ID, value, and items. If Tag Assistant shows the tag fired but DebugView shows nothing, the event is being dropped after it's sent. If nothing fires at all, the problem is on the page itself. Also compare your WooCommerce order count against GA4 purchases for the same 30 days; a gap over 25 percent points to an active failure mode.

Why am I getting clicks but no conversions in GA4?

Separate two causes. If GA4 shows sessions but zero or very few purchases while WooCommerce shows real orders, the tracking is broken, usually a payment redirect or a blocked script, not your traffic. If WooCommerce and GA4 roughly agree on order count but the conversion rate is just low, then it's a traffic-quality or store problem, not tracking. Confirm a test order appears in GA4 first; that one check tells you which problem you have.

Does WooCommerce have built-in analytics?

Yes. WooCommerce includes an Analytics menu with reports for revenue, orders, products, categories, coupons, taxes, and more, read directly from your database. Because it doesn't depend on browser scripts, it's immune to ad blockers, consent rejection, and payment redirects, which makes it your reliable source of truth for what actually sold. What it doesn't show is where your traffic came from or how visitors behaved before buying. For that you need a separate analytics tool alongside it.

Why don't my WooCommerce orders match my GA4 revenue?

Because they measure different things. WooCommerce records every paid order on the server. GA4 records only the orders whose purchase event survived the browser. The difference is the orders lost to redirects, consent, ad blockers, caching, and script errors. A 15 to 25 percent shortfall is common, and EU stores with consent banners often see 40 to 60 percent. WooCommerce is right; GA4 is undercounting.

Will server-side tracking fix missing WooCommerce orders?

It depends which kind. Server-side Google Tag Manager only relays events the browser already sent, so it does not recover orders lost to redirects, consent blocks, or unloaded thank-you pages. Capturing the order from a server hook like woocommerce_payment_complete does fix those, because it fires the event from your server the instant payment confirms, with no browser involved. The hook is the durable fix; server-side GTM alone is not.

Stop losing orders you already earned

Your WooCommerce database has every sale. The only question is whether your analytics does too, and for most stores the honest answer is no, by a margin they've never measured. It isn't a setting you got wrong. It's that the most important event in ecommerce is being asked to fire in the one place that fails most often: a customer's browser, on a page they might never see.

You can keep patching the client side, or you can capture the order where it's already guaranteed, on your server, the moment the money lands. Start a free trial, wire up the hook, and watch your analytics match your bank account for once. No credit card, no consent banner, two-minute setup.