Enhanced Ecommerce to GA4 on Magento 2: What Your Old dataLayer Still Gets Wrong

TL;DR

Enhanced Ecommerce was a Universal Analytics feature, and GA4 did not inherit it. It replaced it with a different event vocabulary, different field types, and different rules about what a category or a variant is. The WeltPixel Google Analytics 4 extension is the direct successor of WeltPixel's Universal Analytics Enhanced eCommerce GTM extension, which is exactly why so many stores running it today are running a container generated years ago against the old format. This is an audit, not a migration guide: five dataLayer facts worth checking against your live store, three things that look broken and are not, the Universal Analytics leftovers that are safe to delete, and the custom dimension trap that got a dedicated safeguard in v1.17.2.

Key Takeaways

• GA4 ecommerce events are snake_case (view_item, add_to_cart, purchase). A dataLayer still pushing Enhanced Ecommerce names keeps sending old event names: GA4 still collects them, but only the recommended ecommerce events automatically populate the dimensions and metrics its ecommerce reports are built from [5].
• Prices and quantities must be numeric. A price arriving as "49.90" instead of 49.90 is a common reason revenue looks empty while events look fine.
• The extension refactored its dataLayer to Google's recommended structure in v1.12.1. Stores that upgraded the module but never re-generated and re-imported the GTM container kept the old container running against the new dataLayer.
• Some things that look like bugs are deliberate: the ecommerce object is cleared before each push, coupon is sent as an empty string when no coupon applies, and product impressions go out in chunks of no more than 15 items.
• Universal Analytics leftovers still sit in the configuration, most visibly the legacy ecomm_pagetype variable in the Google Ads remarketing section. It is not GA4 data and it is not doing anything for your GA4 reports.
• Custom dimension mapping is where stores break themselves quietly. Since v1.17.2 the extension guards against pushing custom values into GA4 reserved field names.
• Verification runs on three tools that answer three different questions: the dataLayer preview window, GTM preview mode, and GA4 DebugView.

Where your old dataLayer actually came from

The WeltPixel Google Analytics 4 extension is documented as the successor to the company's Universal Analytics Enhanced eCommerce GTM extension [4]. That lineage matters more than it sounds. If your Magento 2 store has been tracking ecommerce since 2019 or 2020, the odds are good that your GTM container was first built for Enhanced Ecommerce, then patched forward through the GA4 transition, one tag at a time, by whoever was available.

The result is a container that mostly works. Sessions arrive. Pageviews are fine. Someone in a marketing meeting asks why the product performance report is missing products, and nobody can point at a single broken thing, because nothing is broken in the way software is usually broken. The dataLayer format and the container's triggers no longer match.

Google has not moved the goalposts recently, which is the useful part. Google's ecommerce event reference and the GA4 changelog show no schema changes to these events in the trailing year [2][3]. Whatever mismatch exists between your dataLayer and GA4 has been sitting there for a while, and fixing it once fixes it for good.

Five dataLayer facts worth auditing against your live store

Open your storefront, open the browser console, and compare what your store pushes against what the extension documents as of v1.17.3 [4].

1. Event names are snake_case. The extension pushes GA4's recommended ecommerce events: view_item, view_item_list, select_item, add_to_cart, view_cart, begin_checkout, add_payment_info, add_shipping_info, purchase, and the rest of the standard set. Anything still named in the Enhanced Ecommerce style is a leftover, not an alternative spelling.

2. Price and quantity are numbers. Not strings. GA4 will happily collect a quantity that arrives as the string 2 and then decline to sum it anywhere useful. This is a common cause of the "events are firing but revenue is zero" ticket, and it is worth checking early because it is cheap to confirm.

3. Category values follow the category subtree. Products push their category path rather than a single flat label. On the PRO version you can control how deep that path goes and exclude specific categories from it, which is how stores with a root category that everything belongs to avoid an item_category column where every row says the same word.

4. Configurable products push their variant on view_item. If your catalog is mostly configurables and your GA4 item reports show only parent SKUs, check this before you rebuild anything. The variant data is in the specification.

5. Discounts ride on the purchase event. The purchase payload carries the discount value, which means order-level promotion analysis works without a separate custom event. If you built your own discount tracking during the Universal Analytics years, that separate event can end up double-reporting the same value.

For the full documented event list rather than the audit subset, the older reference at which ecommerce events the GA4 extension tracks is still the right page.

Why does an old container keep producing old data?

Two reasons, and they compound.

The first is the v1.12.1 refactor. That release restructured the extension's dataLayer to follow Google's recommendations, and the documentation is explicit that the GTM container has to be re-imported afterward [4]. A module upgrade alone does not update GTM. Your Magento side starts speaking the new format while your container keeps listening for the old one, and the symptom is not an error anywhere, it is a report that slowly stops matching reality.

The general rule is stronger than that one release. The extension generates the GTM container JSON from your Magento configuration under WeltPixel > Google Analytics 4 Ecommerce > JSON Export Options, so any tracking configuration change makes the container in GTM stale until you re-generate and re-import it. And an imported workspace is still a draft. Publish it, or the storefront keeps serving the previous version.

The second reason is the platform underneath. Adobe fixed the GTM addToCart dataLayer for configurable products in Magento 2.4.8, released April 8, 2025 [1]. If your store sits on an older patch level and your add-to-cart data for configurables has looked wrong for a long time, the fix may be a core upgrade rather than anything in your container. The same release also allowed connections to region1.analytics.google.com when GA is enabled, which is the CSP change that had been throwing errors for EU visitors [1].

What looks broken but is working as designed

Three behaviors get reported as bugs often enough to list them.

The ecommerce object is cleared before every push [4]. If you inspect dataLayer in the console after a page transition and find the previous product's data gone, that is deliberate. It exists to stop the old items array from bleeding into the next event.

The coupon field is sent as an empty string when no coupon applies, rather than being omitted [4]. Consistent key presence is easier to build tags against than conditional keys.

Product impressions are chunked at a maximum of 15 items per push [4]. A category page with 48 products does not send one enormous view_item_list; it sends several. The extension also documents an 8KB ceiling on payloads [4]. If you built a GTM variable that reads only the first impression push, a long category page will look like it lost most of its products, and the variable is the thing to fix.

Which Universal Analytics leftovers should you actually delete?

The most visible one is ecomm_pagetype, the legacy variable still present in the Google Ads Remarketing section of the extension configuration [4]. It is a Universal Analytics dynamic remarketing artifact. It does nothing for GA4 reporting. Whether you remove it depends entirely on whether an active Google Ads remarketing setup still consumes it, so check the Ads side before touching it. If Ads conversion tracking is the part of your stack you are actually reworking, the Google Ads conversion tracking setup guide covers that path properly.

The less visible leftovers are in GTM, not Magento: custom HTML tags someone added in 2021 to patch a gap the extension has since closed, triggers firing on event names nothing pushes anymore, and variables reading dataLayer keys that were renamed in the v1.12.1 refactor. A generated container gives you a clean baseline to compare against. Import a freshly generated JSON into a new GTM workspace and diff it against what is live. Everything in your live container that is not in the generated one is something a human added, and each of those is either load-bearing or dead. There is no third category.

Custom dimensions and the reserved-name trap

The extension documents a set of custom dimensions you can push and map inside GA4, which is how store-specific product attributes reach your reports. It is also one of the easiest surfaces to break quietly.

The failure mode: you name a custom dimension something GA4 already reserves internally, and the dimension shows up empty in reports with no error to explain why. Version 1.17.2 added a safeguard against custom fields colliding with reserved field names [4]. Worth knowing that the guard exists, and worth knowing that anything mapped before that release was mapped without it.

While you are in GA4's admin: the platform added configurable conversion lookback windows on August 11, 2026, and a Source Group dimension plus a hostname filter on June 11, 2026 [3]. None of that changes your dataLayer. It changes how the data you send is attributed and grouped in reports, which is the sort of thing that makes an unchanged tracking setup produce different numbers month over month.

How do you verify any of this?

Three tools, three different questions, in this order.

Is the store pushing the right thing? The extension's dataLayer preview window shows the pushes as they happen on the storefront, and it can be restricted to specific IP addresses so you can inspect a live production store without exposing the panel to customers [4].

Is GTM receiving and reading it? GTM preview mode connects to your storefront and shows which tags fired, which triggers matched, and what each variable resolved to. This is the layer that catches a variable still reading a pre-refactor key name.

Is GA4 receiving it? DebugView shows events arriving on the GA4 side, with parameters, in near real time. If the dataLayer is right and GTM fired and DebugView shows nothing, the problem is between GTM and GA4: a wrong Measurement ID, an unpublished container, or a consent signal blocking the tag.

Work top to bottom and each tool eliminates a layer. Starting at DebugView means guessing; starting at the dataLayer preview means isolating. If your specific symptom is missing orders rather than missing product data, the dedicated writeup on missing transactions and revenue in GA4 is the faster route, and for anyone still standing the whole thing up from scratch, start at how to add Google Analytics 4 to Magento 2.

FAQ

Does Enhanced Ecommerce still work in GA4?

No. Enhanced Ecommerce was a Universal Analytics feature and GA4 replaced it with a different set of recommended ecommerce events and parameters. If your dataLayer still pushes the old event names, GA4 still collects them, but only the recommended ecommerce events automatically populate the dimensions and metrics its ecommerce reports are built from [5].

Why is my GA4 revenue zero when purchase events are firing?

Check the data types first. Prices and quantities have to arrive as numbers, not strings. After that, check that the purchase event carries the value and currency parameters and that the transaction ID is present [2].

Do I need to re-import my GTM container after upgrading the extension?

Yes, after any change that affects the generated JSON, and the v1.12.1 dataLayer refactor specifically requires it. The container is generated from your Magento configuration, so it is a snapshot. Re-generate, re-import, and publish.

Why do my category pages only show 15 products in GA4?

Impressions are pushed in chunks of up to 15 items, so a long category page produces several pushes rather than one. If only the first chunk reaches GA4, the GTM variable or tag reading the impression data is the thing to fix.

Should I delete the ecomm_pagetype setting?

Only after confirming nothing in Google Ads still uses it. It is a Universal Analytics dynamic remarketing leftover and contributes nothing to GA4, but an old remarketing configuration may still read it.

If you are running an audit like this on a store that still needs the GA4 tracking layer rebuilt underneath it, the WeltPixel Google Analytics 4 extension generates the container for you instead of asking you to maintain one by hand, which removes most of the drift this article is about. It supports Magento 2.3.0 through 2.4.9 and installs through composer only, as of v1.17.3, released August 3, 2026.

Sources

1. Adobe Commerce 2.4.8 release notes, April 8, 2025, https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-8
2. Google Analytics, "Measure ecommerce" (GA4 recommended ecommerce events), https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
3. Google Analytics, "What's new in Google Analytics", https://support.google.com/analytics/answer/9164320
4. WeltPixel Google Analytics 4 User Guide, v1.17.3, August 3, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
5. Google Analytics Help, "[GA4] Custom events", https://support.google.com/analytics/answer/12229021