7 Data Layer Errors That Skew Your GA4 Data (and How to Fix Them)

In short: the most common data layer errors that skew GA4 are a double-counted page_view, a purchase with no amount, an empty items array, an event that stops firing after a release, inconsistent casing, undefined or wrongly typed values, and an event firing before consent. Each one has a clear symptom and a clear fix.

Your GA4 numbers look clean. The lines go up, the reports fill in, everyone stares at the dashboard with confidence. The problem is that GA4 never tells you "careful, this data is wrong." It shows whatever you send it, full stop. And if the data layer sends things crooked, you're steering with numbers that lie, without knowing it.

With clients, I keep running into the same culprits. Here are the 7 data layer errors that pollute GA4 most often. For each: the symptom in your reports, the cause in the data layer, and the fix. Let's go.

The double-counted page_view

Symptom: abnormally high traffic, an inflated session count, sometimes a strangely low engagement rate. The numbers look good, too good.

Cause: the classic culprit is two GTM containers on the site (often the leftover of a migration where the old one was never removed), or a duplicate GA4 tag configuration. So every page_view fires twice.

Fix: audit your containers and keep only one. In GTM, check there aren't two GA4 configuration tags firing on the same pages. A quick look in Preview mode is enough to see the page_view fire twice.

The purchase with no amount

Symptom: your conversions are counted in GA4, but revenue is zero or badly underestimated. The number of purchases lines up, the revenue doesn't.

Cause: the purchase event fires, but the value key isn't pushed to the data layer, or it's mismapped in the GTM variable. I've seen this after a funnel redesign: the event fired fine, but without the amount.

Fix: check that the purchase push includes both value and currency, with the right type (a number, not a string). Then verify the variable mapping in GTM, and confirm the value in GA4 DebugView.

The empty items array

Symptom: your e-commerce revenue is mechanically underestimated, product reports come up empty or incomplete, even though sales are happening.

Cause: after a migration, the items array goes to GA4 empty. The e-commerce structure wasn't correctly repopulated, often because the product data is no longer available at the moment of the push.

Fix: check that each item contains at least item_id, item_name and price. Keep in mind items must be populated at the moment the event fires, not after. GA4 DebugView immediately shows whether the array arrives empty.

The event that stops firing after a release

Symptom: a sudden drop of one specific event in your reports. A view_cart, a sign_up, or an add_to_cart that falls to nearly zero overnight.

Cause: a release moved a piece of code, changed a button's CSS id, or altered the order of the pushes. The listener can no longer find its trigger. The site works, but the event is silent. This kind of regression often goes unnoticed for weeks.

Fix: run QA systematically after every release and compare the before/after behavior. In GA4, watch for sudden volume swings per event: a sharp drop is almost always a regression signal, not a drop in activity.

Inconsistent casing (camelCase vs snake_case)

Symptom: GTM variables that are empty for no apparent reason, data present on some pages and missing on others.

Cause: one page sends pageType, another sends page_type. To GTM, those are two different variables. As a result, the variable only populates half the time.

Fix: pick one naming convention (camelCase or snake_case) and document it in the tracking plan. When in doubt, the console is enough to spot casing inconsistencies from one page to the next. One rule, and only one, and you save yourself hours of debugging.

undefined or wrongly typed values

Symptom: the literal string "undefined" showing up in your reports, broken custom dimensions, or metrics that refuse to aggregate correctly.

Cause: a variable pushed before it's available ends up as undefined. Another frequent case: a number sent as a string ("29.90" instead of 29.90), which breaks calculations on the GA4 side.

Fix: set default values to avoid undefined, and check the type of your values, especially amounts, which must be numbers. Worth noting, this type check is one of the first to be forgotten, even though it silently skews all your revenue.

The event that fires before consent

Symptom: Ads conversions that disappear after a consent mode change, or conversely data collected when consent wasn't given (a real GDPR risk).

Cause: an ordering problem. A custom event fires before the consent information is available. The push sequence isn't respected, and the CMP (the consent management platform) arrives too late.

Fix: make sure consent-related events fire before custom events. GTM Preview mode lets you visualize the sequence and spot these race conditions. Done right, consent and data quality don't conflict: you can have both.

How to catch these errors before they get expensive

You've probably noticed these 7 errors share one thing. None of them raises a red alert. The site works, visitors buy, and meanwhile the data drifts in silence, sometimes for weeks, until an analysis or a media budget pays the price.

The classic defense is manual QA: replaying the journeys, checking every event in GTM Preview. Essential, but time-consuming, and impossible to redo in full on every release. Between two QA passes, nobody is watching.

That's exactly the gap MayIA° fills: a system that replays journeys and checks every data layer event continuously, before and after each release, with a contextualized alert the moment one of these errors appears. Manual QA stays useful for scoping; automation, on the other hand, never sleeps.

Wrapping up

If there's one thing to take away: when your GA4 numbers surprise you, don't start by blaming the tool. Nine times out of ten, the problem is upstream, in the data layer. A doubled page_view, an empty items, inconsistent casing, and a whole report tips into fiction.

The right reflex: start from the symptom, trace it back to the cause in the data layer, fix it, then put something in place to stop it coming back on the next release.

Your GA4 data looks off and you want to know for sure? Reach out to the MayIA° team, we'll look at it together.

FAQ

How do I know if my data layer is skewing my GA4 data?

The first signal is a gap between GA4 and a reliable source like your back office or payment tool. GA4 DebugView and GTM Preview mode then let you verify event by event whether the data sent is correct. A sudden swing in an event's volume is another classic signal.

Why don't my GA4 conversions match my back office?

The most frequent causes are a purchase firing without an amount, an empty items array, or an event counted twice due to a duplicate GTM container. A persistent gap is almost always a collection problem, not a GA4 problem.

Can a data layer error have GDPR implications?

Yes. If an event fires before consent is collected, you risk gathering data with no legal basis. Conversely, a badly ordered consent mode can lose conversions. Push order relative to the CMP is both a technical and a regulatory control point.

How do I stop these errors from coming back on every release?

By QA-ing the data layer before and after every release and monitoring event volumes in GA4. For sites that deploy often, automated data layer monitoring catches regressions continuously without relying on manual QA every time.