Every GA4 e-commerce event failing in staging, before going live.
Incomplete item schema, incorrect variants in add_to_cart, purchase blocked by the external checkout architecture.
Event-by-event implementation guide with exact specs for the dev team and a standardized naming convention.
From total failure to full validation. The clearest before/after case to visualize.
Context
Catching it in staging, before launch, is what made the difference — the same failure caught already in production would have meant weeks or months of unusable e-commerce data, plus the added cost of explaining retroactively why the numbers never added up.
How it was actually solved
Why "every event failing" isn’t a single bug
With a total failure, the temptation is to look for one dramatic root cause. Here it was three independent problems overlapping in time: the item object’s schema was missing fields GA4 expects as minimums, product variants were mismapped specifically in add_to_cart (but not in view_item, which ruled out a global cause), and purchase was structurally blocked because checkout lived on an external domain with no dataLayer of its own.
The external checkout problem
When the final checkout happens on a domain or subdomain that doesn’t share the same dataLayer, the purchase event can’t simply "keep firing the same way" — it needs an explicit hand-off mechanism between domains (signed URL parameters, or a server-side call) to replace what the dataLayer would do automatically in a single-domain flow.
Why the event-by-event guide mattered more than the point fix
Fixing the three specific problems would have resolved that one launch. The implementation guide with exact specs per event and a standardized naming convention existed so the next developer touching the dataLayer wouldn’t reintroduce the same class of error out of not knowing the expected standard.
A failure affecting 100% of events rarely has a single cause — it’s more likely several independent problems coinciding, each with its own fix. Treating it as one bug delays finding the other two.
FAQ
Why test this in staging instead of directly in production?
Because an e-commerce tracking failure in production isn’t just "no data" — it means business decisions (media budget, inventory) made on incorrect numbers for however long it takes to notice. Staging exists exactly for this.
Does this kind of audit apply to any e-commerce platform, not just PrestaShop?
Yes, the method (auditing the dataLayer event by event against GA4’s official schema) is platform-independent. What changes is where the dataLayer lives and how it’s generated, not what needs checking.