GTM Ecommerce Tracking: Set It Up Without Errors

Contents

• What you need in place before adding a single tag
• Building a clean ecommerce dataLayer, source by source
• Setting up the key events: view_item, add_to_cart, purchase
• Managing consent with Consent Mode v2
• Checking data quality before you rely on it
• The tracking mistakes that cost the most
• Moving from installed tracking to tracking you can decide on
• Frequently asked questions

What you need in place before adding a single tag

Three building blocks are enough to get started: Google Tag Manager, a Google Analytics 4 account, and edit access to the store. Nothing more for a small business.

Tag Manager acts as the conductor. Instead of editing the site code every time your tracking changes, everything runs through a single interface that manages all the tags. If you have never installed the container, the Google Tag Manager step-by-step for beginners covers the initial setup. GA4 receives and organizes the data. The store, for its part, is the source: it is the one that has to announce "a visitor just added this product to the cart."

What do you need: GTM, GA4 and access to the store?

The GTM container must be installed on every page. A GA4 property with its measurement ID, plus admin access to the CMS: without these three elements, no purchase data can flow.

Order matters. You install GTM first, GA4 next through GTM (not hardcoded in the theme), then you wire up the events. Putting GA4 directly in the code on top of GTM remains the most common way to double up your data. I see this double installation on a good share of the stores I open for the first time.

How does the dataLayer work in one minute?

The dataLayer is a small list of information the site publishes on every important action. Picture a conveyor belt: at each event (product view, cart addition, purchase), the store drops a package of data onto it for GTM to read.

Without this conveyor belt, GTM guesses. It can guess a button click, but not the product price, the currency or the order ID. That is where the real foundation lies: everything else depends on it. The official GA4 documentation on ecommerce measurement details the expected format for each event.

Building a clean ecommerce dataLayer, source by source

A clean ecommerce dataLayer exposes, for each purchase, the product details, the total amount, the currency and the unique transaction ID. These four blocks are non-negotiable.

The classic trap: believing the CMS handles everything correctly by default. Some platforms provide a native dataLayer, but it is almost always incomplete for GA4. The currency is often missing, sometimes the price excluding tax, sometimes a product ID consistent with the advertising catalog. The result: a purchase goes out, but half empty.

What should the dataLayer contain for a purchase?

For a purchase event, the dataLayer must contain at minimum: the transaction_id (unique order ID), the value (total amount), the currency (currency, EUR format), and the items array (list of products with name, ID, price and quantity). Without transaction_id, deduplication is impossible.

value and currency go together. Sending a value without a currency is like writing a price on a label without saying whether it is euros or dollars: GA4 cannot convert it, and revenue becomes unreadable. The items array then feeds all product reports and drives the link with Google Merchant Center for Shopping campaigns.

Shopify, WooCommerce, PrestaShop: where to get the product data?

The three most common CMS platforms handle the dataLayer differently, and none covers everything natively without tuning. What you actually need to plan for by platform:

Shopify restricts access to the checkout funnel outside of advanced plans, which makes a reliable purchase harder. WooCommerce generally relies on the GTM4WP extension, free and solid, which pushes a GA4-compliant dataLayer. PrestaShop almost always requires a paid module or a technical intervention.

When I decide on a setup, I start by mapping what the CMS already pushes, because reinventing a dataLayer that half exists already wastes days for nothing. Setting up the tracking for a data-driven store follows the same prioritization logic.

Setting up the key events: view_item, add_to_cart, purchase

Four events are enough to steer a store: view_item (product view), add_to_cart (cart addition), begin_checkout (entering the funnel) and purchase (purchase). Trying to track everything at once is the surest way to finish nothing.

I always set them up in this order of impact. The purchase first, because it is what feeds revenue and ad decisions. The add_to_cart next: it measures real interest in a product. The begin_checkout to spot leaks in the funnel. The view_item last, useful but rarely decisive for a modest-sized store.

Setting up all seven enhanced ecommerce events from the start sinks half of these projects through sheer complexity. That is not caution, it is experience.

How do you create the trigger and the purchase tag in GTM?

You create a trigger on the custom "purchase" event pushed into the dataLayer, then a GA4 tag of type "event" named purchase, linked to the measurement ID. The trigger listens, the tag sends.

In GTM, data layer variables let you pull value, currency, transaction_id and items from the dataLayer. Each GA4 parameter points to its variable. The Google Tag Manager help center details how to create "Data Layer Variable" type variables. Once wired, a single real purchase should fire a single purchase tag, not two.

Which GA4 parameters should you never forget (value, currency, items)?

The three parameters never to forget: value (the amount), currency (the currency) and items (the product detail). A purchase missing one of the three is technically sent, but commercially useless.

1. Send a unique transaction_id Without it, GA4 cannot deduplicate, and a reload of the confirmation page counts a second phantom purchase.
2. Always pair value with currency An amount without a currency breaks conversion and the ROAS calculation in your campaigns.
3. Fill the items array cleanly Name, ID and price per product feed the reports and the Merchant Center link.
4. Align product IDs with the catalog A different item_id between GA4 and Google Ads prevents dynamic retargeting.
5. Test before activating Ads conversions You only wire a purchase conversion to Google Ads once the purchase is validated.

If I had to look at only one of these five points first, it would be the transaction_id: it is what determines the reliability of everything else.

Managing consent with Consent Mode v2

Without Consent Mode v2 wired correctly, a real share of European transactions is never collected in GA4. This is not a regulatory detail. It is a direct hole in your tracked revenue.

Consent Mode v2 connects the cookie banner (the CMP) to Google Tag Manager and adjusts tag behavior based on the visitor's choice. When someone declines, Google sends anonymized signals and then models the missing conversions. But if the wiring is sloppy, no modeling makes up for it: the tags are blocked, and the matching sales vanish without a trace.

Why do my transactions disappear without consent?

Your transactions disappear because a purchase tag blocked by default, with no consent signal, simply sends nothing to GA4. The decline rate then becomes a rate of invisible sales.

The scale depends on the sector. According to the benchmark of cookie consent rates by sector, ecommerce often caps around 45% acceptance, versus 75% for media. In other words, without Consent Mode v2 to model the rest, you only see a fraction of your real sales. The CNIL sets out the French consent framework, which requires declining to be as simple as accepting.

The practical wiring goes through GTM and a Google-certified CMP. The guide to setting up Consent Mode v2 without breaking GA4 or Ads details how to configure the four consent signals, step by step.

Checking data quality before you rely on it

You only trust your tracking after testing it transaction by transaction, never on the strength of a "green" tag in GTM. Preview mode and Tag Assistant are the two verification tools that matter.

GTM preview mode (Preview) opens a test session where you see, in real time, which tags fire on each action. You add a product to the cart, you watch whether add_to_cart goes out with the right parameters. You place a test order, you check that purchase sends a consistent transaction_id, value and currency. The Tag Assistant extension confirms, browser-side, what GA4 really receives. These two tools are complementary, not interchangeable.

How do you test a purchase with GTM preview mode?

You launch preview mode, you run a full purchase from start to finish, then you check in the debug panel that the purchase tag fires only once with all its parameters filled. An empty parameter signals a problem to fix before publishing, no exceptions.

I always recommend a real test purchase, refunded afterward, rather than a simulation. A genuine checkout reveals the surprises in the payment funnel that preview mode alone does not show. The same website traffic statistics to track are worth nothing if the underlying purchase is wrong.

How do you spot a double-counted purchase?

A double-counted purchase shows up when GA4 revenue exceeds that of the back office, or when the same transaction_id appears several times in the reports. The most frequent cause: the customer reloads the confirmation page, which replays the event.

Here are the seven checks to run systematically before declaring tracking reliable:

The tracking mistakes that cost the most

The most costly mistake is not technical. Deciding on never-verified data is what quietly burns the ad budget for months, steering on a false ROAS.

Right behind come the duplicated purchase and the unwired consent, already covered. But a subtler mistake lies in wait for growing stores: believing you should move quickly to server-side tracking because the documentation and the agencies recommend it.

Should you move to server-side tracking?

For a store whose monthly revenue stays below about €30,000, server-side tracking is most often oversized. It adds a hosting cost and a maintenance complexity rarely justified at this stage.

Server-side means routing the data through your own server before GA4, which improves resistance to blockers and data control. The HTTP Archive analyses on server container usage show real adoption, concentrated on large sites. For a modest store, the marginal gain in data does not cover the bill or the configuration time.

I only recommend moving to server-side once blocker-driven losses become measurable and genuinely weigh on media decisions. Not before. The real lever first: make browser-side tracking reliable, clean and tested. With this sound foundation in place, moving server-side becomes a logical evolution rather than a leap forward for its own sake. No business owner redoes this ongoing reliability work by hand every month: it is exactly the kind of check we have industrialized in Lysible.

Moving from installed tracking to tracking you can decide on

Tracking only has value the moment it changes a decision. As long as you watch it without acting, it is a cost. The moment it tells you which product to push or which channel to cut, it is an investment.

The threshold is clear. Once your purchase data is reliable and stable over several weeks, you can finally compare channels, calculate a real acquisition cost and allocate budget without guessing. Before that threshold, every decision rests on sand. After it, the same time spent on GA4 brings in concrete euros. That is the whole point of connecting Search Console, GA4 and sales into a single reading, which Lysible centralizes for small businesses that want to decide without a permanent provider. Your next concrete step: run a test purchase this week and check that the purchase is clean.