The GA4 mistakes that quietly corrupt your reporting
GA4 fails politely: dashboards keep rendering, numbers stay plausible, and the errors hide inside defaults nobody revisited. The most common ones, and how to check yours in an afternoon.
The dangerous thing about GA4 is that it never looks broken. A misconfigured property produces charts exactly as confident as a correct one, and the errors surface months later in a meeting, when someone cross-checks against the CRM and the numbers are off by 40 percent. Most of the damage comes from a short list of mistakes, and each has a check you can run this afternoon.
Counting key events that are not conversions
GA4 lets you promote any event to a key event, and most properties have promoted generously: scrolls, video plays, outbound clicks, a legacy event nobody remembers creating. Every one of these pollutes the number that ad platforms import and bid against.
Check: open the key events list and interrogate each one. Would a salesperson agree this event is a lead or a sale? If not, demote it. The count of key events should be small, boring and defensible in front of your CFO.
Events firing on intent instead of outcome
The classic: the conversion fires when the form button is clicked, not when the submission succeeds. Validation failures, spam bounces and double clicks all count. Its cousin fires on thank-you page load, so refreshes and bookmarked returns count again.
Check: submit your own form with deliberate mistakes, then correctly, then refresh the confirmation page, with DebugView open. Count what fires. One clean submission should produce exactly one event, and the failed attempts none.
The same conversion counted from two setups
Sites accumulate tracking layers: a hardcoded gtag, a Tag Manager container, sometimes a plugin doing both. Two layers each dutifully report the same purchase, and revenue doubles at the collection layer where no deduplication rescues it.
Check: view page source and count analytics snippets, then watch DebugView during one conversion. Two identical events a moment apart means two layers. Pick one layer, remove the others entirely.
Trusting the migrated property
Properties auto-migrated from Universal Analytics carried over settings nobody chose: sampled audiences, stale event mappings, attribution defaults that changed meaning between systems. If nobody has deliberately reviewed the property since migration, assume it encodes 2022’s assumptions.
Check: review data streams, event definitions, attribution settings and data retention against what you would set up today. Data retention alone bites constantly: the default keeps user-level data 2 months, and explorations silently truncate to it.
Ignoring what consent mode does to the numbers
With consent mode configured, denied users are modeled or absent depending on setup. Either way, GA4’s totals diverge from the ad platforms’ and from the CRM’s by design. Teams that do not know this burn days reconciling numbers that are defined to differ.
Check: find out which consent configuration you run, what your denial rate is, and write both into the header of any report where the numbers get compared. The divergence is fine; the surprise is not.
Nobody wrote anything down
The meta-mistake. Events named by whoever built them, parameters that mean different things on different pages, and no document saying what should exist. Every new person re-derives the setup by archaeology, and every redesign silently breaks part of it.
Check: if there is no measurement plan, a one-page table of event, trigger, parameters and destination, the setup is unowned, whatever else is true of it.
What good looks like
A trustworthy GA4 property is mostly a short list of habits: few key events, each mapping to money; events fired on outcomes, once; one collection layer; settings chosen rather than inherited; consent effects known and stated; the whole thing documented on a page. None of it is clever. All of it is the difference between reporting you defend and reporting you apologise for.
We rebuild this layer before touching any ad account, because optimising against corrupted numbers is worse than not optimising at all. If your GA4 has never had a deliberate audit, the odds it needs one are, in our experience, close to certainty.