GA4 Ecommerce Tracking: What to Check Before You Trust a Report

GA4 ecommerce tracking is the set of events your store sends to Google Analytics 4 describing what a shopper did — viewed a product, added it to a cart, started checkout, bought something — each one carrying the products involved and what they cost, so that Analytics can report revenue rather than only pageviews.

That definition is the easy part, and every page ranking for this query gets it right. I read the three above this one before writing: Google’s own developer documentation, a well‑known tag management guide, and a long tutorial from an analytics vendor. All three are competent and all three do the same thing. They teach you how to send the data. Not one of them tells you how to find out whether what arrived is true.

That is the gap, and it is the only part that matters to someone running a store. Sending the data is a job you do once. Deciding whether to believe the report is a job you do every time you open it, and a wrong number there does not produce a mildly wrong decision. It produces a confident one in the wrong direction.

What is GA4 ecommerce tracking?

It is the structured record of a shopping session, sent from your site to Analytics as a series of named events. Google’s Measure ecommerce documentation lists fourteen of them, from view_item_list and view_item through add_to_cart, begin_checkout and add_payment_info, ending at purchase and refund.

Each event carries an items array — the products involved, with their IDs, names and prices. The same documentation sets the limits: an items array can hold up to 200 elements and up to 27 custom parameters beyond the prescribed ones, and currency must be set at the event level whenever you send a value. That last requirement is the one that quietly breaks reports. Send revenue without a currency and Analytics has a number it cannot interpret.

The events GA4 expects, and the three that decide everything

Three events carry almost all of the decision weight: purchase, begin_checkout and add_to_cart. Get those three right and the reports you actually use will work. The other eleven add resolution to the funnel, and they are worth having, but nobody has ever made a budget decision on select_promotion.

The reason to be precise about this is that implementation effort gets spent evenly across all fourteen when it should be spent almost entirely on one. purchase is the event that feeds revenue, that Smart Bidding learns from if you import it, and that every return figure in your reporting is ultimately built on. It deserves more scrutiny than the other thirteen combined.

Why doesn’t GA4 revenue match my Shopify orders?

They never match exactly, and expecting them to is the most common reason store owners stop trusting Analytics entirely. A small gap is normal and has understandable causes. A large gap is a defect, and the useful skill is knowing which one you are looking at.

The seven checks to run before you trust a report

Run these against a single day that has already closed, before you use any GA4 number in a decision. It takes about twenty minutes and it is the difference between reporting and guessing.

1. Compare one day’s revenue to the store backend. Pick a closed day, put the two totals side by side and write down the percentage gap. You now have a baseline, and every future check is against that rather than against a hope.
2. Compare order counts, not just revenue. Matching revenue with mismatched order counts means two errors are cancelling out, which is worse than one error.
3. Check whether purchase fires twice. Complete a test order, then reload the confirmation page and press back. If a second purchase appears, every return figure you have is overstated.
4. Test every payment path. Card, Shop Pay, PayPal, Apple Pay, Google Pay. Express wallets skip steps in the checkout flow and are the most common place a purchase event silently goes missing.
5. Confirm the transaction ID is unique per order. It is what Analytics uses to deduplicate. A repeated or missing ID is how duplicates get through.
6. Check what is inside the revenue figure. Tax and shipping in or out. Then write the answer down somewhere the next person will find it.
7. Confirm currency is on the purchase event. Required whenever you send a value, per Google’s documentation, and easy to miss on a store that added a second currency after launch.

How do I know if it’s set up right?

Use DebugView, which shows events arriving in real time while you walk through your own store. Google’s DebugView documentation describes a stream of events from the last 60 seconds and an archive of the previous 30 minutes, which is enough to complete a test purchase and watch every event land.

Enable it with Google Tag Assistant or Tag Manager’s preview mode for your own device, or by setting debug_mode to true in the configuration for everyone. One detail from that page is worth carrying around: to turn debug mode off you have to remove the parameter entirely, because setting it to false does not disable it. Stores have shipped to production with debug traffic still flowing because of exactly that.

What to watch for while you click through: every event appearing once rather than twice, the items array populated rather than empty, and the value on the purchase event matching the order total on screen. Those three observations catch most of what goes wrong.

What happens when someone asks for a refund?

You send a refund event, and almost nobody does. It is documented alongside the other thirteen in Google’s ecommerce reference, and in practice it is the most commonly skipped part of an otherwise complete implementation.

The consequence is specific rather than cosmetic. If refunds never reach Analytics, your reported revenue is gross and your real revenue is net, and the difference is invisible precisely where it matters most — the product categories and acquisition channels with the highest return rates look better than the ones with low return rates, when the truth may be the reverse. If your business has a meaningful return rate and no refund event, your channel comparison is wrong in a direction you cannot see. It is also why what a customer can cost you has to be worked out from contribution margin rather than from a revenue figure in a dashboard.

Why is some of my data missing?

Usually thresholding, which is Analytics withholding data to protect individual privacy rather than anything broken on your site. Google’s documentation on data thresholds explains that it applies when a report includes demographic signals or search query information and the underlying user counts are too low, and that the thresholds are system‑defined and cannot be adjusted.

Two things help. Widen the date range, which raises the user count and often clears it. Or export to BigQuery, where demographic data arrives unthresholded. Neither is a fix, because there is nothing to fix. The useful move is recognising thresholding on sight, so you do not spend a week debugging a tag that is working correctly.

Why doesn’t channel revenue add up to total revenue?

Because total revenue is counted once and channel revenue is allocated by an attribution model, and those are two different operations. Google’s attribution documentation describes the models available — data‑driven, paid and organic last click, and Google paid channels last click — along with a configurable key event lookback window.

The practical consequence is that a single order can be credited differently depending on which report you are in and which model is applied, so two reports in the same property can disagree while both are correct. Before comparing channels, check which model the report is using and keep it the same across every comparison you make. Changing the model between two reports and reading the difference as a performance change is a mistake I have watched cost real budget.

Over 24 months on The Lifeguard Store’s account I have managed $159,235 at a 17.5x blended return, and that figure is only worth publishing because the purchase data underneath it was reconciled against the store before anybody quoted it — the account is written up here. A return figure is a claim about revenue. If the revenue was never checked, the figure is a claim about a dashboard.

What to do first

1. Run check one today. One closed day, GA4 revenue against the store backend, and write the gap down. Everything else follows from knowing that number.
2. If GA4 is higher than the store, stop and fix it before anything else. Overstated revenue is the expensive failure, because it makes unprofitable spending look like it is working.
3. Test the express checkout paths. Shop Pay, PayPal and the mobile wallets, one test order each, watched in DebugView.
4. Add the refund event if you take returns. Not urgent on the day, and it quietly distorts every channel comparison until it exists.
5. Write down what your revenue figure includes. Tax and shipping, in or out. Then stop rediscovering it every quarter.

None of this is analytics work for its own sake. It is the precondition for every decision made downstream of it, which is why it comes before campaign structure in how I run Google Ads for ecommerce brands and why restructuring an account is the most visible work and rarely the most valuable.

Questions people ask