Back to notes

September 2, 2026 · 6 min read

Why Most GA4 Migrations Fail (And It's Not a GA4 Problem)

Teams blame GA4 for broken reports, but the real failure almost always happened before a single tag was configured — in event taxonomy nobody agreed on.

GA4AnalyticsMarTech

Every GA4 migration post-mortem I've been called into starts the same way: "GA4 is broken, the numbers don't match UA, we can't trust the reports." And every single time, after a few hours of digging, the problem isn't GA4. It's that nobody wrote down what an event actually means before anyone started firing them.

Universal Analytics let you be sloppy. GA4 doesn't.

UA's category/action/label model was forgiving — you could bolt on a new tracking need by inventing a new label value, and the report would still mostly make sense because sessions and pageviews gave you a stable backbone underneath the mess. GA4 has no such backbone. Every interaction is an event with parameters you define, and if two team members define "add_to_cart" differently — one firing on button click, one on successful cart API response — your funnel numbers will quietly diverge and nobody will notice until a stakeholder asks why conversion rate dropped 30% overnight.

The migration doesn't fail in GTM. It fails in the two weeks before anyone opens GTM, when nobody wrote an event taxonomy doc.

An event taxonomy isn't a nice-to-have artifact for documentation's sake — it's the actual contract that makes a GA4 property trustworthy. At minimum it needs: the exact event name, when it fires (client-side click vs. server confirmation), every parameter it carries with its type, and who owns changes to it. Without that document, you don't have a migration plan, you have five people independently guessing.

The symptom that gives it away

If you want to know whether a GA4 implementation was taxonomy-first or tag-first, look at the parameter names in DebugView. Taxonomy-first implementations have consistent, boring, predictable naming — item_id, item_category, value, currency — because someone designed the schema before building it. Tag-first implementations look like an archaeological dig: productID next to item_id next to prod_sku, three different names for the same concept because three different people built three different tags without talking to each other.

  • Write the taxonomy doc before opening GTM — event names, trigger conditions, parameter schema, ownership.
  • Treat GA4's recommended events (purchase, add_to_cart, sign_up) as a starting vocabulary, not a constraint — but don't invent a parallel custom event for something a recommended event already covers.
  • Validate every event in GA4 DebugView against the taxonomy doc before it ships, not after.
  • Assign one owner for taxonomy changes — a shared doc with no owner drifts within a quarter.

The fix costs less than the migration you already paid for

The frustrating part is that fixing this after the fact is more expensive than doing it right the first time would have been — you're now auditing live production tags, reconciling historical data that was collected under two different implicit schemas, and retraining a team on a taxonomy you should have had from day one. A week of taxonomy design up front is cheap. A quarter of "why don't the numbers add up" conversations is not.