Auditing GA4 Purchase Event Revenue Values
A revenue figure in a dashboard carries no warning label when it is wrong, and it looks identical when it is right. Ivan Sp traces exactly how a GA4 purchase event’s revenue value gets set, rather than trusting the dashboard figure at face value. A misconfigured value produces confident, wrong ROI numbers, and the failure is silent until someone actually checks.
Why Revenue Values Silently Break
A purchase event’s revenue value can pull from the wrong data layer field. The value can also get set correctly once and broken by a later site update, or never configured beyond a rough default. None of these failures throw an error. The event still fires, and the number it reports is simply wrong.
Three Places to Check
Start in GA4’s own interface, under Admin, Events, and the Conversions configuration for the purchase event. Confirm which parameter is actually mapped to the value field, rather than assuming it matches the intended one.
Next, check the site’s e-commerce data layer implementation directly. Confirm the value pushed at the moment of purchase matches the actual transaction total, not a subtotal or a value excluding tax and shipping.
Finally, check the raw gtag or GTM configuration on any site using custom implementation. A manual setup is where field-mapping errors most often originate.
Why Taking the Number at Face Value Is a Real Risk
A revenue figure pulling from the wrong field can be consistently wrong in either direction, understating or overstating real return. A budget decision made on a wrong number looks exactly as confident as one made on a correct number. Nothing about a wrong dashboard figure signals its own error.
When to Run This Audit
This check belongs at the start of any engagement using GA4 revenue data for decisions, as part of the setup work covered under GA4 and Google Tag Manager implementation. Checking once at setup prevents months of decisions made on a broken figure.
Where the Standard Measurement Advice Breaks Down
Has anyone traced a single order from the receipt to the dashboard?
- The usual advice
- Compare the analytics revenue total against the platform total, and investigate if they differ.
- What holds up in practice
- The totals can match while the value is wrong. Refunds, tax handling, and currency conversion can offset each other, and a matching total conceals a value that is wrong on every individual order.
Picture a team reconciling monthly totals that agree within two percent. The measurement is declared sound and the reporting continues.
Tax was included in analytics and excluded in the platform, while unreported refunds offset the difference. Both errors were real and they happened to cancel.
I trace one order end to end rather than comparing totals. A single order checked against the receipt settles what a monthly comparison cannot.
Every ROI figure and every channel decision downstream inherits the fault. A wrong value does not announce itself, and it is quoted in meetings for years.
If your revenue value is wrong, every budget decision made from it is wrong in the same direction. Nothing in the dashboard will ever tell you.
Four Things Commonly Assumed About Revenue Tracking
Which of these has your revenue reporting been checked against?
Ivan Sp meets these four assumptions on most measurement audits.
| Commonly assumed | What actually holds |
|---|---|
| Matching totals means correct tracking. | Offsetting errors produce matching totals. Tax handling and unreported refunds routinely cancel each other out. |
| The platform sends the right value automatically. | Whether tax and shipping are included is a configuration decision, and the default rarely matches what the business reports. |
| Duplicate purchases are obvious in the data. | A refreshed confirmation page fires a second purchase event. Without a transaction_id, GA4 counts both. |
| Currency only matters for international stores. | A missing currency parameter leaves GA4 assuming the property currency, which silently misstates every foreign order. |
| Revenue reporting is a finance concern. | Every channel decision is made from it. A wrong value misdirects budget rather than merely misreporting it. |
The figure you are about to base next quarter’s budget on takes twenty minutes to verify. Nobody ever regrets having checked it.
Where a Purchase Value Comes From
- The event
- The GA4 purchase event, which carries a value and a currency parameter.
- Required parameters
- value, currency, and transaction_id, plus the items array for item-level reporting.
- Currency handling
- GA4 converts to the property currency using a daily rate when currency is set.
- Common fault one
- Tax and shipping included or excluded inconsistently between platform and tag.
- Common fault two
- Value passed as a string with a currency symbol, which fails to parse cleanly.
- Common fault three
- Duplicate purchase events on a refreshed confirmation page.
- Deduplication
- transaction_id is what allows GA4 to discard a repeated purchase.
- Verification surfaces
- GA4 DebugView, Tag Assistant, and the browser network panel.
A Worked Example: One Order, Traced End to End
Consider a single order checked against three sources. The comparison below is illustrative, written to show where values diverge. No client engagement is described here.
| Source | Value recorded | What it includes |
|---|---|---|
| Customer receipt | $248.50 | Subtotal, tax, and shipping |
| Platform order record | $215.00 | Subtotal only |
| GA4 purchase event | $248.50 | Subtotal, tax, and shipping |
| Currency parameter sent | Absent | GA4 assumed the property currency |
| transaction_id sent | Present | Deduplication working |
| Reported monthly total | Within 2% of platform | Offset by unreported refunds |
I read rows two and three together. The two systems are measuring different things, and the monthly comparison never revealed it.
Comparing monthly totals is weighing two bags of shopping and concluding they hold the same items. The scales agree and the contents do not.
The currency row is the quiet one. An absent parameter is invisible until a foreign order arrives, and then it misstates silently.
The Audit, Step by Step
I trace one real order end to end rather than reconciling totals.
- Place a real test order, or pick a recent one you can see the receipt for.
- Open GA4 DebugView and locate the purchase event for that transaction.
- Read the value parameter and compare it against the receipt to the cent.
- Confirm whether tax and shipping are included, and whether the business reports revenue the same way.
- Check that currency is present and correct, since an absent parameter defaults silently.
- Confirm transaction_id is present, which is what prevents duplicate counting.
- Refresh the confirmation page and watch whether a second purchase event fires.
- Check the items array, since item-level reporting fails independently of the order total.
- Compare a full month of GA4 revenue against the platform, with refunds included in both.
- Document how revenue is defined, so future reports use one definition.
How This Engagement Is Scoped
What You Need Before You Start
- Time required
- About twenty minutes for a single order trace.
- Access needed
- GA4 admin access, the ecommerce platform, and one real receipt.
- Tools required
- GA4 DebugView and a browser. Both are free.
- Skill level
- Able to read a JSON event payload and compare two numbers.
- What can go wrong
- Reconciling totals instead of tracing an order, which hides offsetting errors.
- Expected result
- A confirmed revenue definition, and any parameter fault named specifically.
- When to hire instead
- Multi-currency stores, subscription billing, or server-side tagging.
Tools and Primary Sources
The references below document the event and its parameters. Each opens in a new tab.
- GA4 purchase event reference documents the required and recommended parameters for the purchase event.
- GA4 ecommerce measurement covers the full ecommerce event set and the items array structure.
- GA4 DebugView shows the event and every parameter arriving in real time.
- Google Tag Assistant inspects which tags fire on the confirmation page and what each sends.
Trace One Order Today
I suggest the single check that finds most revenue faults.
- Open GA4, then Admin, then DebugView, and leave it open.
- Complete a small test purchase on your own site in another tab.
- Find the purchase event in DebugView and read its value parameter.
- Compare that number against the receipt, including tax and shipping.
A value that differs from the receipt by exactly the tax amount is the most common fault. A missing currency parameter is the second, and neither shows up in a monthly total.
Common Questions
How would I know if my revenue values are wrong without an audit?
There is often no visible sign, since the event still fires and produces a plausible-looking number. Cross-checking a sample of individual transactions against the reported total is the most direct way to catch a mismatch.
Does this apply to Universal Analytics as well as GA4?
The specific configuration paths differ between the two. The underlying discipline, tracing the value back to its actual source, applies to both.
Should this audit run after every site redesign?
Yes. A redesign frequently touches the data layer implementation, which is exactly the kind of change that can silently break a previously correct revenue value.
Should the revenue value include tax and shipping?
Either is defensible, and consistency is what matters. The value sent to analytics should match how the business defines revenue internally, and that definition should be written down.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.