Moving ecommerce measurement from Universal Analytics to GA4 is not a one-to-one tag replacement. The event model, product schema, checkout steps, and reporting logic all change. Platform-specific implementations such as Magento add another layer of complexity because extensions, checkout architecture, and cross-domain behavior vary widely from store to store.
Why UA-to-GA4 ecommerce migrations are complex
Magento's ecommerce tracking challenges stem from three architectural characteristics: server-side rendering means page transitions do not behave like SPAs, the checkout flow can span multiple domains or subdomains, and the extension ecosystem means every store may have a differentdataLayerstructure depending on which analytics extension is installed.
When migrating from Universal Analytics to GA4, these factors combine to create tracking gaps that are not visible in GA4 itself, they simply appear as missing events or lower conversion rates compared to your UA historical data. For the broader property-level changes, our walkthrough of theGA4 vs Universal Analytics migrationexplains what shifts beyond ecommerce.
Most teams also rebuild their tag stack at the same time, ourGTM and GA4 configuration guidecovers how to wire the new container without leaving legacy UA tags running in parallel.
Common migration failures
The most common migration failures on flexible ecommerce platforms such as Magento are:purchaseevents not firing on the order confirmation page due to Magento's server-side redirect after order placement,add_to_cartevents missing on configurable products where the product variant selection happens via AJAX, and cross-subdomain tracking breaking when checkout is on a different subdomain from the main store.
The post-migration audit should sit on top of a healthy event schema, our guide toGA4 ecommerce tracking checkscovers every event you should validate, and thepurchase event parameter referenceis the field-level sanity check before go-live.
Audit existing UA datalayer
Document your current UA Enhanced Ecommerce dataLayer structure. Identify all push events and their data schemas. This becomes your migration source map.
Map UA events to GA4 equivalents
Create a mapping document: UA checkout step 1 becomes GA4 begin_checkout, UA checkout step 2 becomes add_shipping_info, etc. Map all product field names to GA4 item parameter names.
Update or replace the datalayer schema
Either update your existing Magento analytics extension to push GA4-compatible dataLayer events, or install a GA4-native extension. Verify the items array structure on every ecommerce page type.
Configure cross-subdomain tracking
If checkout runs on a different subdomain, configure linker parameters in GA4 to maintain Client-ID across the domain boundary. Test by verifying the _ga parameter appears in URLs crossing the subdomain.
Deploy and run parallel tracking
Deploy GA4 tracking alongside any remaining reference implementation while you validate. Compare event counts, transaction counts, and revenue regularly during this period rather than assuming the first build is trustworthy.
Validate purchase event reliability
Compare GA4 purchase event count against your backend order count for the same period. Investigate any sustained gap after accounting for consent, cancellations, timing differences, and known exclusions.
Magento GA4 migration checklist
- UA dataLayer schema documented before migration begins
- GA4 items array uses item_id (not id) for product identifier
- purchase event fires reliably after server-side redirect
- add_to_cart fires on AJAX configurable product selection
- Cross-subdomain linker configured for checkout domain
- revenue field migrated to value (Google recommends net revenue; tax and shipping can be sent as separate parameters)
- An overlap validation period is in place while the new implementation is checked
- GA4 transaction count is reviewed against backend order count with documented known differences
Magento GA4 migration audit plan
Validate
- Compare GA4 purchase event count vs Magento order count for 30-day window
- Check GA4 add_to_cart count against Magento cart creation events for same period
- Verify items array on purchase event contains correct item_id values matching Magento product IDs
- Confirm value parameter on purchase sends revenue; send tax and shipping as separate parameters if needed
- Test cross-subdomain tracking by following a complete checkout flow and verifying session continuity
Fix
- Move purchase event trigger from client-side page load to server-side order confirmation hook
- Add dataLayer push for add_to_cart on AJAX product selection in configurable product template
- Configure GA4 tag linker domains list to include checkout subdomain
- Update revenue calculation to send net revenue in the value parameter; send tax and shipping as separate parameters
- Rebuild items array to use item_id instead of id field from UA dataLayer
Watch for
- A sustained purchase-count gap between GA4 and backend order totals after known exclusions are accounted for
- Session count dropping significantly at the checkout subdomain boundary
- Revenue discrepancy growing over time (sign of a partial or intermittent failure)
- add_to_cart count disproportionately low compared to view_item counts
Related guides to read next
GA4 Ecommerce Funnel: Tracking the Complete Customer Journey
Full audit checklist for all GA4 ecommerce events from view_item to purchase.
Duplicate Transactions in GA4
Prevent and detect duplicate purchase events that inflate revenue data.
Tracking Cart Abandonment in GA4
Set up and validate the add_to_cart, begin_checkout, and purchase funnel.
Review your UA-to-GA4 ecommerce migration
GA4 Audits helps surface event-mapping gaps, checkout tracking issues, and cross-domain breaks that often appear during ecommerce migrations.