GA4 Ecommerce Events: 12 Best Practices for Accurate Revenue Tracking in 2025
by Trivas.ai
|
7 min read
Oct 01, 2026
Why Most GA4 Ecommerce Setups Have Broken Event Data
Pull up your GA4 revenue number and your Shopify revenue number side by side. There's a decent chance they're off by 10 to 20 percent. Maybe more.
This isn't rare. It's the default state for most DTC brands running GA4 ecommerce tracking without a dedicated setup process. The usual suspects: duplicate purchase events firing twice on the same order, item-level parameters that never got populated, and tracking that only runs client-side, which means it quietly drops events every time an ad blocker or Safari's ITP gets in the way.
None of this shows up as an error. GA4 doesn't warn you. It just reports numbers that look plausible and are wrong, which is worse than an obvious failure because nobody thinks to check.
This post covers 12 google analytics ecommerce events best practices that actually fix broken tracking, not the theoretical GA4 documentation version. If you're trying to get revenue numbers you can actually build decisions on, start here.
Implement the Full Recommended Ecommerce Event Set
Most stores implement two events and call it done: add_to_cart and purchase. That's not an ecommerce funnel, that's two data points with a guess in between.
The full recommended set looks like this:
view_item
add_to_cart
begin_checkout
add_shipping_info
add_payment_info
purchase
refund
Skip begin_checkout and add_shipping_info and you lose the ability to see where checkout actually breaks down. Is it shipping cost shock? Payment friction? A broken form field? Without the mid-funnel events, every checkout problem gets lumped into one vague "cart to purchase" drop-off number, and you're left guessing which step to fix.
Every one of these events also needs an items array, and this is where implementations quietly fall apart. Developers populate item_id and price because those are obvious, then skip item_category and affiliation because nothing breaks immediately if they're blank. Those fields matter the moment you want to segment revenue by category or compare marketplace performance against your own site. Blank fields now mean unusable reports in six months, once you actually need the breakdown.
Fix Duplicate Purchase Events Before They Inflate Revenue
Here's the most common way GA4 revenue gets overstated: the purchase event fires again when a customer refreshes the order confirmation page, or hits the back button and lands there again.
Each refresh is a free, fake transaction as far as GA4 is concerned. On a store doing meaningful order volume, this adds up to real distortion, and it's almost always invisible until someone reconciles against the actual order count.
The fix is transaction_id deduplication. Before firing purchase, check whether that transaction ID has already been sent in this session. Better yet, validate it server-side against a unique order ID from your order management system, so a page refresh can't trigger a second event no matter what the client does.
Build in a standing check too: once a week, pull GA4 transaction count for the last 7 days and compare it against actual order count in Shopify or your Amazon seller dashboard. If GA4 is consistently 3 to 5 percent higher, you've got a duplication problem worth chasing down before it compounds across a quarter of reporting.
Move Critical Events to Server-Side Tagging
Client-side tracking alone loses events. Not occasionally, consistently. Ad blockers strip tracking scripts outright, and Safari's Intelligent Tracking Prevention limits cookie lifespan and script execution in ways that cut into your data. The real-world loss on client-side-only setups tends to land in the 10 to 15 percent range, and it's not random. It skews toward privacy-conscious users and Safari traffic, which means your reporting is biased, not just smaller.
For most events, that's a tolerable gap. For purchase and refund, it's not, because those two events are the entire basis of your revenue reporting.
Move those two to server-side tagging, either through a server-side Google Tag Manager container or a dedicated server endpoint that fires the event based on confirmed order data rather than a browser executing JavaScript. The event fires because an order exists, not because a script managed to run.
The tradeoff is real: server-side setup takes more engineering time upfront, and it's not a drag-and-drop GTM container swap. But for the two events that determine whether your revenue number is trustworthy, it's worth the lift.
Pass Consistent Parameters Across the Funnel
Inconsistent parameters are a quieter problem than duplicate events, but they cause just as much damage downstream.
Start with currency. GA4 will default to whatever's set at the property level if you don't explicitly pass a currency parameter on every event. Fine if you sell in one currency. A real problem if you run a multi-currency store and a UK order gets reported in USD without conversion, which silently misstates revenue by the exchange rate difference.
Coupon and discount parameters matter for the same reason. If coupon isn't passed consistently, promo-driven revenue gets attributed as if it happened at full price, which throws off margin analysis and makes a discount campaign look more profitable than it actually was.
And keep item_id values identical between GA4 and whatever feed powers your Google Ads or Merchant Center listings. Mismatched IDs between the two systems make it impossible to tie ad performance to an individual product's actual on-site conversion behavior, which defeats the point of connecting the two in the first place. For a deeper look at how GA4 fits into a broader revenue tracking setup, the GA4 solution page covers how funnel events should connect to the rest of your stack.
Validate Events With DebugView and BigQuery Before Trusting Reports
Don't launch a new event implementation and assume it's correct. Check it.
GA4's DebugView shows events firing in real time, in order, with full parameter detail. Walk through a full purchase path yourself (view item, add to cart, checkout, payment, purchase) and confirm each event fires in the right sequence with the right data attached. This catches the obvious stuff: a missing items array, a parameter that's firing as a string when it should be a number, an event that doesn't fire at all.
Once you're past the launch-week check, GA4's own UI starts working against you. It samples data on anything beyond a modest volume, and sampled data isn't the number you want to make revenue decisions on. If you're doing meaningful order volume, export raw GA4 event data to BigQuery and query it directly. No sampling, full event-level detail, and you can join it against your own order data to spot discrepancies yourself.
A quick audit checklist worth running monthly:
Event count vs. actual order count for the period
Percentage of purchase events missing item-level parameters
Currency mismatches between GA4 and your payment processor
Our data dictionary is a useful reference if you're not sure which GA4 parameters map to which standard ecommerce metrics.
Skip the Spreadsheet Audits with Automated Revenue Reconciliation
Manually checking GA4 against Shopify and ad platform revenue every week works fine when you're doing a few hundred orders a month. Past that, it stops scaling. You end up with someone on your team spending hours every Monday pulling three exports into a spreadsheet just to confirm the numbers roughly agree, and that's hours spent catching errors after they've already shaped a week of decisions.
Trivas pulls GA4 funnel events, Shopify order data, and ad spend into one Redshift-backed dashboard, so a mismatch between GA4 transaction count and actual orders surfaces automatically instead of waiting for someone to notice it in a spreadsheet three weeks later. You see the discrepancy the day it happens, not at month-end close.
If you want to see what that kind of GA4 funnel reporting actually looks like in practice, our GA4 solution page walks through it in more detail.
Quick Reference: The 12-Point Checklist
Bookmark this part.
Implement the full event set: view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund
Populate every item array field, including item_category and affiliation, not just item_id and price
Add transaction_id deduplication logic to prevent double-counted purchases
Validate transaction IDs server-side against your order management system
Run a weekly GA4-vs-actual-orders check for a 7-day window
Move purchase and refund events to server-side tagging
Accept the engineering tradeoff on server-side setup for revenue-critical events
Pass currency explicitly on every event, especially for multi-currency stores
Track coupon and discount parameters consistently to avoid misattributed revenue
Keep item_id values identical between GA4 and your Google Ads/Merchant Center feed
Use DebugView to confirm event order and parameters before launch
Export to BigQuery and audit monthly for missing parameters and currency mismatches
Every dashboard, forecast, and ad-spend decision downstream depends on these events being clean. Get the tracking right first, everything else is just reporting on top of it.
If you want more breakdowns like this, sign up for our newsletter or poke around our other guides on ecommerce reporting.
Content author and contributor at Trivas.ai, sharing insights on e-commerce analytics, business intelligence, and data-driven strategies to help businesses grow.
Continue Reading
explore more insights
Advanced Funnel Analysis Methodologies
3 min read
Breakeven ROAS Calculator: Find Your Minimum Profitable Ad Spend
3 min read
Best Tools and Technologies for E-commerce Report Automation
.d53b12e5.png&w=3840&q=75 "Trivas.ai")
