Google Analytics Ecommerce Recommended Events: purchase, add_to_cart, begin_checkout (Official Reference)
by Trivas.ai
|
7 min read
Oct 09, 2026
Google Analytics Ecommerce Recommended Events: purchase, add_to_cart, begin_checkout
GA4's official recommended ecommerce events include purchase, add_to_cart, and begin_checkout, and each one needs an items array plus its own set of parameters like value, currency, and transaction_id. Get these wrong and your funnel reports quietly go blank or start lying to you. This isn't a third-party best practice list, either: these are the exact events defined in Google's own GA4 Measurement Protocol and gtag.js documentation.
This post breaks down the parameters for each event, where they belong in the customer journey, and the specific mistakes that break ecommerce reporting even when the events technically "fire." If you've ever stared at an empty Purchases report wondering why GA4 isn't counting revenue it clearly received, the answer is usually in here.
What 'recommended events' means in GA4 (and why it matters for reporting)
GA4 splits events into three buckets. Automatically collected events (page_view, session_start) need zero setup. Recommended events, purchase and add_to_cart among them, are events Google has pre-named and pre-parameterized so its standard reports know what to do with them. Custom events are anything you invent yourself, with whatever naming you want.
The catch: recommended events only unlock GA4's pre-built reports, like the ecommerce purchases report or Funnel Exploration, if you use Google's exact event names and parameter names. Name your event "Purchase" with a capital P, or pass "cost" instead of "value," and GA4 won't throw an error. It'll just fail to map the data into those reports. The event shows up in DebugView looking fine. The revenue report shows zero.
This is the part most GTM setups get wrong: everyone assumes "the tag fired, so it worked." Firing isn't the same as being read correctly downstream. If you're auditing your own setup, Trivas's GA4 integration guide covers the exact naming conventions GA4 expects, which is worth a look before you assume your tracking is broken at a deeper level than it actually is.
The purchase event: required parameters and example payload
The purchase event is the one finance actually cares about, so it's the one worth getting exactly right. Required parameters:
transaction_id: a unique order ID
value: total transaction revenue
currency: ISO 4217 code (USD, EUR, etc.)
items: array of objects, each with at minimum item_id, item_name, price, and quantity
Beyond the required fields, a few optional parameters are worth adding because they feed directly into margin and promo reporting: tax, shipping, coupon, and affiliation. Skip these and your "value" field is really just gross revenue with no context.
Here's the deduplication problem nobody warns you about: if you fire purchase both client-side on the thank-you page load and server-side via a webhook (common with Shopify apps and payment processors), you'll double-count revenue. The fix is picking one source of truth per order, usually keyed off transaction_id, and deduping on that ID before it hits GA4.
A minimal gtag.js example:
[@portabletext/react] Unknown block type "code", specify a component for it in the `components.types` prop
Simple on paper. In practice, this is where most "GA4 revenue doesn't match Shopify" tickets start.
The add_to_cart event: parameters and placement in the funnel
The parameter list here is shorter: currency, value, and the items array (same shape as purchase: item_id, item_name, price, quantity).
Placement matters more than people think. This event should fire on the actual add-to-cart confirmation, meaning the click succeeded and the cart state actually changed, not on page load of a product detail page. Firing it too early inflates your add-to-cart count and makes your view-to-cart conversion rate look worse than it is, since you're counting visits instead of intent.
Variant handling trips up a lot of implementations too. If a shopper bumps the quantity of an item already in their cart, that's a quantity update, not a new add_to_cart event. But if they select a different size or color, that's genuinely a different item and should fire as its own event with item_variant populated correctly. Leave item_variant blank or inconsistent and GA4 merges distinct SKUs into one undifferentiated line in your item reports, which makes variant-level performance impossible to read.
The begin_checkout event: parameters and why it's often misconfigured
Parameters: currency, value, the items array, and optionally coupon if a discount code was already applied at checkout entry.
The most common mistake here is firing begin_checkout on cart page view instead of the moment checkout actually starts, usually a "Proceed to Checkout" button click. Conflate the two and your checkout-start count balloons, because now you're counting everyone who glanced at their cart, not just people who committed to buying.
This matters beyond vanity metrics. begin_checkout is the connective tissue in GA4's Funnel Exploration report, sitting between add_to_cart and purchase. If it's measuring the wrong moment, your entire mid-funnel drop-off analysis is built on a bad baseline, and any "fix" you make based on that data is aimed at the wrong leak.
Other recommended ecommerce events worth tracking alongside these three
Purchase, add_to_cart, and begin_checkout get the most attention because they're the ones Google highlights first. But GA4 defines several other recommended ecommerce events that fill in the gaps: view_item, view_item_list, select_item, view_cart, add_shipping_info, and add_payment_info.
None of these are required. But skipping them means you lose visibility into where people actually fall off between browsing and buying. Without view_item_list and select_item, you can't tell if a collection page is doing its job. Without add_shipping_info and add_payment_info, you can't tell if checkout is failing at the form stage specifically, versus earlier.
The three core events give you start and end points. These fill in everything between them, which is usually where the actual optimization opportunities live.
Common implementation mistakes that break GA4 ecommerce data
A few patterns show up constantly in GA4 ecommerce audits:
Missing or malformed items array. This is the single most frequent cause of a blank or partial ecommerce report. Miss a required field inside one item object and GA4 may drop the whole event's item data, even if value and currency look fine.
Mismatched currency codes. Multi-currency stores that pass inconsistent currency values across events (USD on one page, EUR on another, no conversion applied) end up with revenue totals that don't mean anything without manual correction.
Duplicate events from stacked tracking. Platforms like Shopify increasingly ship native GA4 integrations. Add a manual GTM tag on top without checking first, and you're firing purchase twice per order. Nobody notices until revenue looks suspiciously high.
Test transaction_ids leaking into production. Staging environments or QA checkouts that share a GA4 property with live traffic will pollute your purchase data with fake orders, usually with suspiciously round values like $1.00.
Most of these are findable with a quarter hour in GA4's DebugView and a real test purchase. Few teams actually do that check regularly.
Turning GA4 event data into usable reporting
Getting these events firing correctly is step one, not the finish line. Even a flawless GA4 setup still leaves you inside GA4's native UI, which means manually exporting and joining that funnel data against ad spend and order data anywhere you want a real ROAS number by channel or campaign.
That manual join is the actual bottleneck for most teams, not the tracking itself. Trivas's BI reporting pulls GA4 funnel events (purchase, add_to_cart, begin_checkout, and the rest) into Redshift alongside ad platform and order data, so the funnel sits next to spend and revenue in one dashboard instead of three browser tabs. For marketing leads who'd rather not run a GTM audit every quarter just to trust their numbers, that's usually the faster path. Our GA4 solution page and the dashboard reporting overview cover what that setup looks like in practice.
If you're still untangling your own event setup, it's worth bookmarking Google's official recommended events reference and checking your implementation against it event by event. And if you'd rather have that tracking feed straight into a dashboard that already understands purchase, add_to_cart, and begin_checkout the way GA4 intended, that's a conversation worth having before your next funnel report review.
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
Ecommerce Analytics That's Actually GDPR Compliant in Europe
3 min read
The Ecommerce Analytics Platform That Replaces Northbeam (Without the Black-Box Attribution)
3 min read
Key Performance Indicators and Measurement Framework
.d53b12e5.png&w=3840&q=75 "Trivas.ai")
