Google Analytics Ecommerce Recommended Events: view_item, add_to_cart, begin_checkout, purchase (Official)
GA4's official ecommerce recommended events, per Google's own measurement documentation, are four: , , , and . Together they form the core funnel from "someone looked at a product" to "someone paid for it." If you've landed here searching for the google analytics ecommerce recommended events view_item add_to_cart begin_checkout purchase official list, that's it. That's the whole list for the funnel backbone.
view_item
add_to_cart
begin_checkout
purchase
These four sit inside GA4's broader recommended events schema, which is Google's way of standardizing event names and parameters so the platform's built-in reports actually work. That's different from a custom event you name yourself. Recommended events follow Google's exact spec, which means GA4's default ecommerce reports and funnel exploration templates read them correctly without any extra configuration.
Worth noting: the full ecommerce event list also includes things like add_to_wishlist, view_item_list, add_shipping_info, and add_payment_info. Those matter for a fuller picture of shopping behavior. But the four in the title are the ones that define the actual purchase funnel, and they're the ones most teams get wrong first.
Why these four events specifically
Here's the thing about GA4: it didn't build its ecommerce purchases report, or the funnel exploration templates, to work with whatever event names you feel like sending. It built them around specific, predefined names. Use view_item and GA4 knows what to do with it. Use something custom like product_viewed and you're on your own.
That's the real gap most Shopify and WooCommerce setups fall into. A store sends addToCart (camelCase, no underscore) instead of add_to_cart, and suddenly none of it shows up where it should. GA4 doesn't try to guess your intent. It matches on exact string names and exact parameter structures. Miss the spec, lose the report.
Map these four events to a classic funnel and they line up cleanly: view_item is product interest, add_to_cart is cart intent, begin_checkout is checkout intent, and purchase is the conversion. It's not a coincidence Google chose these four. They're the stages every ecommerce business already tracks mentally, just formalized into a schema the platform can actually report on.
view_item: required parameters and when it fires
view_item should fire on page load of the product detail page, full stop. Not on hover, not on a list thumbnail, not inside a quick-view modal if that modal isn't a true PDP. Hover and list-level views are what view_item_list is for, and conflating the two is one of the more common tracking mistakes we see in GA4 audits.
The required structure is an items array (even for a single product) containing:
item_id
item_name
price
currency
Leave out currency and your revenue numbers downstream get murky fast, especially for stores selling in multiple markets. Most implementations fire this through a Google tag via a GTM trigger set on PDP load, or through native ecommerce events if you're on Shopify with GA4's built-in integration. Either path works. What matters is firing once, at the right moment, with a correctly formed items array.
add_to_cart, begin_checkout, and purchase: parameters and firing rules
add_to_cart fires on the actual add-to-cart click, not on page load, not on checkout. It needs the same items array as view_item, plus quantity and value. Skip value and you lose the ability to see cart-value trends separate from raw click counts, which matters more than people expect once you're trying to diagnose a cart abandonment problem.
begin_checkout fires the moment the checkout flow starts. Include coupon if a discount code is already applied at that point. This is, honestly, the event most often double-fired in misconfigured setups. We see it happen when a tag is set to trigger on a checkout page view and the page re-renders client-side (common with SPA checkout flows), so the same session logs begin_checkout three or four times for one actual checkout attempt. That inflates your checkout-intent numbers and quietly wrecks your begin_checkout to purchase conversion rate.
purchase fires once per completed transaction and requires transaction_id. That ID is what GA4 uses to dedupe, so if it's missing or inconsistent, you'll see inflated revenue. Include tax and shipping as separate parameters too, otherwise your revenue figure in GA4 won't match what's actually hitting your bank account, and that discrepancy is the kind of thing that erodes trust in the whole dashboard once a finance person notices it.
The single biggest implementation mistake we see: firing purchase on every page load of the thank-you page instead of gating it by transaction_id. A customer refreshes the confirmation page, or hits back and forward in their browser, and GA4 logs a second purchase with the same order. Gate the tag so it only fires once per unique transaction_id, and this problem disappears.
How to verify these events are firing correctly
Don't trust that your tags work just because they look right in GTM preview mode. Open GA4's DebugView and watch each event fire live: confirm it fires once, in the correct funnel order, carrying the item-level parameters you expect. If view_item is missing price, you'll see it immediately in DebugView rather than three weeks later when someone asks why average order value looks wrong.
Next, check the Monetization > Ecommerce purchases standard report and compare total revenue against known order totals from your actual order management system. If GA4 shows meaningfully more or less revenue than your real numbers, something in the event chain is off.
Common gaps worth checking specifically:
Missing currency parameter (GA4 will still record the event but revenue reporting gets inconsistent across currencies)
items sent as a single object instead of an array (GA4's schema expects an array even for one item, and a malformed structure can silently drop the event from reports)
Duplicate purchase events firing from both a client-side tag and a server-side tag pointed at the same conversion
That last one is sneaky because each individual event looks valid in DebugView. It's only when you add up total transaction counts against your real order count that the duplication shows up.
Where this GA4 data actually becomes useful for ecommerce teams
Getting these four events to fire correctly is step one. It's necessary, but it's not where the actual decision-making happens. The real value is seeing the view_item to purchase funnel sitting next to ad spend and blended ROAS, not isolated inside GA4's own interface where it's disconnected from what you're actually spending to drive that traffic.
GA4's UI also has real limits for this kind of analysis. It samples data once you're querying larger date ranges or more complex segments, and lookback windows for things like audience building are capped. That's fine for a quick check. It's not fine if you're trying to run unsampled, multi-month funnel analysis next to Shopify and Meta or Google Ads spend. That's the actual reason teams end up piping GA4 ecommerce events into a warehouse: so the view_item-to-purchase funnel can sit alongside the rest of the business data without sampling getting in the way.
If you're a marketing leader trying to report blended funnel performance up the chain, this distinction matters more than the GA4 setup itself. The setup is the easy part.
Next steps: getting GA4 ecommerce data into your reporting stack
Once these four events are confirmed and firing cleanly, the next question is what you do with them. GA4 on its own won't tell you how view_item volume correlates with Meta ad spend that week, or whether your begin_checkout drop-off tracks against a shipping cost change. That requires connecting GA4 to something built to blend those sources.
Trivas's GA4 integration pulls these four events, along with the rest of the ecommerce schema, into unified dashboards that sit next to Shopify orders and ad platform spend, so the funnel isn't stranded in its own silo. And if you want to confirm exactly how each parameter maps to a reporting metric before you start building anything, the data dictionary lays that out in plain terms.
If you're just getting your GA4 tracking sorted and want to keep learning about how these pieces fit into a broader dashboard setup, it's worth poking around our other resources on dashboards and analytics or subscribing for more of this kind of breakdown as we publish it.
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
How to Evaluate Polar on Actionable Customer Analytics
3 min read
Content Pruning Decision: Implementation Strategies for AI Ecommerce Insights
3 min read
Marketing Attribution Software for Ecommerce: What It Actually Does
.d53b12e5.png&w=3840&q=75 "Trivas.ai")
