GA4 E-commerce Tracking: The Complete Event Setup Guide

Why Most GA4 E-commerce Setups Are Incomplete

GA4 ships with a powerful e-commerce event schema. Most stores only fire a fraction of it. They track purchases, maybe view_item, and call it done. That leaves cart data, checkout step data, and promotion performance completely invisible.

The result is a reports tab full of revenue numbers with no story behind them. You can see that 94% of visitors didn't buy. You can't see where they left or what they looked at first.

This guide covers every standard GA4 e-commerce event, what each one measures, how to fire them correctly, and what the data actually tells you. If you're building a setup from scratch or auditing an existing one, this is the sequence to follow.

The Full GA4 E-commerce Event Sequence

Google defines a recommended sequence of events that map to the shopping journey. Each event has required and optional parameters. Getting the parameters right matters as much as firing the event itself - GA4's e-commerce reports are built around them.

The core events in order are:

• view_item_list - product appears in a category or search results page
• select_item - user clicks a product from a list
• view_item - user lands on a product detail page
• add_to_wishlist - user saves a product
• add_to_cart - user adds to cart
• view_cart - user opens the cart
• remove_from_cart - user removes an item
• begin_checkout - user starts checkout
• add_shipping_info - shipping step completed
• add_payment_info - payment step completed
• purchase - transaction completes
• refund - full or partial refund processed

Promotion events sit slightly outside this sequence: view_promotion and select_promotion track banner ads and internal campaigns.

Event Parameters: The Part That Breaks Most Implementations

Every e-commerce event passes an items array as its primary parameter. Each item object in that array describes a product. Getting this structure wrong is the single most common implementation mistake - and it's invisible until you try to run a product performance report and find the data is missing or mismatched.

The items Array Structure

Each item object should include:

• item_id - your internal SKU or product ID (required)
• item_name - product name (required)
• price - unit price as a number, not a string
• quantity - how many units
• item_category - primary category
• item_category2 through item_category5 - subcategory hierarchy
• item_brand - brand name
• item_variant - size, color, or other variant
• item_list_name - the list context where the item appeared
• item_list_id - machine-readable list identifier
• discount - discount amount applied
• coupon - coupon code used
• index - position in the list

The purchase event also needs top-level parameters outside the items array: transaction_id, value, currency, tax, shipping, and optionally coupon.

Implementation Methods: GTM vs. Direct vs. Platform Native

Three paths exist to get these events into GA4. Which one to use depends on your platform, your team's technical capacity, and how much custom logic your store needs.

Google Tag Manager (Recommended for Most Stores)

GTM is the right choice when you need flexibility without touching source code on every change. You push a dataLayer event from your platform, then GTM reads it and fires the GA4 event tag with the correct parameters.

The dataLayer push for an add_to_cart event looks like this in your page code:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'USD',
    value: 49.99,
    items: [{
      item_id: 'SKU_001',
      item_name: 'Merino Wool Sweater',
      item_category: 'Clothing',
      item_variant: 'Blue / Large',
      price: 49.99,
      quantity: 1
    }]
  }
});

In GTM, you create a GA4 Event tag, set the event name to add_to_cart, and use the built-in ecommerce variable to pass the items data. You'll want to clear the ecommerce object between pushes - otherwise old product data bleeds into new events. Add a dataLayer push of { ecommerce: null } immediately before each new ecommerce push.

Our GTM setup guide covers the full tag configuration in more detail.

Platform-Native Integrations

Shopify, WooCommerce, BigCommerce, and Magento all offer GA4 integrations that handle the event firing automatically. The trade-off is control. Native integrations often miss optional parameters like item_list_name, index, and discount - which limits what you can analyze later.

If you're on Shopify, the native GA4 integration handles purchase, add_to_cart, and view_item reasonably well. Checkout step events are harder because Shopify's checkout pages restrict custom script injection on most plans. Review exactly what your plugin or native integration sends before assuming the data is complete.

Our Shopify SEO guide covers Shopify-specific tracking constraints in more detail.

Direct gtag.js Implementation

Direct implementation means calling gtag() functions from your site code without GTM as an intermediary. It's faster to load, simpler in architecture, but requires a code deploy for every change. This works well for development teams that control their own release cycle and don't need non-technical marketers adjusting tags.

Auditing an Existing Implementation

Before building anything new, check what's actually firing. Three tools help here.

GA4 DebugView (found under Admin - DebugView) shows every event as it fires in real time when you have debug mode active. Walk through your own purchase funnel and watch the event stream. You'll immediately see which events are missing, which have malformed parameters, and whether the items array is structured correctly.

Google Tag Assistant (the browser extension) shows what GTM tags are firing and what data they're sending. It's particularly useful for verifying that the ecommerce object is populated before the GA4 tag fires.

GA4's e-commerce reports themselves reveal gaps indirectly. If your purchase count matches your order management system but your add_to_cart count is suspiciously low - or if view_item data is missing product names - something is broken upstream.

Cross-referencing GA4 data against your platform's native order data is the final sanity check. Purchase counts should match within a few percent. Large discrepancies usually point to duplicate firing (over-counting) or tracking code missing on certain device types or browsers (under-counting).

What to Do With the Data Once It's Flowing

Collecting events is only half the work. The reports that make e-commerce tracking valuable are spread across two places in GA4: the standard Monetization reports and the Explore section.

Standard Monetization Reports

Under Reports - Monetization, you'll find:

• E-commerce purchases - revenue, items purchased, and item views with conversion rates for each product
• Purchase journey - a funnel showing session counts at each stage from session start through purchase
• Checkout journey - dropout rates at each checkout step (requires add_shipping_info and add_payment_info events)
• Promotions - views and clicks for internal promotions if you're tracking view_promotion/select_promotion

The Purchase Journey report is often the first place to look for quick wins. It shows what percentage of sessions that added to cart actually started checkout, and what percentage that started checkout completed it. Large gaps at specific stages point to specific problems.

Funnel Exploration for Custom Analysis

The standard Purchase Journey report has fixed steps. For custom funnel analysis - segmenting by traffic source, device type, or first-time vs. returning customers - you need GA4's Funnel Exploration. This lets you define exactly which events constitute each step and compare completion rates across any dimension you choose.

Our GA4 Funnel Exploration guide walks through building these reports in detail. When your e-commerce events are firing correctly, funnel exploration becomes one of the most actionable reports in your analytics stack.

Item-Level Performance

The E-commerce purchases report breaks down by item_name or item_id. You can see which products get viewed most often, which convert best (purchases divided by item views), and which have the highest average revenue per unit. Products with high view counts but low purchase rates often have pricing, description, or photography problems rather than traffic problems.

This analysis only works if you're passing item_name and item_id consistently. If the same product appears under different names across events ("Blue Sweater" in view_item but "Merino Wool - Blue" in purchase), GA4 treats them as different products and the data fragments.

Connecting Revenue to Acquisition Channels

GA4's default channel grouping reports show sessions and conversions by channel. Once purchase events fire correctly, you can see revenue by channel directly - not just conversion counts. This reveals which channels bring buyers versus browsers, and which channels produce customers with higher average order values.

Understanding GA4's channel groupings is important here because misattributed traffic inflates or deflates channel revenue numbers. If you're seeing unexpectedly high Direct revenue, dark traffic is likely the culprit.

Common Mistakes That Break E-commerce Data

A few patterns show up repeatedly in broken GA4 e-commerce setups:

Duplicate purchase events. Firing the purchase event on a thank-you page that users can refresh, or that loads when users return to confirm their order, causes double-counting. Use a session flag or a server-side check against transaction_id to fire the event only once per transaction.

Missing currency parameter. GA4 requires a currency code on any event that passes a monetary value. Events without it are discarded from revenue calculations entirely. The currency field takes ISO 4217 codes (USD, EUR, GBP).

Price as a string instead of a number. Passing price as "49.99" instead of 49.99 breaks revenue aggregation. The items array expects numeric values for price, discount, and quantity.

Not clearing the ecommerce dataLayer between events. This causes previous product data to bleed into subsequent events. A view_item event might accidentally include cart contents from an earlier add_to_cart push.

Inconsistent item_id values. Using a numeric SKU in some events and a string version in others (123 vs. "SKU-123") splits product data across what GA4 treats as different items.

Server-Side Events for Better Data Quality

Client-side tracking has a persistent problem: ad blockers, browser privacy settings, and consent management platforms all reduce the number of events that actually reach GA4. Estimates vary, but 15-30% of e-commerce events can be lost this way depending on your audience.

For the purchase event specifically, server-side firing is worth considering. When an order completes, your server sends the purchase event directly to GA4's Measurement Protocol endpoint rather than relying on the browser. This is immune to ad blockers and fires regardless of the user's cookie consent status for analytics (note: check your local privacy regulations before implementing).

Server-side tracking requires development work, but the data quality improvement on purchase events alone is usually worth it for stores doing meaningful volume. A 20% gap between GA4 purchases and actual orders is a large blind spot.

The conversion funnel analysis in MeasureBoard can help surface where your biggest data gaps are appearing, giving you a starting point for prioritizing which events to fix first.

The Implementation Priority Order

If you're building a new setup or fixing an existing one and need to phase the work, this is the order that delivers the most analytical value fastest:

Phase 1 (essential): purchase, add_to_cart, begin_checkout, view_item. These four events give you a basic funnel and product performance data.

Phase 2 (high value): add_shipping_info, add_payment_info, view_cart, remove_from_cart. These fill in the checkout journey and reveal exactly which step loses the most users.

Phase 3 (complete picture): view_item_list, select_item, view_promotion, select_promotion, refund, add_to_wishlist. These enable list-level product performance analysis and promotion measurement.

Most stores should be able to reach Phase 2 completeness within a focused two-week implementation sprint. Phase 3 events require more coordination with your catalog and CMS systems but are worth it for stores with large product catalogs where category page performance drives a significant portion of revenue.

For a broader look at where your funnel is leaking, our e-commerce funnel analytics guide covers the strategic analysis side once your event tracking is in place.