Ecommerce Tracking in Google Tag Manager: Checklist

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

We set up and repair ecommerce tracking in Google Tag Manager for brands and agencies most weeks, and the pattern rarely changes: the tutorial part goes in fast, then the numbers still disagree with the finance export. So this is the walkthrough we actually give a client. What the events are, how to wire them in GTM, and the specific faults that make a clean-looking setup report wrong revenue.

What is ecommerce tracking in Google Tag Manager?

Ecommerce tracking in Google Tag Manager is the setup that carries GA4 ecommerce events from your site to GA4 through GTM. The site pushes a structured event to the data layer (a JavaScript object holding the event name and an items array), and a GA4 event tag inside GTM reads that object and forwards it. GTM sits in the middle. It moves and shapes the data; it does not create it.

That distinction decides where you look when something breaks. If the purchase value is wrong, the data layer almost always sent it wrong, and GTM passed the mistake along faithfully. Fixing GTM tags when the fault is in the data layer is the most common wasted afternoon in this work.

Which GA4 ecommerce events do you actually need?

GA4 has a defined set of ecommerce events, and each one maps to a step a shopper takes. You do not need all of them on day one, but the checkout and purchase events are not optional if you want revenue in GA4. Google’s GA4 ecommerce events reference lists every event and its required parameters.

Funnel step	GA4 event	What it needs
Sees a product list	view_item_list	items array with item_list_id
Clicks a product	select_item	the clicked item
Views a product	view_item	items, value, currency
Adds to basket	add_to_cart	items, value, currency
Views the basket	view_cart	full items array
Starts checkout	begin_checkout	items, value, currency
Enters payment	add_payment_info	items, payment_type
Completes order	purchase	transaction_id, value, currency, items

The items array is the spine of all of it. Every event carries the products in play, with an item_id, item_name, price and quantity. Get the shape of that array right once and reuse it on every event; get it wrong and the same fault repeats down the whole funnel.

How do you set up ecommerce tracking in GTM?

Set it up in four moves, in this order. The order matters, because you cannot build a tag against a variable that does not exist yet.

1. Build the data layer first. Each ecommerce action must push an event to window.dataLayer with GA4’s event name and a populated items array. This is the one step that may need a developer, and this shape is the spec to hand them:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null }); // clear the previous object
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "T12345",
    value: 128.5,
    currency: "GBP",
    items: [
      { item_id: "SKU-123", item_name: "Example product", price: 64.25, quantity: 2 }
    ]
  }
});

On Shopify, WooCommerce or BigCommerce a plugin or app produces these pushes for you; on a custom build, every event from view_item to purchase follows this same pattern with its own event name. The ecommerce: null push before each event stops values from an earlier event leaking into the next one.

2. Create a trigger per event. In GTM go to Triggers > New > Custom Event and set the event name to exactly match the push, for example purchase. Name it plainly (CE - purchase). Do not trigger ecommerce tags on page views; the purchase page can load without the purchase push having fired.

3. Add a GA4 event tag per event. Go to Tags > New > Google Analytics: GA4 Event, pick your GA4 configuration or Measurement ID, and set Event Name to purchase. Then open the tag’s More settings > Ecommerce (the checkbox is labelled “Send Ecommerce data” in older containers) and set the data source to Data Layer. That one setting sends the whole ecommerce object, items included, with no manual mapping. Only create individual Data Layer Variables (Variables > New > Data Layer Variable, with names like ecommerce.value) if something else needs the values, such as a Google Ads conversion tag that wants the order value on its own. Attach the trigger from step 2.

4. Test in Preview mode, then in GA4 DebugView. Click Preview in GTM, enter the site URL, and walk a real or test purchase. In the preview rail, select the purchase event and open the Data Layer tab: the ecommerce object should be complete. Then open GA4 Admin > DebugView, pick your debug device, and expand the purchase event. Confirm it fired once, the items array is populated, and value and currency arrived. DebugView shows the event as GA4 received it, which is what Preview mode alone cannot prove.

If you are wiring this on Shopify specifically, the container and checkout rules are different enough to need their own steps; we cover those in the Shopify Google Tag Manager setup.

Where does ecommerce tracking in GTM go wrong?

This is the part tutorials skip, and it is why a setup that looks finished still sends numbers you cannot trust. When we audit an ecommerce container, the same handful of faults come up again and again.

• The purchase event fires twice. A shopper refreshes the confirmation page, or returns to it from an email, and the purchase event fires again. Without a unique transaction_id and de-duplication, GA4 counts two sales for one order. This is the single most common reason GA4 revenue reads higher than the finance export.
• The items array is empty. The purchase event fires, the value is right, but items is blank because the data layer did not populate it at that step. Revenue looks fine; item-level and product-performance reports are quietly useless.
• Value and currency are wrong or missing. A value sent as a string instead of a number, or a missing currency, and GA4 either mishandles the revenue or drops it. Multi-currency stores get this wrong most often.
• The tag fires on page view, not on the event. Triggering a purchase tag on the confirmation URL instead of the data layer event means it fires whether or not the order data is ready, so you get events with no products attached.
• Consent blocks the event before it leaves the browser. With Google Consent Mode set to deny analytics storage until opt-in, events from visitors who ignore or decline the banner never reach GA4. That is correct behaviour, but if nobody planned for it, a real slice of traffic goes missing and looks like a tracking fault. We walk through this in how Consent Mode drops GA4 data.

A GA4 purchase count that sits a little below your backend orders is expected; consent denials, ad blockers and dropped sessions always cost you some events. A count that runs above your orders is a bug, almost always the duplicate-purchase fault above. Running the wider container through a structured pass, our GTM audit checklist covers the six things worth checking, catches most of these before they reach a report.

Does server-side GTM make ecommerce tracking harder?

Server-side GTM is not required for accurate ecommerce tracking, and reaching for it too early is its own mistake. A clean data layer and a well-built web container measure ecommerce correctly on their own. Server-side solves different problems: recovering conversions that browser restrictions would drop, keeping control of what data leaves the browser, and sending a first-party signal to ad platforms.

It also adds a server to run, a cost to carry, and a second place for things to break. The honest sequence is web-side first: get the data layer and the events right, prove them in DebugView, then decide whether server-side earns its keep. If you want the fuller picture, we set out the tradeoffs in our server-side tracking guide. Building server-side on top of a broken data layer just moves the same faults to a place that is harder to debug.

What we check when ecommerce tracking sends wrong numbers

When a client’s ecommerce numbers do not match their orders, we do not start by rebuilding tags. We start by watching a real purchase in Preview mode and DebugView, then trace each event back to the data layer that fed it. The fix is usually one of the faults above, in a specific place, not a full rebuild. We do this work for agency and in-house teams most weeks, so the diagnosis tends to be quick even when the container is large.

If you want to see what is firing on your site right now, before deciding anything, Sonar scans a URL from the outside in one click and reports the tags and pixels it can prove from that scan, no account needed. When you already know the ecommerce events are wrong and want them fixed properly, our paid tracking audit goes inside the GA4 and GTM account and returns a written findings report naming each broken event, its impact and the fix.