Meta description: GA4 has 4 different revenue metrics, and each report may show a different one. Which is which, why the numbers don’t match your store, and what to do about it.
If you run an ecommerce store, you almost certainly have Google Analytics 4 (GA4) and use revenue-based reports. Revenue might seem like one of the simplest metrics. Yet it will never match your accounting system. Revenue in GA4 has several pitfalls worth keeping in mind.
A Bit of Technical Context
When someone makes a purchase on your site, the tracking code fires a purchase event. This event contains order information and the contents of the shopping cart.
- Parameter
value— the total order value. According to the documentation, it should be the sum of (product price × quantity) for all products in the order, excluding tax, shipping, payment fees, and other charges. Discounts should be included. - Cart contents — the products the customer bought, including their price and quantity.
What complications can arise? Quite a few.
Passing Incorrect Values
The first issue is that the implementation on your specific store may differ from the specification. For example, you might be sending the value including tax, or including shipping. A typical case: a developer sends the VAT-inclusive price into value because “that’s what the customer sees.” GA4 then reports revenue 21% higher than the actual net figure.
Tips:
- Make sure your tracking codes send data according to the specification.
GA4 Has 4 Revenue Metrics — and Each Report May Show a Different One
A common source of confusion. Most people assume “revenue in GA4” is a single number. It isn’t.
GA4 works with four revenue metrics:
Gross purchase revenue — the simplest revenue metric. A plain sum of all order value parameters, with no adjustments whatsoever.
Purchase revenue — this is the primary metric you’ll see in reports and work with most often. Unlike Gross purchase revenue, it subtracts refunds.
Item revenue — the sum of price × quantity for each item in the order. It does not include shipping, taxes, or discounts applied to the entire order. This is why Item revenue will never match Purchase revenue, even when the implementation is technically flawless.
Gross item revenue — Item revenue without refunds at the individual item level. Useful for product portfolio analysis without refund distortion.
Tips:
- For executive reporting and comparison with financial results, use Purchase revenue.
- For product and category performance analysis, use Item revenue. When comparing with your store, first make sure you know which metric your store reports — and compare like with like.
Vouchers and Refunds — What “Breaks” the Numbers Even with a Perfect Implementation
Here we get to things that look like measurement errors at first glance but are actually properties of how ecommerce works. It’s important to know about them upfront.
Vouchers and negative orders. This is a tricky trap. Purchasing a voucher itself is not subject to VAT — VAT is charged only when the voucher is redeemed. If a customer has a voucher worth 500 CZK and places an order for 400 CZK, the order value after deducting the voucher is negative. Negative values won’t pass through some GA4 event validators, and implementations that don’t account for this will simply discard or incorrectly record such transactions.
Discount codes on orders vs. on items. This is the source of a mysterious difference between Purchase revenue and Item revenue that’s hard to diagnose. A discount applied to the entire order reduces value but does not reduce the price of individual items. Item revenue then shows a higher number than Purchase revenue — and without knowing the implementation details, it looks like a bug.
Tips:
- Make sure you understand how discount and voucher values are calculated.
Consent and Measurement Errors
The biggest gap comes from measurement consent. On a typical website, somewhere between 30 and 70% of visitors give consent — depending on how aggressive your consent collection is.
GA4 can model missing data — it will then display an estimate of transactions without consent. However, this modeling is only approximate and not always available.
There are also measurement blockers (ad blockers, Brave, Firefox), data transmission errors, and technical website issues.
Testing
A fun source of transaction count discrepancies is testing.
- Developers have development/testing environments where tracking codes fire.
- Sometimes someone simply places an order for two million washing machines on your site. And doesn’t pay. This is exactly what you don’t want in your analytics tools — even if you “refund” the order later, the original transaction remains visible in GA4.
Tips:
- Make sure you’re not firing tracking codes on your testing environment.
- Block anomalous transactions.
GA4 vs. Accounting
GA4 is not an accounting system and was never designed to replace your store’s database. It serves trends, attribution, and user behavior — not for comparing absolute numbers with financial statements. If you expect that from GA4, you’ll always be disappointed.
The right question isn’t “why don’t the numbers match” but “what percentage of transactions does GA4 capture?” If that ratio holds steady — say 85–90% — and the trend matches your store’s trajectory, GA4 is working correctly. If the ratio suddenly drops or the trend diverges significantly, that’s a signal to investigate.
Tip:
- Regularly check what percentage of orders you’re capturing in GA4.
Even though GA4 isn’t perfectly accurate, it’s the best available source of data on website performance and marketing campaigns. Without clickstream analytics, you have no attribution, you don’t know where customers come from, and you can’t see what they do on your site.
Note: instead of GA4, you can of course choose a different clickstream tool.
What’s Next — Margins in GA4 via Server-Side GTM
GA4 shows you revenue. It doesn’t show you profitability.
Purchase revenue is a good foundation. But an ecommerce business that wants more from analytics needs to know which campaign or product category actually makes money — not just generates volume. Revenue without margin is an imprecise compass.
Technically, this can be solved via server-side tracking. The principle is simple: on the server, you enrich each transaction with data from your internal system — cost price, margin — and send these values to GA4 as custom metrics. The customer’s browser never sees this internal data because the entire calculation happens server-side.
The result: in your GA4 report — ideally in a custom Looker Studio dashboard — you see gross margin alongside Purchase revenue.
This is an advanced topic that deserves its own article. If SGTM enrichment interests you as a next step, get in touch — I’m happy to discuss whether it makes sense for your setup.
What to Do Now
Revenue in GA4 looks simple, but there are more pitfalls than meet the eye. Here’s a summary of the tips from this article:
- Make sure your tracking codes send data according to the specification.
- For executive reporting, use Purchase revenue; for product analysis, use Item revenue. When comparing with your store, first find out which metric your store reports.
- Make sure you understand how discount and voucher values are calculated.
- Regularly check what percentage of orders you’re capturing in GA4.
- Don’t fire tracking codes on your testing environment, and block anomalous transactions.
If you’re not sure what your GA4 implementation is actually sending, I’m happy to take a look as part of a measurement audit. Just get in touch.