The GA4 E-commerce Tracking Checklist

Google Analytics 4 can tell you a great deal about how shoppers move through your store, but only if the events it receives are complete, consistent and correctly labelled. A GA4 property with half-implemented e-commerce tracking is worse than none, because it produces confident-looking reports built on gaps.

This checklist walks through the events, parameters and habits that make GA4 e-commerce reporting trustworthy. It is platform-neutral, so it applies whether you run Shopify, WooCommerce, a headless build or something custom. Use it as a build guide for a new store or an audit for an existing one.

How GA4 thinks about e-commerce

GA4 is event-based. Instead of page views and transactions as separate concepts, everything is an event with parameters. For e-commerce, Google defines a set of recommended events with specific names and parameters. If you use the exact names and structure, GA4's built-in reports, such as the monetisation overview, purchase journey and item reports, work automatically. If you invent your own names, you lose those reports and have to rebuild them by hand.

The principle for this whole article: use Google's recommended names exactly, and send every parameter consistently.

The core event set

These are the events that describe a shopping journey. You do not need every one on day one, but the more you implement, the richer your funnel analysis becomes.

Event	When it fires
view_item_list	A list of products is shown, such as a category page or search results
select_item	A visitor clicks a product in a list
view_item	A product detail page is viewed
add_to_cart	An item is added to the cart
remove_from_cart	An item is removed from the cart
view_cart	The cart page or drawer is viewed
begin_checkout	Checkout starts
add_shipping_info	Shipping details are submitted
add_payment_info	Payment details are submitted
purchase	An order is completed
refund	An order is refunded, fully or partially

At an absolute minimum, implement view_item, add_to_cart, begin_checkout and purchase. Those four give you the shape of your funnel.

The parameters that matter

Event-level parameters

• currency: a three-letter ISO code such as USD. Required whenever you send a value.
• value: the monetary value of the event, as a number.
• transaction_id: required on purchase and refund. Must be unique per order.
• coupon, shipping and tax: optional but useful on purchase events.
• items: an array describing the products involved.

Item-level parameters

Each object inside the items array can include:

• item_id and item_name: at least one is required. Use both.
• price: unit price as a number.
• quantity: an integer.
• item_brand, item_category (and item_category2 to item_category5), item_variant.
• discount, coupon, index and item_list_name for list context.

A worked example

A purchase event, as it would appear in a data layer push, looks like this:

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "T-10482",
    value: 89.90,
    currency: "USD",
    shipping: 6.00,
    tax: 7.20,
    items: [
      { item_id: "SKU-123", item_name: "Trail Backpack", price: 59.95, quantity: 1 },
      { item_id: "SKU-456", item_name: "Water Bottle", price: 23.95, quantity: 1 }
    ]
  }
});

Notice the first line, which clears the previous ecommerce object. This is a well-known best practice: without it, values from an earlier event can leak into the next one.

Checklist part 1: data layer

1. Clear before you push. Push { ecommerce: null } before each e-commerce event.
2. Use numbers for numbers. value, price and quantity must be numeric, not strings like "$59.95".
3. Always include currency alongside any value.
4. Send the same item IDs everywhere. The item_id in view_item should match the ID in purchase, or product-level funnels break.
5. Populate the items array on every e-commerce event, not only purchases.
6. Fire on real actions, not on page load. An add_to_cart should fire when the click succeeds, not when a page renders.

Checklist part 2: purchase integrity

Purchases are the event you will make decisions and spend money on, so give them extra care.

1. Unique transaction IDs. Use your real order number. GA4 uses transaction_id to avoid counting the same order twice.
2. Protect against refreshes. A thank-you page that can be reloaded, bookmarked or revisited should not re-fire the purchase. Fire once per order, for instance by remembering that the ID has been sent.
3. Match your shop platform. Compare revenue and order counts in GA4 with your store's reports for the same period. Differences of a few percent are normal; large gaps need investigation.
4. Consider what "value" means. Decide whether value includes shipping and tax and stay consistent, so numbers reconcile with your finance reports. Many stores send the product total excluding tax and shipping.
5. Send refunds. A refund event with the original transaction_id keeps revenue honest over time.
6. Handle payment redirects. If customers leave your site to pay and return, make sure the session and campaign attribution survive, and that the return page reliably fires the purchase.

Checklist part 3: implementation in GTM

1. Use a GA4 event tag per event (or a consistent pattern), triggered by custom events from the data layer.
2. Enable "Send Ecommerce data" on GA4 event tags, using the data layer as the source.
3. Use a single GA4 configuration or Google tag per property, so page views are not sent twice.
4. Test in Preview mode. Walk through the whole journey and inspect each event's payload.
5. Name things clearly and keep a change log, so later you can tell what changed and when.
6. Publish deliberately. Changes to a container do not affect visitors until you publish.

Checklist part 4: making data resilient

Even a perfect implementation loses events if the browser will not deliver them. Expect gaps from blockers, cookie expiry and closed tabs. To make data more resilient:

• Serve GA4 from your own domain. Route the Google tag through a first-party tagging server. Set the server_container_url as shown in connecting web GTM to your server container.
• Consider sending purchase server-side. Delivering the highest-value event from a server reduces dependence on the browser.
• Keep cookies durable. Read our article on first-party cookies and lifetime to see why returning-visitor attribution suffers otherwise.
• Watch the pipeline. With server-side tagging, use request logs to confirm events keep arriving after site changes. See using Event Logs and analytics.

Checklist part 5: property settings

1. Data retention. GA4 keeps event-level data for two months by default, and you can extend it to fourteen months in the settings. Extend it if you want to run exploration reports over longer periods.
2. Mark key events. Mark purchase (and other outcomes you care about, such as sign-ups) as key events so they appear in conversion reporting.
3. Link Google Ads. Link the property so conversions and audiences flow between the two, and import purchase as a conversion.
4. Exclude internal traffic. Filter your team's visits and, if you can, test orders, so they do not pollute revenue.
5. Set the currency and timezone to match your store.
6. Configure cross-domain measurement if checkout happens on a different domain from the store, so sessions are not split.
7. Review referral exclusions. Payment providers that send customers back to your site can otherwise appear as the traffic source for the purchase.

Checklist part 6: consent

If you serve customers in regions that require consent, GA4 needs to know the visitors' choices. Google's Consent Mode lets tags adapt their behaviour depending on whether analytics and advertising storage are granted. Make sure your consent banner is connected to your tags, the consent state is set before tags fire, and the state is passed to your server-side container as well. Details vary by region and by the banner you use, so follow your consent platform's instructions and your legal guidance. More on the wider topic in server-side tracking and privacy.

Common mistakes to look for

• Duplicate purchases. The same transaction ID appearing more than once, often from both a plugin and a manual tag.
• Missing or wrong currency causing zero-value or misreported revenue.
• Items without IDs, which break product reports.
• Events firing on page load so add-to-cart counts inflate.
• Inconsistent item names or IDs between events.
• Two GA4 tags sending page views, doubling sessions.
• Purchase events sent before the order is confirmed, including failed payments.
• No refund tracking, so revenue only ever goes up.

Auditing an existing setup

To audit rather than build, run these checks in order:

1. Open GA4's DebugView, then complete a full test purchase. Do all expected events appear, in order?
2. In the monetisation reports, check that revenue, purchases and item names look sensible.
3. Compare seven days of orders and revenue with your shop platform.
4. Look for repeated transaction_id values in an exploration report.
5. Check the funnel: does each step have fewer events than the one before it? A step with more events than the previous one signals an implementation issue.
6. Segment by browser and device to spot lost data, for example Safari looking unusually weak.

Turning good data into decisions

Once the events are trustworthy, put them to work:

• Build a funnel exploration from view_item through purchase and segment it by channel, device and new versus returning users.
• Rank products by views, add-to-cart rate and purchases to spot items with weak conversion.
• Look at cart abandonment by step to find whether shipping, payment or account creation is the sticking point.
• Compare campaigns by engaged sessions, add-to-cart rate and revenue, not clicks alone, to find waste. Our article on reducing ad waste with web analytics goes deeper.

The bottom line

Reliable GA4 e-commerce tracking comes down to discipline: Google's exact event names, consistent parameters, numeric values with currencies, unique transaction IDs and regular reconciliation against your real orders. Add a resilient delivery path and a proper consent setup and you will have data you can act on with confidence.

Keep this list handy. Re-run it after theme changes, checkout changes and new app installs, since those are the moments tracking most often breaks quietly.