GA4 Purchase Event Missing WooCommerce
Orders are real. Revenue is real. But your purchase signal can vanish between checkout and GA4. This guide helps you diagnose the exact break and fix it.
If you want a full forensic audit (GA4 + GTM + Ads + consent), start here: /services/tracking-and-analytics-integrity/
1) The Ghost Order Problem
“Missing purchase” is different from “purchase exists but revenue is wrong.” Missing means the event never sent, never processed, or got hidden in reporting. That makes ROAS and attribution unreliable.
Three ways “missing” happens
Collection failure
No GA4 request leaves the browser. Common causes: gateway redirects, ad blockers, consent blocking, JS errors.
Validation failure
The hit arrives, but GA4 drops revenue or items because types/fields are wrong (value, currency, items[]).
Reporting suppression
DebugView shows it, but standard reports hide it due to thresholding, identity, or modeled consent.
If you’re seeing revenue mismatches or missing items, use the dedicated fix page: /fix/ga4-purchase-and-revenue-mismatches-woocommerce/
Typical sources of purchase data gaps (example distribution)
Use this chart as a mental model. Your store may differ.
2) Root Cause Taxonomy (What breaks most often)
In WooCommerce, GA4 usually fails because the “Thank You page journey” is fragile. Your order can complete server-side, while the browser never sends the purchase event.
Probability of root cause (example ranking)
Treat this as a checklist order, not a guarantee.
1) Gateway redirects (closed tab)
Users finish on PayPal or a bank page and close the tab before returning to /order-received/.
2) Consent Mode and CMP blocking
The GTM container or GA4 tag never runs when consent is denied or misconfigured.
3) Caching/minification break the dataLayer
Cached order-received pages can load without fresh order data, leaving the purchase payload empty.
If your checkout crosses domains or uses offsite flows, also review: /fix/cross-domain-and-attribution-issues-ga4/
3) Diagnostic Playbook (Stop guessing)
Run a real test order. Keep the Thank You page open. Then follow this decision path to find the exact break.
Start
Step 1: Check GA4 Realtime
Place a test order, then open GA4 Realtime → Events. Do you see purchase?
Signal exists
You likely have a reporting/visibility issue (thresholding, identity, latency, modeled consent). Check DebugView and wait 24–48 hours for standard reports.
Signal missing
Open DevTools → Network and search for “collect”. No request usually means GTM didn’t fire or consent blocked it.
Deep dive
Step 2: Inspect dataLayer + GTM Preview
On the Thank You page, run dataLayer in the console and look for: event: "purchase".
dataLayer.push({
event: "purchase",
ecommerce: {
transaction_id: "15402",
value: 149.50,
currency: "USD",
items: [ /* ... */ ]
}
});If the dataLayer has the purchase object but no GA4 request fires, your GTM trigger/tag/consent logic is the blocker.
4) Fix Protocol (Do the safe fixes first)
Apply fixes based on what you found. Avoid “false fixes” like firing purchase on button clicks. That often creates double revenue.
Gateway returns and closed-tab losses
Turn on “Auto-return” where possible. But don’t trust it fully. If many users never return to your Thank You page, you need a server-side fallback.
If Ads conversions also drift, review: /fix/google-ads-conversion-tracking/
Consent initialization (don’t block the container)
In GTM, make consent rules explicit. If the container is blocked, nothing fires. If you use trigger groups, ensure “purchase + consent granted” is intentional.
Exclude checkout + order-received from caching
Exclude /checkout/ and /order-received/ from page caching. Also exclude GTM scripts from “delay/defer JS” tools that change execution order.
Transaction ID stability (dedupe)
Use the Woo order ID as transaction_id. Fire once. Don’t generate new IDs on refresh.
5) Validation Checklist (How you know it’s fixed)
Verification steps
- ✅ Realtime shows purchase for your test order.
- ✅ DebugView shows correct value, currency, and a populated items[].
- ✅ After processing, standard reports populate (often 24–48 hours).
- ✅ Woo revenue ≈ GA4 revenue (expect some variance; investigate if 10%+).
If you need a monitoring dashboard, see: /articles/visualize-ga4-data-in-looker-studio/
Example DebugView payload
event_name: purchase
params: {
transaction_id: "15402"
value: 149.50
currency: "USD"
tax: 12.00
items: [ ... ] // populated
}If GA4 and Google Ads still disagree after fixes, review the proof framework: /fix/ga4-and-google-ads-attribution-alignment/