You check your GA4 Monetisation reports and see purchase events but no revenue. Or revenue is present but dramatically lower than your store backend shows. Or revenue appears intermittently, correct some days and missing others. These are among the most consequential tracking failures in an ecommerce setup because they corrupt every ROAS calculation, every conversion rate report, and every budget decision downstream. Missing revenue in GA4 almost always comes from one of a small set of specific technical failures. This guide covers every common cause in order of likelihood, with the diagnostic steps for each.
The most common cause: event name is not exactly purchase
GA4 will only calculate Purchase revenue, Item revenue, and all associated monetisation metrics when the triggering event is named exactlypurchase. Case-sensitive, no spaces, no underscores around it, no prefixes or suffixes.
Names like completed_purchase, transaction, order_success, order_complete, Purchase (capital P), or any other variant will result in GA4 recording the event with the correct event count but ignoring the value parameter entirely for revenue calculations.
InDebugView, place a test order and check what event name fires. If it is anything other than purchase, rename the event in your GTM tag or modify the dataLayer push to use the correct name. Our reference onGA4 purchase event parameterslists every required field so nothing else slips through.
Missing currency parameter
In GA4, bothvalueandcurrencyare required for revenue to register. The currency must be a validISO 4217three-letter code. If currency is absent, null, undefined, or formatted as a symbol rather than a code, GA4 discards the revenue for that transaction silently. The event fires, it appears in the Events report, but revenue is zero.
Common implementation errors: sending currency: '$' instead of currency: 'USD', sending currency: '' or not sending it at all, or having a GTM variable that returns undefined when the currency data layer key does not exist on the page. For multi-store setups, our guide onresolving GA4 currency mismatcheswalks through how property-level conversion can mask or amplify the problem.
Missing or zero value parameter
The value parameter contains the transaction revenue. If value is sent as 0, if the GTM variable that reads it returns undefined or null, or if the dataLayer push fires before the order data has populated on the page, revenue will be missing or zero. The pattern of correct purchase counts but zero revenue is exactly what we cover in our breakdown ofGA4 revenue showing zero on purchases.
A common timing issue: the GTM trigger fires on DOM Ready or Page Load before the ecommerce dataLayer push from the order confirmation page has executed. The tag fires, reads an empty or undefined value, and sends a purchase event with value: 0 or value: undefined. This results in purchase events with zero revenue.
Diagnose this with DebugView and by reviewing the timeline of dataLayer events in GTM Preview mode. The ecommerce dataLayer push should occur before the GTM tag fires. If it does not, add a custom event trigger that fires specifically when the ecommerce push occurs, rather than relying on DOM Ready.
GA4 Audits checks every purchase event parameter, value, currency, transaction_id, items array, and flags revenue gaps automatically.
Consent mode blocking the tag
If your site has a cookie consent banner usingBasic Consent Mode, the GA4 tag will not fire at all for users who decline or have not yet interacted with the banner. Purchase events from these sessions will be completely absent from your reports.
If you have recently implemented or updated your consent banner and revenue dropped suddenly, this is the most likely cause. Check GA4 Admin > Data Collection and Modification > Consent Settings to see if consent signals are being received and whether a significant percentage of your traffic is missinganalytics_storageconsent. OurConsent Mode v2 guidecovers how to switch from Basic to Advanced mode without losing purchase data.
Duplicate transaction ids being deduplicated
GA4 uses thetransaction_idparameter to deduplicate purchase events. If two purchase events arrive with the same transaction_id, GA4 counts only the first one. This is intentional behaviour to prevent double-counting from page refreshes or duplicate tag fires.
However, if your implementation generates non-unique transaction IDs (for example, all test orders use id: 'test123', or there is a bug in your order ID generation), real transactions may be silently deduplicated. Each new order should carry its unique order ID as the transaction_id.
A subtler version of this problem occurs with subscription renewals or recurring billing: when a recurring payment is processed server-side and pushed to GA4 via Measurement Protocol, if the renewal order carries the same ID as the original subscription order, it will be deduplicated. For a deeper look at the dedup rules and edge cases, see our guide toduplicate transaction handling in GA4.
GA4 tag not firing on the order confirmation page
An obvious but frequently missed cause: the GA4 Configuration tag or the purchase event tag is simply not installed on the order confirmation page. Some ecommerce platforms have separate checkout domains or post-purchase pages that are managed differently from the main site. Pages added to the site after the initial GA4 implementation may also be missing the tracking code.
Use Google Tag Assistant or GTM Preview mode to confirm the GA4 tag fires on your actual order confirmation page. If your checkout redirects to a third-party payment provider and then returns to a confirmation page, verify the GA4 tag fires specifically on that return page, not just on the pre-payment page.
Ad blockers and browser script blocking
A predictable percentage of users will have ad blockers or browser privacy settings that block the GA4 JavaScript from loading entirely. These sessions will never send a purchase event to GA4 regardless of how correctly your implementation is configured. Ad blocker impact varies widely by audience — developer and tech audiences can lose 20–35% of events, while mainstream retail typically loses a smaller share. Measure your actual rate with a server-side vs. client-side comparison rather than assuming a fixed range.
Server-side tagging mitigates this by sending conversion data from your server rather than relying on the user's browser to execute the tracking script. For ecommerce stores where revenue accuracy is critical, server-side purchase event sending is the most reliable architecture.
Open GA4 DebugView and place a test purchase
Navigate to Admin > DebugView in GA4. Complete a test purchase on your site. Watch for the purchase event to appear in real time in DebugView.
Confirm the event fires and check the name
If no purchase event appears, the tag is not firing or is being blocked entirely. If it does appear, verify the event name is exactly 'purchase', any variation means revenue metrics will not populate.
Inspect the value and currency parameters
Click the purchase event in DebugView to expand its parameters. Confirm value contains a positive number (not zero, not undefined, not a string). Confirm currency contains a valid three-letter ISO 4217 code such as GBP, USD, or EUR, not a symbol.
Check transaction_id uniqueness
Confirm the transaction_id matches your actual order ID and is unique per transaction. Place a second test order and verify a different transaction_id appears in DebugView.
Run a 30-day revenue reconciliation
Compare GA4 total purchase revenue against your store backend for the same period. A gap that exceeds your measured ad blocker loss rate signals a parameter error rather than ordinary event loss — measure your actual ad blocker impact with a server-side vs. client-side comparison.
Diagnosing missing revenue in GA4
Work through these steps when GA4 shows purchase events but zero or understated revenue.
Validate
- Open DebugView and place a real test purchase, confirm a purchase event fires
- Check the event name is exactly 'purchase' (case-sensitive, no variants)
- Inspect the value parameter: it must be a positive number, not zero, null, or undefined
- Inspect the currency parameter: it must be a three-letter ISO 4217 code (GBP, USD, EUR), not a currency symbol
- Verify transaction_id is unique per order, duplicate IDs cause silent deduplication
- Confirm the GA4 tag fires on the actual order confirmation page, not just pre-payment pages
Fix
- Rename any non-standard event names to exactly 'purchase' in GTM or the dataLayer push
- Populate value from the correct dataLayer variable, ensure the ecommerce push fires before the GTM tag trigger
- Replace currency symbols with ISO 4217 codes in the dataLayer or GTM variable
- Switch GTM triggers from DOM Ready / Page Load to a custom event that fires on the ecommerce dataLayer push
- Assign each order a unique transaction_id drawn from your order management system
Watch for
- Purchase event count is correct but revenue shows as zero or near-zero across all transactions
- Revenue is correct on some days but missing on others, suggests a timing or conditional logic issue in the GTM trigger
- A sudden revenue drop coinciding with a consent banner update, may indicate Basic Consent Mode blocking the tag
Missing revenue checklist
- Event name is exactly purchase
- currency parameter is a valid three-letter ISO code
- value contains a numeric amount, not zero or undefined
- transaction_id is unique per order
- GA4 tag fires on the actual order confirmation page
- Consent Mode is not blocking the tag for a significant portion of users
- Server-side purchase event sending is evaluated for high-revenue stores
Catch every revenue gap automatically
GA4 Audits runs 33 e-commerce integrity checks including value parameter validation, currency format, transaction ID uniqueness, and items array completeness, so you catch revenue loss before it compounds.