Google Analytics 4 Ecommerce Events: The Official List and How to Use It
by Trivas.ai
|
8 min read
Oct 08, 2026
Google's official GA4 ecommerce events are view_item, view_item_list, select_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, and refund. These come straight from Google's Measurement Protocol and recommended events documentation, not from some agency's interpretation of best practice. If your GA4 property isn't using this exact list with the exact parameters Google specifies, your ecommerce reports are quietly broken, even if events are technically firing.
That distinction matters more than it sounds. "Official" here isn't a branding choice, it's the schema GA4's standard reports are hardcoded to expect. This post walks through what each event tracks, which parameters actually matter, and how to confirm your setup is sending what GA4 thinks it's receiving.
What Makes an Event "Official" in GA4
Google ships GA4 with a set of recommended ecommerce events. These have fixed names (snake_case, exact spelling) and a defined parameter structure. You can invent your own custom events too, GA4 doesn't stop you. But custom events don't automatically populate the Monetization reports, the purchase funnel, or the ecommerce exploration templates. Those are built to read purchase, not order_completed or checkout_finished.
This is the part that trips up a lot of in-house dev teams: they build an ecommerce tracking plan that makes sense internally, name events however their product team talks about the funnel, and then wonder why GA4's own reports show zeros or partial data. The reports aren't broken. They're just not being fed the events they're looking for.
Stick to Google's exact event names and parameter structure, and GA4's standard reports, funnel exploration, and Google Merchant Center integrations all populate the way they're supposed to. Deviate, and you're stuck building custom explorations to reconstruct basic reports Google already gives you for free.
The good news: if you're running Shopify with Google Tag Manager, you're probably already 80% of the way there. Shopify's data layer and most GTM ecommerce templates push variables that map directly onto these events, you just need to confirm the mapping is exact rather than close enough.
The Full List of Official GA4 Ecommerce Events by Funnel Stage
Here's the full list, grouped by where they sit in the customer journey.
Discovery stage
view_item_list: fires when a shopper sees a product listing, like a category page or search results grid.
select_item: fires when they click a specific product from that list.
Consideration stage
view_item: fires on the product detail page.
add_to_cart: fires when a product gets added to cart.
remove_from_cart: fires when a product gets removed.
view_cart: fires when the cart page or cart drawer is opened.
Checkout stage
begin_checkout: fires when checkout starts.
add_shipping_info: fires once shipping details are entered.
add_payment_info: fires once payment details are entered.
Conversion stage
purchase: fires on the order confirmation page, once per completed order.
refund: fires when an order (or part of one) is refunded.
Most of these map to an obvious moment in the UI, which is exactly why they're easy to mess up. view_item_list should fire once per page load of a listing page, not once per product tile. add_to_cart should fire on the actual add action, not on page load of the cart. Get the trigger timing wrong and the event still "works" in the sense that it shows up in GA4, it just doesn't mean what the report assumes it means.
Required Parameters: Why Events Fire But Reports Still Look Wrong
This is where most GA4 ecommerce setups quietly fall apart. The event name firing correctly is only half the job, the parameters attached to it are what make the data usable.
Every product-related event needs an items array, and each item inside it needs at minimum an item_id and item_name. Miss one of those on, say, add_to_cart, and the event still counts toward your add-to-cart total, but it won't show up correctly in any product-level breakdown. You'll have a number with no name attached to it, which is useless when you're trying to figure out which SKU is driving cart adds.
currency and value matter just as much, especially on purchase and add_to_cart. Leave currency off a purchase event and GA4 can silently drop that revenue from certain reports instead of defaulting to your property's base currency. It doesn't throw an error. It just understates revenue, and nobody notices until the monthly numbers don't reconcile with Shopify.
transaction_id on purchase deserves its own callout. This is the field GA4 uses to deduplicate orders. If it's missing, or if the same order sends two different transaction IDs across two fires, you get either undercounted or double-counted revenue, and it's one of the more common reasons GA4 revenue and Shopify revenue diverge by a specific, suspicious percentage.
coupon and affiliation parameters are optional, but worth setting up if you run promo codes or influencer-specific discounts. For DTC brands leaning on discount-driven acquisition, that's the parameter that tells you whether a coupon actually drove incremental purchases or just discounted orders that would've happened anyway.
If you want a clean reference for what each of these fields is supposed to represent at the metric level, the data dictionary is a good place to cross-check definitions before you assume a report is wrong.
Common Implementation Mistakes That Skew GA4 Ecommerce Data
A few mistakes show up over and over, regardless of platform.
Firing add_to_cart on every page load of the cart page, instead of on the click event that actually adds the item. This inflates your add-to-cart count and makes your cart-to-purchase conversion rate look artificially low, because the denominator is wrong.
Firing purchase more than once on the order confirmation page. Refreshing that page, or a slow page load that re-triggers the tag, sends a second purchase event with the same (or sometimes different) transaction ID. Either way, revenue gets double-counted, and it's one of the most common reasons GA4 revenue runs hotter than what actually hit the bank account.
Using custom event names instead of the exact snake_case names Google specifies. Purchase, order_complete, checkoutStarted, none of these populate GA4's standard ecommerce reports. The event shows up in the raw event list, but every pre-built report stays empty.
Missing the items array entirely on begin_checkout. This one's sneaky because the funnel step still counts, you still see how many people started checkout. What you lose is the ability to tell which product was in the cart when they bailed, which defeats the entire point of a checkout funnel report. You end up with a drop-off number and no way to diagnose it.
How to Verify Your Events Are Firing Correctly
Don't trust a tag manager preview mode alone. Walk through GA4's DebugView and watch events fire in real time as you click through an actual test purchase, product page to cart to checkout to confirmation. DebugView shows you the exact parameters attached to each event, which is the only reliable way to catch a missing item_id or a blank currency field before it quietly skews a week of data.
GA4's Realtime report is your fast sanity check. Any time you ship a tag change or touch the data layer, open Realtime and fire a test event. If it doesn't show up within a minute, something's broken upstream, and you want to know that in five minutes, not in next week's reporting cycle.
Then do the boring but necessary step: cross-check your purchase event count against actual order volume in Shopify (or whatever your store backend is) over the same time window. If GA4 shows more purchases than Shopify has orders, you've got a duplicate-fire problem. If it shows fewer, you're likely losing events to ad blockers, consent banners, or a tag that's not firing on certain checkout paths. Either way, this comparison is the single fastest way to catch a broken implementation before it bleeds into a month of reporting. For teams managing this across multiple dashboards, it's worth checking how your dashboard and analytics setup is pulling this data in, since a lot of drift happens quietly at the integration layer, not the GA4 event layer itself.
Why Official Events Aren't the Whole Picture
Here's the thing nobody mentions when they hand you the official event list: getting it perfectly implemented still only tells you what happened on your site. It doesn't tell you what that behavior cost you, or which ad dollar caused it.
GA4 has its own attribution model, and it's a reasonable one for understanding on-site behavior. But it wasn't built to blend cleanly with Meta's reported conversions, Google Ads' click data, and TikTok's pixel events into one number you can actually act on. Each platform reports its own version of the truth, and GA4's version is just one more voice in that argument, not a referee.
That gap is exactly what breaks for growing DTC brands: the GA4 events are correct, the ad platforms are correct in their own silos, and nobody's revenue number matches anyone else's without a few hours of manual spreadsheet stitching every week.
This is the piece Trivas's GA4 integration is built around: pulling GA4 ecommerce events into the same Redshift-backed pipeline as Meta, Google Ads, TikTok, and your store data, so purchase events sit next to spend and margin instead of living in their own isolated report. Once that's unified, the question stops being "did the event fire correctly" and starts being "which campaign actually drove this revenue, at what cost."
Get Your GA4 Ecommerce Events Working for You, Not Against You
Correct event implementation is the floor, not the ceiling. It's necessary, but a perfectly clean GA4 setup still won't tell you whether your Meta spend last week was profitable once you factor in COGS and shipping.
If you've already got your official events firing cleanly and you're wondering what to do with that data next, it's worth seeing how that funnel data looks sitting next to ad spend and margin instead of on its own. Take a look at how the reporting comes together on the BI reporting product page, or subscribe to keep learning how the rest of the GA4 to ad spend pipeline fits together before you lock in a tool decision.
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
Tools for Automating Ecommerce Reporting and Insights
3 min read
Ecommerce Analytics: The Complete Guide to Metrics, Tools, and Strategy
3 min read
What Is AppLovin and How It Affects Ecommerce Advertising
.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.ai
