.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiYou pull up GA4, check revenue for the month, then check Shopify. The numbers don't match. Sometimes GA4 shows 15% more orders, sometimes 15% fewer. Nobody on the team can say why with confidence, so everyone just picks whichever number supports their point in the meeting.
This happens constantly, and it's not a GA4 bug. Universal Analytics used to infer a lot of ecommerce behavior automatically. GA4 doesn't. Every event, every parameter, every item in the cart has to be explicitly pushed to the data layer or sent through gtag. Miss a parameter and the event either doesn't fire, fires with blank data, or fires twice. Any of those breaks your funnel and your revenue reporting at the same time.
This guide is the ga4 ecommerce events setup guide we wish existed when we started reconciling client accounts: the full list of recommended ecommerce events, two implementation paths (Google Tag Manager and gtag.js directly), and a verification process so you're not trusting a dashboard until you've actually checked its math against real orders.
GA4's recommended ecommerce events map to the actual shopper journey, from browsing to purchase to refund. Here's each one and what it needs to carry:
items array with item_id and item_name at minimum.items, currency, and value.items, currency, value.items, currency, value.shipping_tier parameter.payment_type.transaction_id, value, currency, and items. Without transaction_id, GA4 can't dedupe the event if it fires twice.transaction_id to match back to the original purchase, plus value if it's a partial refund.The items array is required across nearly all of these, and each item object should consistently include item_id, item_name, price, and quantity. Optional parameters like item_category or item_brand add reporting depth but won't break anything if they're missing.
Here's the one that causes the most damage: transaction_id deduplication on the purchase event. If your confirmation page fires purchase on every reload, or if both GTM and a hardcoded script send it, GA4 counts every duplicate as new revenue. We've seen accounts where this alone inflated reported revenue by double digits. It's the first thing to check when numbers don't match Shopify.
GTM is the more common path, especially for teams who want marketing to adjust tracking without filing a dev ticket every time.
The setup: create a GA4 Event tag in GTM for each ecommerce event (purchase, add_to_cart, etc.). In the tag, set the Event Name to match GA4's recommended naming, then map the Event Parameters, specifically ecommerce object fields like items, value, currency, and transaction_id, pulling from the data layer via the built-in {{ecommerce}} variable or custom data layer variables you define.
For this to work, your site needs to push a properly structured dataLayer.push() call before the GTM tag fires. Something like:
Order matters here. The push needs to happen before GTM's trigger fires, not after, or the tag reads an empty object. This is the single most common bug in GTM-based ecommerce setups: a tag firing correctly, but reading stale or missing data because the push landed too late.
Triggering logic depends on your platform. If you're on Shopify, you're working with native checkout events (or theme-level custom events for cart drawers) to fire the right tag at the right funnel step. Custom-built sites typically fire a custom event at each step (add-to-cart click, checkout step load, order confirmation) that GTM listens for. The key discipline: one event, one trigger, one tag, no overlap.
If you're not using GTM, gtag.js calls go directly in your site code. The purchase event looks like this:
Same required fields as the GTM version: transaction_id, value, currency, items. GA4 doesn't care which method delivered the event, only that the structure is right.
Direct gtag implementation makes sense for custom-built storefronts or headless commerce setups where there's no clean data layer to hook into, and where a developer is already touching the checkout code anyway. GTM makes more sense when marketing or growth teams need to iterate on tracking without waiting on engineering.
One real risk here: if a developer hardcodes gtag calls on the confirmation page and GTM also has a purchase tag firing on that same page, you'll double count every order. We see this specifically on sites that migrated to GTM but never removed the original gtag snippet. Check your page source for gtag('event', 'purchase' before assuming GTM is your only source of truth.
Shopify's native GA4 integration (through the Google & YouTube channel app) handles the basics: page views, view_item, and purchase are usually solid out of the box. Add_to_cart is where it falls apart, specifically on themes using AJAX cart drawers.
If your cart updates without a page reload (which is most modern Shopify themes), the native integration often misses the add_to_cart event entirely, because there's no fresh page load to trigger it. The fix is checking your theme.liquid file and any cart drawer JavaScript for a dataLayer.push() tied to the actual "add to cart" button click, not just the page load.
Checkout extensibility is the other constraint. On non-Plus Shopify plans, you can't inject custom scripts into the checkout pages themselves, which means add_shipping_info and add_payment_info often can't fire at all, since those steps live inside Shopify's locked checkout flow. Plus merchants get more flexibility here through checkout UI extensions. If you're not on Plus, expect gaps in the mid-funnel checkout events and plan your funnel reporting around what's actually trackable.
For a deeper walkthrough of connecting Shopify data cleanly, see our Shopify integration resources, and if you're evaluating GA4 alongside your Shopify stack specifically, the GA4 solutions overview covers how the two should work together. If you want Shopify order and GA4 event data sitting in one place without maintaining this reconciliation manually, Trivas AI on the Shopify App Store is built for exactly that gap.
Don't build a single dashboard on top of this until you've verified it. GA4's DebugView and GTM's Preview mode are both free and both non-negotiable.
Turn on GTM Preview mode, browse your own site, and watch each event fire in the Tag Assistant panel. Confirm the order is right: view_item before add_to_cart, add_to_cart before begin_checkout, and so on. If an event fires out of order or not at all, you've found your bug before it hits production data.
GA4 DebugView shows the same events landing in your GA4 property in real time, parameter by parameter. This is where you catch the transaction_id duplication problem directly: place a test order, watch DebugView, and confirm the purchase event fires exactly once with the correct transaction_id. If you see it twice, you've got a double-firing tag or a confirmation page that re-triggers on refresh.
Once that's clean, do one more check before trusting anything long-term: pick a single day, pull GA4's purchase count and revenue, and compare it line by line against Shopify's order export for that same day. They won't be identical to the penny (GA4 misses some orders due to ad blockers and cookie consent), but they should be close, within a few percent. If they're off by 20%+, something in the setup is still broken.
A few patterns show up again and again in accounts we've audited:
Missing currency parameter. If currency isn't passed on an event, GA4 defaults to your property's base currency setting. For a US-based property accidentally receiving GBP values with no currency tag, every transaction gets reported as if it were in dollars, which quietly misstates revenue without throwing any errors.
Inconsistent item_id or item_name values. If the same product shows up under two different IDs (one from your CMS, one from a legacy SKU format), GA4 and any BI tool built on top of it will report it as two separate products. Product-level reporting falls apart, and so does any attribution work layered on top.
Begin_checkout firing multiple times per session. Common on single-page checkout flows where the event is tied to a page load rather than an actual checkout initiation click. The result: funnel reports show far more checkout starts than real sessions, which makes your checkout abandonment rate look worse than it is.
None of these throw error messages. They just quietly skew the numbers until someone notices the totals don't add up.
A correct GA4 setup isn't the end goal, it's the foundation everything else sits on. Funnel analysis, channel attribution, product-level reporting: none of it means anything if the underlying events are wrong.
Once you've verified events are firing clean, the next problem is usually combining that GA4 data with Shopify, Amazon, and ad platform numbers without manually cross-referencing spreadsheets every week. That's the layer Trivas is built for: pulling verified GA4 ecommerce events alongside Shopify, Amazon, and ad platform data into one Redshift-backed reporting layer, so you're looking at one number instead of reconciling five sources by hand. If that's the stage you're at, our BI reporting product and data integration resources walk through how that connection works.
If you're still mid-setup, bookmark this guide and come back to the verification section before you plug GA4 into anything else. And if you want more breakdowns like this as we publish them, our resource hub is a good place to keep an eye on.
explore more insights
3 min read
3 min read
3 min read