.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiGoogle's official GA4 ecommerce events are view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund, view_item_list, select_item, view_cart, and remove_from_cart. These are documented in Google's Measure Ecommerce guide, and they're the exact event names GA4 and Google Ads reporting look for, not stand-ins you name yourself.
That last part trips people up constantly. You can build a perfectly good custom event called cart_add that fires every time someone adds a product, and GA4 will log it fine. It just won't show up in any of the standard ecommerce reports, because those reports are keyed to specific reserved names. This article covers the full official list, the parameters each event needs, and the mistakes that quietly break reporting even when the events technically fire.
Google organizes these around the shopping funnel, and they're meant to be used together, not cherry-picked.
view_item_list and select_item cover the browsing stage. The first fires when a shopper sees a list of products, say a category page or search results. The second fires when they click one of those products. Together they tell you which placements actually drive clicks.
view_item fires on the product detail page itself. This is your top-of-funnel product interest signal.
add_to_cart and remove_from_cart fire on cart actions. Both carry an items array with price and quantity, which is what lets you calculate cart abandonment by product rather than just by session.
view_cart fires when someone opens their cart. Simple, but it's the event most people forget to wire up, and without it you can't tell the difference between "added to cart and left" and "added to cart, viewed cart, then left."
begin_checkout, add_shipping_info, and add_payment_info are the three checkout stages Google recommends tracking as separate events, not one blob. The reasoning is straightforward: if you only track "checkout started" and "purchase complete," you have no idea where in that process people bail. Split it into three and you can see if it's the shipping form or the payment form killing conversions.
purchase is the conversion event. It requires transaction_id, value, currency, and an items array. Miss any of those and your revenue numbers get shaky fast.
refund mirrors the purchase event's structure and exists to subtract reversed revenue from your totals. A lot of implementations skip it entirely, which means refunded orders keep counting as revenue forever in GA4's reports.
Not every parameter carries the same weight, and GA4 doesn't always tell you when you've missed one.
On the purchase event, transaction_id and value are genuinely required. Without them, GA4 can still log the event but it won't attribute revenue correctly, and deduplication (which uses transaction_id) breaks. currency is technically recommended rather than required, but treat it as required anyway, because of the issue below.
Then there's a second tier of recommended parameters: coupon, affiliation, shipping, tax. These don't break anything if they're missing, but you lose the ability to segment by promo code or separate product revenue from tax and shipping in your reports.
The items[] array is where most of the actual reporting value lives. Each item object should include item_id, item_name, price, quantity, and item_category. These four or five fields are what nearly every ecommerce report in GA4 pivots on, product performance, category breakdowns, revenue by SKU. If you're only passing a flat transaction total with no item array, you've got a revenue number and basically no detail behind it.
Here's the one that catches teams off guard: missing currency on the purchase event doesn't throw an error. GA4 will accept the event, show it in real-time reports, and silently miscalculate revenue in any view that assumes a default currency different from what the transaction actually used. If you sell in multiple currencies and skip this field, your blended revenue totals can be wrong for months before anyone notices.
There are really three paths here, and which one fits depends on how much engineering time you have.
Google Tag Manager with a data layer push is the most common route. You push an ecommerce object to the data layer at each funnel step (view_item, add_to_cart, and so on), then GTM reads that object and fires the GA4 event. This keeps event logic out of your codebase and lets marketing update triggers without a dev deploy.
Hardcoding gtag('event', ...) calls directly in your site code is the alternative. It's more rigid, since any change needs a code release, but it's also more predictable, because there's no intermediate data layer to misconfigure.
Platform plugins are the third option, and for most Shopify stores this is the realistic default. Shopify, through its own analytics integrations or apps, can expose ecommerce events without you touching a data layer manually. If you're running on Shopify, check our Shopify integration guide before you build anything from scratch, since a lot of this groundwork is already handled.
One thing that matters regardless of which path you pick: event order. GA4's funnel reports assume view_item happens before add_to_cart, which happens before begin_checkout. If your implementation fires these out of sequence, say add_to_cart fires without a preceding view_item because of how a quick-add button is wired, your funnel visualization will show drop-off numbers that don't reflect reality. Test the actual click path, not just whether each event fires in isolation.
Most GA4 ecommerce problems aren't exotic. They're one of these four.
Using custom event names instead of the reserved ones. cart_added instead of add_to_cart. GA4 logs it as a custom event, and it never enters the standard ecommerce reports no matter how well-formed the payload is.
Double-firing purchase on page refresh. If your order confirmation page fires the purchase event on every page load rather than once per transaction_id, a customer who refreshes the confirmation page adds a second "purchase" to your reports. This is one of the most common causes of revenue figures in GA4 running hotter than what Shopify or Stripe actually processed.
Mismatched currency codes across markets. If your US store fires USD and your EU store fires EUR but one of them is misconfigured and sends the wrong code, GA4 blends the totals as if they were the same currency. Numbers look fine at a glance and are wrong underneath.
Not passing item-level data. A purchase event with just a transaction_id and value, no items array, gives you a revenue total and nothing else. No product breakdown, no category performance, nothing to act on.
GA4 events are the raw signal. They tell you what happened on your site and in what order. What they don't do is reconcile automatically against what Shopify or Amazon actually recorded as an order, or against what you spent on the ad that drove the click. That reconciliation is where most teams get stuck, usually manually, in a spreadsheet, once a week.
Trivas pulls GA4 ecommerce event data into Redshift-backed dashboards alongside Shopify, Amazon, and ad platform data, so funnel drop-off from view_item through purchase sits next to actual order data and true ROAS in one view instead of three browser tabs. If you want to see how each GA4 metric maps into that kind of reporting, the data dictionary is a useful reference point before you start building dashboards.
The official list is the starting point, not the finish line. The real work is making sure every one of these events fires in the right order, carries the right parameters, and doesn't quietly double-count or drop currency data. Get that right and GA4 becomes a genuinely usable funnel view. Get it wrong and you've got a dashboard full of numbers nobody trusts.
If you'd rather see your GA4 funnel sitting next to your Shopify and Amazon order data without exporting CSVs every Monday, start a trial and connect your accounts.
explore more insights
3 min read
3 min read
3 min read