Orders are going through, customers are paying, and the payment processor confirms it — but GA4's ecommerce reports show $0 in revenue, zero transactions, and an empty monetization overview. If this is what you're looking at right now, the good news is that your tracking almost certainly isn't missing entirely. Something is firing; it's just misconfigured in a way that prevents GA4 from recognizing the purchase data, and the fix is usually one of six specific problems.
This piece walks through each cause in order of how commonly it appears in container audits, starting with the one that takes five minutes to fix and ending with the structural issues that need more investigation.
The ecommerce reporting toggle
The single most common cause of $0 revenue in GA4 is an admin setting. GA4 has an ecommerce reporting toggle under Admin > Property settings > Ecommerce settings that must be explicitly enabled before ecommerce data appears in reports, and the setting doesn't affect data collection — your purchase events still fire and the data still reaches GA4, but with the toggle off, GA4 doesn't process those events into the monetization reports.
This catches people because everything else looks correct. The GTM tag fires, DebugView shows the purchase event, the parameters are all there, but the ecommerce reports remain empty because GA4 isn't looking for ecommerce data in the first place.
Check this first — it takes 30 seconds to verify and is the cause often enough that it should be the default starting point. If the toggle is off, enable it and wait 24-48 hours for data to populate; if it was already on, move to the next cause.
Missing required purchase parameters
GA4's purchase event requires three specific parameters — transaction_id, value, and currency — and all three must be present. If any one is missing, GA4 records the event but doesn't calculate revenue metrics from it, which is a silent failure: you'll see "purchase" appear in your event list with an event count, but the revenue column stays at zero.
The currency parameter trips people up most often. In Universal Analytics, currency was optional and defaulted to the property's currency setting, but in GA4, currency is mandatory on every ecommerce event. Send a purchase event without currency: 'USD' (or whatever applies) and GA4 processes the event but discards the monetary value — your purchase count might look correct while revenue shows nothing. Google's ecommerce implementation guide lists the required parameters per event, and currency appears on every one that involves a monetary value.
The value parameter has its own pitfall: it needs to be a number, not a string. If your data layer pushes value: "49.99" as a quoted string instead of value: 49.99 as a numeric value, some GA4 implementations handle the type coercion and some don't, depending on how the GTM variable is configured. The safest approach is to ensure the data layer always pushes numeric values for price and revenue fields.
The diagnostic: open GA4 DebugView, complete a test purchase, and inspect the purchase event. Click into it and verify that transaction_id, value, and currency all appear with the expected values. If any of the three is missing, the fix is in whatever populates your data layer — whether that's your ecommerce platform's GA4 integration, a custom data layer push, or a GTM variable configuration.
Purchase event on the wrong trigger type
This one is subtle and doesn't show up in DebugView the way you'd expect. The purchase event should fire on a data layer event — specifically when the data layer receives a push containing the purchase event data — but in some implementations, the GA4 event tag is configured to fire on a page load trigger (like "Page View" or "DOM Ready") on the order confirmation page instead.
The difference matters because of timing. A page load trigger fires when the page loads, but the ecommerce data layer push may not have happened yet, so the GA4 tag fires, finds no ecommerce data in the data layer, and sends a purchase event with no parameters. Or it fires before the backend has finished writing the transaction data to the page, sending partial information. Either way, the event fires but the revenue data is incomplete or absent.
The correct trigger for a purchase event is a Custom Event trigger in GTM that matches the data layer push event name. If your ecommerce platform pushes {event: 'purchase', ecommerce: {...}} to the data layer, your GTM trigger should be a Custom Event trigger listening for the event name purchase, which ensures the GA4 tag only fires after the ecommerce data is available in the data layer.
To check: open your GTM container, find the GA4 event tag that sends the purchase event, and look at its trigger. If the trigger is any form of page load (All Pages, DOM Ready, Window Loaded, or a Page View trigger filtered to the confirmation URL), that's likely your problem — switch it to a Custom Event trigger that matches your data layer push.
Checkout domain splits
This is the one that doesn't show up in GTM at all, because the problem is architectural rather than configurational. When a customer starts checkout on your domain and gets redirected to a third-party payment processor (PayPal, Stripe Checkout, a hosted payment page), the session breaks: the customer leaves your domain, completes payment on the processor's domain, and returns to your order confirmation page, and GA4 treats the return as a new session referred by the payment processor.
The result is that GA4 attributes the purchase to the payment processor as a referral source rather than to the original traffic source. Your revenue might actually be recording, but it's attributed to "paypal.com" or "checkout.stripe.com" instead of the Google Ads campaign or organic search session that actually drove the sale. If you're filtering reports by specific channels or campaigns and seeing $0, the revenue exists but it's in the wrong bucket.
The fix is GA4's referral exclusion list. Under Admin > Data Streams > Configure tag settings > List unwanted referrals, add every third-party domain that appears in your checkout flow — common ones include paypal.com, checkout.stripe.com, and any hosted payment page domain your processor uses. After adding them, GA4 will stop treating returns from those domains as new sessions and will preserve the original attribution.
A second fix for some platforms: check whether a server-side purchase confirmation is available that doesn't depend on the customer returning to your site. If a customer completes payment on PayPal but closes the tab instead of clicking "return to merchant," your client-side purchase event never fires. Server-side solutions (Measurement Protocol, or platform-specific webhooks) capture these transactions regardless of browser behavior.
Incomplete ecommerce funnel coverage
GA4's ecommerce model defines a sequence of events — view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, and purchase — and many implementations only track view_item and purchase, skipping everything in between. This doesn't directly cause $0 revenue, but it creates blind spots that make diagnosing revenue problems much harder.
When the full ecommerce funnel is implemented, GA4's funnel exploration report shows exactly where users drop off: how many viewed a product, how many added to cart, how many started checkout, how many completed purchase. When intermediate steps are missing, the funnel appears to go directly from product view to purchase (or product view to nothing), and you lose the diagnostic visibility that would help you understand conversion problems.
The more insidious issue is that some implementations track intermediate events inconsistently — maybe add_to_cart fires for some products but not others because the data layer push is implemented on some product templates but not all. The funnel looks partially populated but the numbers don't reconcile, making it impossible to trust any single metric in the chain.
If you're troubleshooting $0 revenue and have already checked the previous four causes, audit your full ecommerce event coverage. Use DebugView to walk through a complete purchase flow from product page to confirmation, and every step should produce an event with the correct parameters. Gaps in this sequence mean gaps in your ability to diagnose what's going wrong.
Verifying the fix from DebugView to reports
Once you've identified and fixed the problem, verification follows a specific sequence because GA4 processes data at different speeds in different places.
DebugView (immediate): Enable debug mode in GTM Preview, complete a test transaction, and confirm the purchase event appears with all required parameters. This validates that the tag is firing correctly and the data is leaving your site as expected — if parameters are missing here, the fix isn't working yet.
Realtime reports (minutes): After confirming DebugView looks correct, check GA4's Realtime report. You should see the purchase event appear in the event count within a few minutes; Realtime won't show revenue detail, but it confirms the events are reaching GA4's processing pipeline.
Standard reports (24-48 hours): Ecommerce data in standard GA4 reports takes 24-48 hours to fully process, so don't panic if the monetization overview still shows $0 the day you deploy the fix. Check back the next day — if data appears, the fix worked; if it doesn't, re-check DebugView to confirm the events are still firing correctly in production (not just in preview mode).
Historical data: GA4 does not retroactively fix revenue data, which means transactions that occurred while the configuration was broken will remain at $0 in reports. Revenue tracking begins from the moment the fix goes live, not from when the problem started. For historical reconciliation, compare GA4 data against your payment processor or ecommerce platform's native reporting for the affected period — this comparison also gives you a baseline for validating that the fix is working, because once the GA4 revenue numbers start tracking within a reasonable margin of your payment processor's numbers, you know the implementation is correct.
Scanning for ecommerce configuration problems
The $0 revenue problem is almost always one of the six causes above, and each one is fixable. The challenge is that ecommerce tracking has more moving parts than most GA4 configurations, requiring coordination between your ecommerce platform, your data layer, your GTM container, and your GA4 property settings — any break in that chain produces missing revenue.
TagManifest checks for the container-level ecommerce problems described in this piece: the sendEcommerceData configuration, missing required parameters on purchase events, purchase events on the wrong trigger type, ecommerce events firing on page load instead of data layer events, and incomplete ecommerce funnel coverage. It won't catch GA4 admin settings or domain-level issues (those live outside the container), but it covers the GTM configuration causes that make up the majority of $0 revenue problems.
If you're still troubleshooting after checking all six causes, the GA4 data quality audit checklist covers the broader set of GA4 configuration issues that can affect ecommerce data alongside the rest of your event model.