2026-08-31

GA4 Purchase Event Not Firing on WooCommerce: The Full Diagnostic Order

Your WooCommerce dashboard shows real orders and real revenue this week, but GA4's Ecommerce purchases report is stuck at zero — or showing a fraction of what it should. Reports has run clean for months and nothing in the theme or plugin list obviously changed. This is almost always one of four specific breakages, and checking them in the wrong order wastes hours.

Why this happens

Ranked by how often each one is the actual cause:

• Plugin conflict on the tracking layer. You have two things trying to fire GA4 purchase events at once — for example a GTM-based WooCommerce ecommerce tag plus a plugin like Site Kit, PixelYourSite, or a theme's built-in GA4 integration. One overwrites the other's dataLayer push, or both fire and GA4 dedupes them into nothing visible.
• The order-received (thank-you) page is being skipped. If the customer pays via PayPal, Stripe redirect, bank transfer, or any gateway that sends them off-site and then back via a webhook instead of a browser redirect, WooCommerce marks the order complete without ever loading /checkout/order-received/ in that browser session. If your purchase event only fires on that page's pageview, it never fires for these orders.
• Duplicate transaction_id suppressing the hit. If the order-received page can be reloaded, revisited via back button, or is triggered twice by two tags, GA4 receives the same transaction_id twice. GA4 deduplicates repeated transaction IDs by design — the second (or only surviving) hit is silently dropped, and if the first attempt failed for another reason, you're left with zero.
• Consent Mode blocking the tag. If you run Consent Mode v2 and analytics_storage defaults to denied until a cookie banner interaction, and your purchase tag isn't set to fire on the consent update event, orders from users who never explicitly accept (or who bounce before interacting) never get measured.

Fix, step by step

1. Open your browser's DevTools Network tab, filter for collect?v=2, and place one real test order (or a WooCommerce test order via a sandbox gateway). Confirm whether a request fires at all on the order-received page.
2. Check for a plugin conflict first. In WordPress admin, go to your GA4 tag source — GTM's Tag Assistant preview mode if using GTM, or the plugin's settings page if using Site Kit / PixelYourSite. If more than one tool claims to send the purchase event, disable all but one. Keep the one that reads WooCommerce order data natively (order total, items, currency) rather than a generic pageview-based hack.
3. Rule out the redirect-skip issue. In WooCommerce, go to WooCommerce → Settings → Payments and check which gateways are active. For any off-site gateway (PayPal Standard, some bank transfer plugins), test a full order using that specific method and watch whether /checkout/order-received/ loads in the browser at all. If it doesn't, your purchase tag needs a server-side or webhook-based trigger instead of relying on that pageview.
4. Check for duplicate transaction_id firing. In GTM, open the purchase tag's trigger conditions — confirm it fires once per order_id, not on every page load of the thank-you URL. If you're using a plugin, look for a "prevent duplicate purchase tracking" or "order tracked" meta flag setting.
5. Check Consent Mode. In GTM, open Admin → Container Settings → Consent Overview or inspect the purchase tag's Consent Settings section. Confirm analytics_storage is listed as a requirement and that your consent banner actually updates it via gtag('consent', 'update', ...) before the order-received page loads — not just on page load of the homepage.
6. Re-test with GA4 DebugView open (Admin → DebugView, with the GTM/GA4 debug parameter or Tag Assistant's debug mode enabled) and place one more test order end to end.

Copy-paste verification checklist

GA4 PURCHASE EVENT DIAGNOSTIC — RUN IN THIS ORDER

[ ] Network tab shows a collect?v=2 request on order-received page
[ ] Only ONE tool/plugin is configured to send the "purchase" event
[ ] Off-site gateway orders (PayPal, bank transfer) still trigger tracking
    - if not: switch trigger to order-received webhook, not pageview
[ ] transaction_id in the event = WooCommerce order ID (unique, no reuse)
[ ] Purchase tag fires once per order_id, not once per page load
[ ] Consent Mode: analytics_storage = granted before purchase event fires
[ ] GA4 DebugView shows "purchase" event with correct value + currency
[ ] Ecommerce parameters present: items[], value, currency, transaction_id

How to verify it worked

Open GA4's DebugView, place one test order using each payment method your store actually offers (card, PayPal, bank transfer — whichever apply), and confirm a purchase event appears in real time for every single one, with the correct transaction_id and value. Don't stop at one successful test order via your default gateway — that's exactly the scenario that was probably already working.

Once GA4 is reliably capturing every purchase, the next problem is usually turning that clean data into decisions fast — which is the gap Next Action Analyst is built to close, by taking your campaign exports and GA4 conversions and telling you what to act on next instead of just reporting what happened.