Set Up Google Analytics 4 in Magento 2: E-Commerce Events, Consent Mode and Common Mistakes

1. The measurement plan: clarify the questions first, then choose the technology

Before a single tag is placed, write down which decisions the data should support later. Typical questions are: which channels bring orders, at which checkout step do customers drop off, and which product categories are viewed often but rarely bought? Each of these questions determines which events and parameters you actually need.

A measurement plan is not a thick document but a table with event name, trigger, required parameters and an owner. It prevents agency, marketing and development from each working on their own assumptions. If you write the plan only after the implementation, you usually document what happened to emerge instead of steering what should be measured.

Also decide who reads the numbers regularly. A report nobody opens does not need an event. Assign each event a question and a person who decides based on the answer. Events without a consumer only add maintenance effort and error rates.

2. The recommended e-commerce events: view_item, add_to_cart, begin_checkout, purchase

GA4 is event based and ships with a set of recommended events for shops, whose names and parameters are defined by Google. A lean core is usually enough to start: view_item_list and view_item for listings and product pages, add_to_cart and view_cart for the basket, begin_checkout for the start of payment and purchase for the completed order.

It matters to use the predefined names exactly. Only then do the standard e-commerce reports fill up without custom analysis work. Additional events such as add_shipping_info or add_payment_info pay off once you want to know more precisely where customers leave the checkout. Start small and extend in a controlled way.

3. The purchase event in detail: parameters and a data layer example

The purchase event is the most important signal because revenue, campaign evaluation and attribution depend on it. It needs at least a unique transaction_id, the currency, the value and the list of purchased items with ID, name, price and quantity. Tax and shipping are separate parameters and should not be quietly folded into the value.

The example below shows a push in the usual data layer format. The values are placeholders. The preceding reset of ecommerce prevents data from an earlier event from being carried over into the new one by accident.

// Example values, in the shop they are filled from the order
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "100000123",
    currency: "EUR",
    value: 100.00,
    tax: 19.00,
    shipping: 4.90,
    items: [
      {
        item_id: "SKU-123",
        item_name: "Example product",
        price: 50.00,
        quantity: 2
      }
    ]
  }
});

4. Avoiding duplicate purchase events

Orders counted twice are among the most frequent errors. They happen when the confirmation page is reloaded, when customers return to it from the confirmation email, or when several tags send the same event. GA4 itself only discards duplicates when the same transaction_id appears again, and even that is not reliable in every case.

A safeguard in the shop therefore makes sense: the event is fired only once per order, for example through a marker in the session or in browser storage that remembers the order number already reported. In addition, check after every release that a test order creates exactly one purchase entry. Only this test turns an assumption into a verified result.

5. Consent Mode v2: bringing consent and measurement together

Consent Mode is a mechanism that lets Google tags adjust their behavior to the visitor's decision. Consent is passed through signals such as analytics_storage and ad_storage, and version 2 adds further signals for advertising data. The order is decisive: the default values must be set before any tag fires, and the banner updates them after the decision. Our tracking extensions offer a starting point for this, but they do not replace testing in your specific store.

Whether and to what extent you use modeled data after a refusal is a question of your privacy assessment, not only of technology. Do not rely on expectations about how much of the gap Consent Mode closes. Compare your figures with the orders in the shop instead. This text is not legal advice, so clarify the details with your data protection advisor.

6. Cookie consent and banner: what the shop has to deliver

A consent banner only helps if the decision is actually enforced technically. That means: before consent, no tags are loaded or they run only in a restricted consent mode, and the decision is stored and applied again on every page view. Check in the browser network log that no requests to analytics domains leave before consent is given.

In Magento stores with caching, another point matters: pages are usually delivered completely from the cache, so consent must not be rendered into the HTML on the server. It is evaluated on the client. The privacy policy belongs here too: if you use GA4, the policy should describe in a comprehensible way what is measured and how consent can be withdrawn.

7. Validation with DebugView, preview mode and a test order

DebugView in GA4 shows the events of a test device in near real time and with all parameters. It is the most reliable way to check whether name, currency, item list and transaction_id are correct. In Tag Manager you enable preview mode for this, so debug data is transmitted and your test session is not mixed with real data.

Run the whole chain once: open a product page, add it to the basket, start checkout, complete a test order. Afterwards compare order number, value and line items with the record in the Magento backend. Repeat the test with a coupon, with a different delivery address and with another payment method, because deviations tend to appear exactly there.

Document the results of every test order with date, order number and a screenshot. At the next release the state can be compared, and if deviations appear you know immediately what changed.

8. Common mistakes: duplicate tags, wrong currency, tax and shipping

Duplicate tags are especially common: a developer hard coded GA4 into the theme, marketing later adds the same tag in Tag Manager, and every page reports two page views. An extension can also send events in the background on its own. Check the page source and the network requests for multiple measurement IDs. Other failure patterns usually have simple causes that are still easy to overlook.

A wrong or missing currency means revenue is not evaluated correctly. In multi currency stores the currency of the order must be passed, not the base currency. And if tax and shipping end up unplanned inside the value, revenue does not match accounting. Decide beforehand what value means and record that definition in the measurement plan.

9. Gross or net: set a definition and reconcile the numbers

In German retail especially, the question of gross versus net is decisive. Consumers see gross prices while accounting works with net revenue. Decide deliberately which view your reporting needs, and pass tax and shipping separately so both views can be derived. The same applies if you later commission tracking changes and consult the pricing overview: a clearly defined scope is easier to estimate.

Finally, reconcile regularly: order count and revenue in GA4 against the Magento orders of a period. Small deviations are normal because of consent and ad blockers, large ones point to errors. Tracking also affects load time and visibility, so performance optimization and Magento SEO should be looked at together, not in isolation.

10. Summary

11. FAQ: GA4 in Magento 2: The Essentials at a Glance