Why Does Google Analytics Show Different Sales from WooCommerce?

Google Analytics can show different sales from WooCommerce because it measures collected events, while WooCommerce stores orders. Differences also arise from consent and browser blocking, missing or duplicated purchase events, reporting dates, refunds, order statuses and whether the totals include tax and shipping. Match the definitions and compare transaction IDs before deciding which cause applies.

The WooCommerce order record remains the operational record of the sale. If Niwa helps shoppers choose products, the final order still needs to be measured through the store's ecommerce integration. A conversation count cannot reconcile a missing purchase event.

Compare the same period and the same money

Start by writing down the exact WooCommerce report and GA4 metric you are comparing. "Sales" can refer to gross sales, net sales, an order total, purchase revenue or another metric. Similar labels do not guarantee identical definitions.

Match the date range and check the reporting time zones. Compare the same currency, and account for any currency conversion in your store or Analytics property. Allow for processing time before investigating today's incomplete standard report.

Then inspect tax, shipping, discounts and refunds. Google's recommended purchase event defines value as the sum of item price multiplied by quantity, excluding shipping and tax, which have separate parameters. Verify how your integration actually sends those fields using the event reference.

For an illustrative order with USD 80 in discounted items, USD 8 shipping and USD 16 tax, the charged total is USD 104. A correctly defined item-based purchase value can be USD 80. Comparing 104 with 80 without checking the metric creates a discrepancy even when the underlying collection is correct.

Separate missing transactions from amount differences

Use a small sample of private WooCommerce order IDs and corresponding GA4 transaction IDs. Keep the customer information out of the comparison file you share with anyone who does not need it.

First ask whether each transaction appears at all. A missing transaction points toward collection coverage or the trigger. A transaction present with the wrong amount points toward parameter mapping. Repeated transaction records point toward duplicate or inconsistent identifiers.

You do not need to change the whole setup to distinguish those cases. A controlled test order and its event payload often give more useful evidence than another dashboard screenshot.

Check the customer's payment-return journey

The official Google Analytics for WooCommerce integration documents a purchase-tracking requirement: the payment gateway returns the customer to the thank-you or order-received page.

If the customer pays but closes the browser before returning, the store can have an order without the expected browser-side purchase event. Test every relevant payment method and the actual return page, using an approved test method.

Check orders placed by staff, imported orders and other paths that do not follow the ordinary website checkout. They may belong in the WooCommerce report without having generated a browser event. Decide which order population your comparison is supposed to cover.

The WooCommerce integration guide also describes tracking options and troubleshooting. Its supported route is evidence about that extension, not a universal explanation for every store.

Review consent and collection coverage

A customer can complete an order while declining analytics collection or using a blocking extension. Treat that as a collection boundary rather than changing consent settings to force the numbers to match.

Google's consent-mode documentation distinguishes basic and advanced implementations. Modeling and consent-related reporting depend on the actual setup and eligibility. Neither approach establishes that every order will appear as a directly observed purchase.

If the gap changed after a consent-tool update, compare controlled accepted and refused journeys. Record what the tag did in each case. Do not infer the cause solely because two dates are close.

Inspect identifiers, duplicates and refunds

Every real order should have a stable unique transaction ID. Google uses transaction IDs to deduplicate purchases. Reusing one ID across several orders can suppress events; inconsistent IDs across repeated sends can undermine deduplication.

Check whether the theme, an analytics plugin and Tag Manager each send shopping events. Follow Google's ecommerce validation guide rather than removing an arbitrary plugin and hoping the total improves.

Refunds need their own measurement support. A refund recorded later in WooCommerce does not automatically update a previously sent GA4 purchase unless the integration handles the appropriate refund data. Cancellation and order-status rules also need matching definitions.

Use public complaints as clues, not your diagnosis

In a public WooCommerce integration support thread, a store owner reported that purchase events and revenue were below the store's records. Support asked for event tests and reviewed overlapping tracking tools. This is an example of the troubleshooting questions worth asking, not proof that your installation has the same fault.

Maintain a short reconciliation note: report names, period, currency, included amounts, order statuses, missing transaction sample, event payloads and consent test results. Fix the verified mapping or collection issue, then repeat the same comparison.

With Niwa's WooCommerce operations, keep the actual store records as the basis for business decisions. Send Niwa the specific discrepancy you found so the discussion starts with a missing event, wrong amount or measurement boundary instead of an unexplained total.