Short answer: in nearly every store I have audited, the analytics were lying — and usually in a predictable direction. Some orders never arrive, some are counted twice, and the traffic source gets lost on the payment gateway redirect. The problem isn't that the numbers are imprecise; you can live with that. The problem is that budget decisions are made on top of them.
Six reasons the numbers don't match
1. Cookie consent. If someone declines, some events never fire. Consent Mode partially fills the gap with modelling, but that is an estimate, not a fact. The key point: the loss is not random — certain segments decline more often, and your picture skews.
2. Duplicate purchases. A customer refreshes the "thank you" page and purchase fires again. Or the event lives both in the theme and in an analytics plugin. Classic symptom: GA4 shows noticeably more orders than the admin.
3. Source lost at the payment gateway. Payment goes to the bank's domain and comes back — new session, and the source becomes the bank or "direct". In reports this reads as "direct traffic converts brilliantly", and budget goes to the wrong place.
4. Blockers and browser restrictions. Some traffic simply isn't measured. Not a reason to give up, but a reason to distrust absolute numbers and watch trends instead.
5. Refunds and cancellations aren't deducted. GA4 shows placed orders. If you have 15% returns or a meaningful cancellation rate on cash-on-delivery, the "revenue" in your reports is revenue before subtracting what came back.
6. The same word meaning different things. "Conversion" in GA4, in the ad platform and in your head are three different metrics with three attribution windows. Arguments about numbers are often arguments about definitions.
An hour-long reconciliation: three numbers that must match
This is the single most useful procedure in this topic. Take one calendar month and compare three values from GA4 against the WooCommerce admin:
| Metric | Where to look | Acceptable gap |
|---|---|---|
| Order count | GA4 purchase vs order list | up to 10% |
| Revenue | GA4 revenue vs order totals | up to 10% |
| Average order value | revenue / orders in both | up to 5% |
What the result tells you:
- More orders in GA4 — duplicate events. Look for a double tag installation or re-firing on thank-you page reload.
- Fewer orders in GA4 — events are being lost. Usually redirect payments or declined cookies.
- Orders match, revenue doesn't — the event carries the wrong amount: shipping included or not, tax included or not, currency, discounts.
Until this reconciliation lands, every report by channel, campaign and product is unreliable. And conversely: once it lands, you have earned the right to make decisions from data.
What to measure besides conversion
Conversion is not a business goal. You can raise it with a 30% discount and go broke. The minimum set worth reviewing monthly:
- Margin by channel, not revenue. The channel producing the most revenue often produces the least profit.
- CAC — customer acquisition cost. Ad spend plus everything else, divided by new customers.
- Repeat purchase rate. The most underrated metric in small ecommerce — it has its own topic: retention and LTV.
- LTV to CAC. If a customer's lifetime value is below what it cost to acquire them, scaling ads accelerates the loss.
- Returns by product. A product with a 40% return rate can be loss-making at an excellent conversion rate.
- Speed (Core Web Vitals). The one technical metric worth keeping in a business report, because it moves all the others.
Attribution: why "last click" misleads
Last-click gives all the credit to the final touch. As a result brand search and email look heroic (they are always last), while whatever first brought the person in looks worthless. Real ecommerce journeys are rarely single-step: saw it on social → googled it → left → came back from an email → bought.
A practical approach for a small store, without building complex models:
- Look at assisted conversions, not only last click
- Ask customers directly ("how did you hear about us?") — in a post-purchase survey, not in checkout
- Test channels by switching them off: pausing a campaign for two weeks and watching total revenue is more honest than any model
Developer note
- One source of events. Theme, or plugin, or GTM — not all three. Double-fired
purchaseis the number one cause of discrepancies. - Make purchase idempotent. Send
transaction_idand protect the thank-you page from re-firing on reload. - Server-side sending for redirect payments. Firing
purchasefrom the server when the order status changes (via the Measurement Protocol) solves both the redirect loss and part of the blocking. The event spec is in the GA4 ecommerce documentation. - Consent Mode goes before the tags, not after. Initialisation order matters; get it wrong and you either lose data or send it without consent. Setup is covered in Google's consent guide.
- Refunds are events too. Send
refundwhen you refund, otherwise revenue reports stay permanently inflated. - Don't load tags synchronously in
<head>. Render-blocking analytics degrades LCP and INP — you are paying for measurement with speed.
If that goes beyond what you want to handle yourself, I offer it as a separate service: analytics and conversion tracking.
Practical check
- Reconciled orders, revenue and AOV in GA4 against the admin for one month
- Order gap is under 10%
-
purchasefires exactly once and carries atransaction_id - Redirect payments don't lose the traffic source
- Funnel step events are configured:
view_item,add_to_cart,begin_checkout - Refunds are reflected in analytics
- Consent Mode is configured and sends nothing before consent
- I know my CAC and repeat purchase rate, not just conversion
What's next
Once the numbers can be trusted, the biggest hole in most stores becomes visible — and it isn't conversion, it's what happens after the first purchase: retention and LTV.