GA4 Not Tracking Purchases or Revenue: A Diagnostic

GA4 Not Tracking Purchases: How to Find the Break

Two weeks ago an e-commerce brand selling home goods asked me to figure out why their September Google Ads ROAS had dropped to 0.4. They had not changed bids, budgets, or creative. I opened GA4 and found 89 purchase events for the first ten days of the month. Their payment processor showed 147 completed orders in the same window. That is a 39 percent gap -- roughly EUR 5,200 per day in revenue invisible to Smart Bidding.

The GA4 purchase event was not working for three separate reasons: a currency mismatch sending all revenue as zero, a consent banner blocking the tag for roughly 30 percent of visitors, and a duplicate transaction ID causing GA4 to silently deduplicate legitimate orders. No single failure was dramatic. Together they made the data useless.

This is the pattern I see when GA4 is not tracking conversions correctly. It is rarely one spectacular break. It is three or four small ones stacked together, each invisible in isolation. This post walks through a systematic diagnostic -- symptom, cause, fix -- so you can identify exactly where your purchase data is leaking.

Start Here: Establish the Gap

Before debugging anything, quantify the problem. Compare your GA4 purchase count and revenue against a system that does not depend on browser JavaScript: Shopify admin, Stripe dashboard, WooCommerce orders, your CRM.

Metric	GA4 value	Source-of-truth value	Gap
Purchase count (last 30 days)	?	?	? %
Total revenue (last 30 days)	?	?	? %

If the gap is under 5 percent, your setup is probably fine. Between 5 and 15 percent, something is leaking. Above 15 percent, something is broken. I cover this comparison in more detail in the GA4 tracking audit checklist, but for purchase-specific issues the table above is your starting point.

The Diagnostic: Seven Areas Where GA4 Missing Transactions Originate

1. The purchase event is not firing at all

The simplest cause of GA4 not tracking purchases is that the event never fires. This happens more often than you would expect.

How to check: Open GA4 DebugView (Admin > DebugView) with preview mode enabled, complete a test purchase, and look for the purchase event in the stream. If it does not appear, the event is not reaching GA4.

Common causes:

• The GTM trigger is misconfigured -- it fires on the wrong page, or on a click event that the confirmation page does not produce.
• The confirmation page uses client-side routing (common in React and Next.js checkouts) and the trigger expects a traditional pageview that never fires.
• On Shopify, the checkout extensibility migration moved purchase tracking from checkout.liquid to Web Pixels, and the old tag stopped receiving data. I covered this migration in the Shopify server-side tracking guide.
• A developer removed or broke the data layer push during a site update. No push, no trigger, no event.

Fix: Walk through the purchase flow in GTM Preview mode. Confirm the data layer push fires, the trigger evaluates, and the GA4 tag executes. If any step fails, that is your break.

2. The event fires but parameters are wrong or missing

The purchase event shows up in DebugView. But GA4 reports zero revenue or the Monetization reports are empty. This means GA4 conversion tracking is not working at the parameter level.

What to inspect in DebugView or Tag Assistant:

Parameter	Required for	What goes wrong
transaction_id	Deduplication	Missing or hardcoded to a static value -- GA4 deduplicates by transaction_id, so identical IDs cause legitimate orders to be dropped
value	Revenue reporting	Missing, hardcoded to zero, or passed as a string ("149.00") instead of a number (149.00)
currency	Revenue calculation	Missing -- GA4 defaults to USD when no currency is set, silently converting non-USD revenue at whatever rate it applies
items[]	Product-level reports	Empty array or missing entirely, which blanks out every item-scoped dimension

The currency issue is the one I find most often in European accounts. A store transacts in EUR but the data layer omits the currency parameter. GA4 records the value as USD. The Monetization report shows revenue, but the number is wrong and does not match anything in the back end. If the store uses multiple currencies, the distortion compounds.

3. Consent blocks the tag entirely

In GDPR markets, consent banners that are not connected to Consent Mode v2 will block GA4 from loading for every visitor who declines cookies. Research from Didomi shows that roughly 25 percent of European visitors do not consent, and the rate is higher in Germany and France. If your consent integration is missing or stuck in Basic mode, those visitors produce zero data -- no purchase events, no revenue, nothing.

How to check: Decline cookies on your site. Open browser DevTools > Network and filter for requests to analytics.google.com or google-analytics.com. If no requests appear, Consent Mode is missing or misconfigured.

Fix: Implement Consent Mode v2 in Advanced mode. Advanced mode fires Google tags in a restricted, cookieless state when consent is denied. Google then applies behavioral modeling to estimate the conversions it cannot directly observe. The modeling requires at least 1,000 daily events with analytics_storage='denied' for seven consecutive days before it activates.

4. Duplicate transaction IDs cause silent deduplication

This one is counterintuitive. GA4 not tracking revenue sometimes means GA4 is actively dropping events it considers duplicates.

GA4 uses the transaction_id parameter to deduplicate purchase events. If two purchase events arrive with the same transaction_id within the same property, GA4 keeps the first and discards the second. That is correct behavior when a user refreshes the confirmation page and the tag fires twice. It is destructive when the transaction_id is hardcoded, auto-incremented incorrectly, or reused across sessions.

Scenarios I have seen:

• A staging environment and production share the same GA4 property. Test orders use transaction IDs that collide with real ones.
• The transaction_id is generated client-side and resets on page reload, producing IDs like 1, 2, 3 that collide across different customers.
• On Shopify, both the native Google & YouTube channel and a custom GTM pixel fire the purchase event. Same transaction_id, same property -- GA4 keeps one, discards one. The numbers look roughly right, but depending on timing, either tag's data wins, and parameter completeness varies.

Fix: Ensure transaction_id is a globally unique value sourced from your order management system. Verify with DebugView that each purchase produces exactly one event with a unique ID.

5. The key event toggle is off

The purchase event fires. Parameters are correct. But GA4 not tracking conversions in reports means the event was never marked as a key event.

Google renamed conversions to key events in 2024. I wrote about the practical impact in GA4 Key Events vs Conversions: What Actually Changed. The rename caused some properties to lose their conversion designation -- either through a migration bug or because someone recreated the property and assumed the setting carried over. It does not.

How to check: Go to Admin > Key events. Confirm purchase is listed and toggled on. If it is missing, toggle it. Note that the key events report only populates from the date you enable the toggle -- it does not backfill.

6. Ad blockers and ITP suppress the client-side tag

Even with everything configured correctly, client-side GA4 tags are vulnerable to suppression. Ad blockers on desktop affect roughly 30 percent of users and many block Google Analytics alongside ads. Safari's Intelligent Tracking Prevention caps JavaScript-set first-party cookies at seven days, which does not prevent purchase events from firing but destroys attribution -- a purchase that happens eight days after the click appears as direct traffic instead of the campaign that drove it.

This does not show up as GA4 missing transactions in absolute numbers. It shows up as inflated direct traffic, deflated campaign ROAS, and a persistent gap between GA4 revenue and back-end revenue that no parameter fix can close.

Fix: Implement server-side tracking via a server-side GTM container on your own subdomain. Server-side tracking routes requests through your infrastructure, making them invisible to ad blockers and allowing server-set cookies that persist beyond the seven-day ITP cap. In accounts I have migrated to server-side, purchase capture rates improved from roughly 65 percent to above 90.

7. Data processing lag and reporting identity thresholds

Sometimes GA4 is tracking purchases but the reports do not show them yet -- or they are hidden behind thresholding.

GA4 standard reports can take 24 to 48 hours to process, and Google warns of up to 72 hours during peak periods. If you just marked purchase as a key event or deployed a new tag, wait a full day before troubleshooting the reports.

Thresholding is a separate issue. When reporting identity is set to "Blended" and your traffic volume is low, GA4 withholds rows to prevent identifying individual users. A yellow icon appears in the report header. Switch reporting identity to "Observed" under Admin > Reporting Identity to eliminate thresholding, at the cost of losing cross-device modeling.

A Quick Diagnostic Sequence

Run through this in order. Each step takes under five minutes.

1. Compare totals. GA4 purchase count versus back-end order count for the last 30 days.
2. DebugView. Complete a test purchase. Confirm the event appears with correct transaction_id, value, currency, and items.
3. Consent check. Decline cookies, inspect network requests. Verify Consent Mode pings appear.
4. Key event toggle. Admin > Key events. Confirm purchase is toggled on.
5. Tag count. Load the confirmation page in Tag Assistant. The purchase event should fire exactly once.
6. Transaction ID uniqueness. Check that transaction_id values in recent events are unique. If you have BigQuery export enabled, a simple query against your events table can surface duplicates instantly.
7. Wait 48 hours. If the event appeared in DebugView but not in reports, give processing time before escalating.

If you have worked through all seven areas and the numbers still do not match -- or if you do not have the access, time, or confidence to run the diagnostic yourself -- I can do it for you. I will identify every leak, prioritize by revenue impact, and give you a concrete fix list.

FAQ

Not sure your purchase tracking is trustworthy? Get in touch -- I will run the full diagnostic against your property and tell you exactly what is broken and how to fix it.