Google's own GA4 documentation names four ecommerce events as "recommended": view_item, add_to_cart, begin_checkout, and purchase. These form the core funnel GA4 uses to report on ecommerce performance, from product views all the way to completed orders. This isn't a third-party naming convention someone made up for consistency. It's straight from Google's GA4 ecommerce measurement spec, and these google analytics recommended ecommerce events, view_item, add_to_cart, begin_checkout, purchase, official as they are, decide whether your funnel reports and Google Ads conversion data actually mean anything.
Get any one of these wrong (wrong trigger timing, missing parameters, duplicate fires) and the damage spreads. Funnel reports show phantom drop-off. Attribution misfires. Google Ads conversion values stop matching your actual revenue. This guide walks through what each event should do, where teams usually break it, and how to check your own setup before you trust a single chart.
Why Google Calls These the "Recommended" Events
GA4 splits events into four buckets: automatically collected (page views, scrolls), enhanced measurement (outbound clicks, site search), recommended (the ecommerce set, plus a few others like sign_up or login), and custom events you define yourself.
Recommended events aren't just a suggestion with no teeth. They get special treatment inside GA4. The Monetization > Ecommerce purchases report, the automatic funnel exploration templates, the checkout behavior reports: all of it is built around these exact event names and parameter structures. Name your event "add_to_basket" instead of "add_to_cart" and GA4 has no idea it's related to ecommerce at all. It just sees a custom event with no revenue context.
There's a practical reason to stick to Google's naming too. The GA4 to Google Ads import pipeline expects these specific event names and parameter shapes. Deviate from them and your Google Ads conversion import either breaks silently or reports numbers that don't match reality. If your GA4 setup feeds into broader reporting, like a GA4 integration pulling funnel data into other dashboards, getting the event names right at the source saves you from reconciling mismatched data downstream.
view_item: Tracking Product Detail Page Views
view_item should fire once, when a user actually lands on or views a single product's detail page. Not a category grid. Not a search results list with twelve products in it. One product, one page, one event.
Required parameters: an items array with item_id, item_name, and price for the product being viewed, plus currency and value at the top level. Miss the items array and GA4 can't tie the view back to a specific SKU, which kills any item-level reporting later.
The gotcha here shows up constantly: teams fire view_item on category or collection pages because it's easier to wire up in Google Tag Manager, or because a quick-view modal from a listing page gets treated the same as a full PDP visit. That inflates funnel entry counts and makes your view-to-cart conversion rate look artificially low, since you're counting views that were never real product page visits in the first place.
add_to_cart: Capturing Cart Additions
This one fires when a user adds an item to their cart, whether that's from the PDP, a quick-add button on a listing page, or a "you might also like" recommendation in the cart itself.
Required parameters mirror view_item but need quantity added too: items array (with quantity), currency, and value matching the line item(s) just added. If someone adds 3 units of a $20 product, value should reflect $60, not $20.
The bug worth watching for: quantity selectors that fire add_to_cart once per unit instead of once per action. Someone bumps the quantity field from 1 to 5 and clicks "add to cart" once, but the tag fires five separate times. Your cart event count balloons, your cart-to-purchase ratio tanks, and nobody can figure out why the funnel looks broken when the store is actually doing fine. Check this specifically on any product page with a stepper or quantity input before trusting your add_to_cart numbers.
begin_checkout: The Most Commonly Misconfigured Event
begin_checkout should fire the moment a user initiates checkout, either by landing on the checkout page or tapping a "checkout" CTA, depending on how your platform structures that flow.
This is the event that breaks most often, and it's rarely subtle. Shopify's hosted checkout, headless storefronts, and custom-built checkout flows all handle this step differently, and a lot of implementations either double-fire begin_checkout on page reloads or miss it entirely on one-page checkout designs. The result is a visible, often large gap between add_to_cart counts and begin_checkout counts that has nothing to do with actual cart abandonment. It's just a tracking hole.
Required parameters: items array, currency, value. If a discount code is already applied by this point, include the coupon parameter too, since that'll matter later when you're trying to explain why net checkout value differs from gross cart value.
purchase: The Conversion Event Everything Else Feeds Into
purchase is the one that matters most, because it's the one tied to revenue reporting and ad platform conversion data. Required parameters: transaction_id, value, currency, an items array, and tax and shipping if you're measuring those separately from product value.
The problem that shows up again and again: purchase fires twice, once client-side on the order confirmation page and again from a server-side webhook (Shopify's order creation webhook is a common culprit). Both fire with the same order, and suddenly GA4 thinks you did double the revenue you actually did. Nobody notices until someone compares GA4 revenue to the Shopify admin and the gap is impossible to explain.
transaction_id is the fix, or at least the mechanism GA4 uses to catch it. GA4 deduplicates purchase events based on transaction_id, so if the same order ID fires from both the client and server side, GA4 should only count it once, but only if that ID is identical and consistent across both sources. If your server-side event generates its own order reference instead of reusing the one from checkout, deduplication fails and you're back to double-counted revenue.
How to Verify These Events Are Firing Correctly
Don't take any of this on faith. GA4's DebugView, paired with the Realtime report, lets you walk through your own site step by step and watch each event fire with its actual parameters attached. Open a product page, add it to cart, start checkout, complete a test order, and confirm all four events show up in the right order with the right values.
After that, check the Monetization > Ecommerce purchases report against your actual order data. Item-level revenue in GA4 should match what you see in your store admin, within a reasonable margin. If it's off by more than a few percent, something upstream is misfiring.
Finally, cross-check raw event counts against platform order data directly, Shopify orders or WooCommerce orders, not just GA4's own totals. This catches the two failure modes that GA4 alone won't flag for you: under-counting (events that never fired, orders GA4 never saw) and over-counting (duplicate fires inflating both event volume and revenue). This single cross-check catches most of the issues described above before they quietly skew a quarter's worth of reporting.
Turning These Events Into a Funnel You Actually Trust
These four events, view_item, add_to_cart, begin_checkout, purchase, give you the full view-to-purchase funnel GA4 was built to report on. But GA4's native reporting stops at descriptive charts. It'll show you that drop-off happened between add_to_cart and begin_checkout. It won't tell you why, or which channel's traffic is responsible.
That's the gap Trivas is built to close. It pulls GA4 funnel events into Redshift-based dashboards alongside ad spend and order data from Shopify and Amazon, so when a drop shows up between add_to_cart and begin_checkout, you can trace it back to a specific campaign or channel instead of guessing. If this kind of unified view across bi-reporting and your funnel data sounds useful, or you want to see how GA4 events map against your paid spend without stitching spreadsheets together manually, it's worth a look. And if you're responsible for reporting these numbers up the chain, our marketing leaders resources go deeper into what good ecommerce reporting actually looks like.
Worth bookmarking this one and coming back to it the next time a funnel report looks off. It usually traces back to one of these four events, not some mysterious tracking failure.
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
15 Important Ecommerce KPIs for Shopify Brands (And How to Actually Track Them)
3 min read
Northbeam Analytics Pricing in 2025: Full Breakdown of Plans, Costs, and Hidden Fees
.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.ai
