Why GA4 purchase counts don’t match your WooCommerce orders

First, match the comparison

Choose a short date range and compare WooCommerce orders with GA4’s purchase events. Check one order at a time if you can; comparing monthly revenue totals hides the cause of a difference.

• Match the dates. WooCommerce Analytics can group orders by date created, paid, or completed. Its default is Date Paid. GA4 uses the time the event was collected, so an order paid near midnight or after a delay can land in a different day in the two systems. Check the store and property time zones too.
• Match order states. WooCommerce Analytics has configurable excluded statuses. By default it includes Processing, On hold, and Completed orders, while excluding Pending payment, Cancelled, and Failed. An On hold order may still be awaiting payment confirmation, so check the order and payment notes before treating every included order as a completed sale.
• Match the metric. An order count, a GA4 purchase count, gross sales, and GA4 purchase revenue are different measures. Taxes, shipping, discounts, refunds, and currency conversion can make revenue totals differ even when the same order is represented.
• Exclude noise. Check test orders, retries, cancellations, and refunds. A refunded order can still have a purchase event; refunds are a separate event in GA4.

WooCommerce documents its date type, excluded order statuses, and Analytics reports. Use those settings to build a like-for-like comparison before investigating tracking.

Check the WooCommerce side

Open a small set of the orders that appear to be missing. Note their payment method, status, date paid, and order notes. WooCommerce’s order status guide explains the difference between Processing, On hold, Pending payment, Failed, and Completed.

If the orders are missing from WooCommerce’s own Analytics report too, the issue may be with that report’s filters, import, or cache rather than GA4. Check Analytics → Settings for excluded statuses, the data status or failed imports where available, and the selected date type. WooCommerce also documents how to refresh its Analytics cache and retry failed historical imports.

Keep store records as the source for whether an order was actually placed or paid. GA4 is a measurement system; a missing event does not mean the sale itself failed.

Trace one purchase

Use a staging store and a payment gateway’s test mode where possible. If you need to test a live store, use an authorised low-value order and follow your normal refund process. Don’t use a customer’s personal details as test data.

1. Open Brave’s developer tools and choose Network. Turn on Preserve log if checkout redirects to a payment provider or another page. Clear the log before the run.
2. Open GA4 DebugView and select the device you’ll use for the test. Enable debug mode with Tag Assistant or your tag manager’s preview mode.
3. Complete one test purchase, return to the order confirmation page, and note the order’s payment status and time.
4. In Network, search for collect and inspect the request. Confirm the measurement ID and whether the request completed, failed, or was blocked.
5. In DebugView, look for one purchase event from the same test. Open it and check its parameters.

Google’s DebugView guide explains how to enable debug mode and choose the right device. Events may not appear there when analytics consent has not been granted.

A browser response such as HTTP 204 is useful network evidence, but it doesn’t by itself confirm that the intended GA4 property recorded the purchase. Check DebugView as well. Standard reports can take longer to populate, so use the debug event to diagnose a fresh test.

Test consent and blocking separately

For the first run, accept analytics consent and leave Brave Shields off. Confirm that the expected purchase event reaches DebugView. This is your baseline.

Then repeat the same test with Shields on and recovery off. Keep the consent choice, tag setup, payment method, and event the same. In Network, note whether the Google tag loads and whether the event request is blocked, fails, or completes. Brave’s built-in Shields are enough for this check; you don’t need to add a browser extension.

If the event disappears only when a request is blocked, you have evidence that blocking affects this tested setup. If it is missing in both runs, look again at the event trigger, checkout return, measurement ID, consent configuration, or plugin setup.

Now repeat with recovery enabled, while keeping Shields on. Compare the browser request and verify the resulting event in DebugView. The three-run screenshot walkthrough shows how to make that comparison without assuming what every site will do.

Finally, check the behavior with analytics consent declined. A recovery tool should respect the site’s consent rules; don’t use a recovered event to work around a visitor’s choice.

Check duplicates and purchase details

One WooCommerce order should normally produce one intended GA4 purchase event. If it fires twice, check whether more than one component is sending ecommerce events: for example, a WooCommerce analytics plugin, Site Kit, a Google Tag Manager container, theme code, or a separate header snippet. Map what each one sends before changing the live store, then test one source at a time in staging.

Open the event parameters and compare them with the test order:

• transaction_id should be unique to the order and should not contain information that identifies the customer.
• currency should match the transaction’s currency.
• value should follow your intended item-value calculation. Google’s ecommerce guidance defines it from item price multiplied by quantity; send tax and shipping in their own parameters.
• items should contain the products and quantities that were purchased.

Google Analytics deduplicates web purchase events that share a transaction ID. That makes a stable, unique ID useful for retries, but it also means a reused or empty ID can undercount purchases. Use an order reference, not customer information.

Google’s GA4 ecommerce guide shows the recommended purchase parameters and how refunds are measured separately.

When recovery may help

Recovery is relevant when you have confirmed that analytics consent allows the event, the purchase tag is configured to fire, and the browser blocks the tag or request. It won’t fix mismatched report dates, an unpaid order, a missing checkout trigger, duplicate plugins, an incorrect currency, or a reused transaction ID.

If your test shows a blocked request, the WooCommerce installation guide explains where to add Introtrace. After installation, repeat the same test and verify the event and its parameters in GA4. A recovered browser request is a reason to check the event, not proof that every order or every browser is covered.

If the purchase arrives but the traffic source looks wrong, investigate attribution separately. A purchase event can be present even when campaign reporting is incomplete. Keep the event-delivery diagnosis distinct from attribution and revenue reconciliation.