Measurement
Make the numbers usable before bigger CRO decisions depend on them: events, totals, funnels and practical reporting notes.
Read our five-star reviews on Trustpilot
If GA4 revenue doesn't match your WooCommerce orders, you're making decisions on data you can't trust, and a small, explainable gap is normal, but a large or patterned one means the tracking is broken. We repair GA4, GTM and the WooCommerce data layer so that one order becomes exactly one GA4 purchase, refunds are recorded, consent is handled correctly, and the numbers are provable before any decision or test relies on them.
The recommended GA4 ecommerce events, a valid items array, and a unique order-based transaction_id on every purchase, implemented through the most auditable route, which for a serious store is GTM plus a WooCommerce data layer, inspectable in Tag Assistant, DebugView and BigQuery.
GA4 deduplicates on transaction_id, keeping the first and ignoring the second, but only when the ID is present, unique and never blank. We make sure only one path can emit purchase and that the trigger depends on the real order-received state.
We tie the purchase event to WooCommerce's actual thank-you lifecycle rather than a generic page view, restore it on customised or builder-heavy templates, and set unwanted-referral handling for payment domains.
We implement Consent Mode v2 correctly (the ad_storage, analytics_storage, ad_user_data and ad_personalization signals) and align it with UK PECR, without hard-blocking tags in a way that destroys modelling.
We send a refund event against the original transaction_id, with item data, so GA4 reflects net commercial reality.
GA4 value excludes shipping and tax, which BigQuery stores separately, so we standardise the comparison instead of treating an accounting definition as a tracking bug.
Internal-traffic filters, web-hostname filters and separated QA streams, because GA4's automatic bot exclusion isn't exhaustive.
We document the order-to-purchase path, data-layer events, GTM triggers, consent states and refund handling so the setup can be QA'd again after plugin, gateway or template changes.
Our standard is simple: before any CRO decision or A/B test uses GA4 data, we can prove that one WooCommerce order becomes one and only one GA4 purchase, and one refund becomes one GA4 refund, under your real consent and gateway conditions. We validate the browser path in Tag Assistant, confirm it lands in DebugView and Realtime, run controlled test orders across every gateway, device and consent state, then reconcile real order IDs against GA4, using BigQuery for dependable order-level checks. On a controlled QA run the target is effectively 100% on the tested journeys; on live traffic, once technical faults are removed, a residual gap of roughly 5–10% can be normal because of consent and browser loss, while a persistent gap larger than that usually means something is still broken.
Because GA4 is an event-based measurement system constrained by consent, browser blocking and modelling, while WooCommerce is the order system of record. A small residual gap can be normal; a bigger or patterned gap usually means the tracking needs fixing.
We check whether the same WooCommerce order ID appears more than once in GA4 or BigQuery, then inspect the purchase trigger in Tag Assistant. GA4 deduplicates on transaction_id, so blank or repeated IDs are the first thing we audit.
Because many WooCommerce setups only fire the purchase event on the thank-you page, and some redirect flows or custom templates never return the buyer there with the right WooCommerce hooks intact. We tie the event to the real order-received lifecycle instead.
Only under the ICO's narrow 2026 statistical-purposes exception, sole service-improvement statistics, aggregate outputs and a simple objection mechanism. Tracking individuals or using analytics for advertising still requires consent, so a compliant consent setup remains the conservative default.
Start Here
Book the phase-one audit so we can review one revenue-critical WooCommerce journey first.