Companies switch analytics tools the way people switch diets. The tool gets blamed, the migration gets budgeted, and eighteen months later the new tool shows the same nonsense the old one did. That is because the problem was never the tool. It was the implementation underneath it, and the implementation moved over with the furniture.
This guide is about that layer: the events, the dataLayer, the naming, the verification. It is the least glamorous part of analytics and the part that decides whether anything downstream can be trusted.
Why does tracking break so often?
Because nobody owns it. The developer who added the dataLayer push left. The agency that built the GTM container finished its contract. The marketer who requested the event moved on. What remains is a container with 60 tags, no documentation, and a property where purchase, Purchase, and transaction_complete all coexist.
Tracking is not a project. It is a system that degrades every time someone deploys code, redesigns a checkout, or installs a consent banner. If nothing watches it, it rots. Quietly. The dashboards keep rendering, which is the dangerous part: broken tracking rarely looks broken. It looks like a slightly disappointing month.
What does "implemented" actually mean?
My bar is simple. An event is implemented when it has three things:
- An owner: one named person who answers for it when it breaks.
- A definition: written down, with the trigger condition and the parameters it carries. "Fires on the order confirmation page, carries transaction_id, value, currency, items."
- A test: proof it fires in production, with the right values, visible in the network tab. Not in a preview tool. In production.
Most setups I audit have zero of the three on most events. That is not an implementation. That is a pile of tags.
What is the dataLayer, really?
A contract. Your site promises to describe what happens ("someone bought something, here is the order") in a stable, documented shape, and your measurement tools promise to read only from that shape. When both sides keep the promise, you can redesign the site, swap GA4 for something else, or add a new ad platform without rewriting everything.
When there is no contract, every tag scrapes the page directly: CSS selectors, URL patterns, DOM text. Then a designer renames a button and your conversion tracking dies without a single error message. If your tracking history includes mysterious drops that coincided with releases, this is usually why. I wrote a plain-language explainer on this: what a dataLayer is and why yours is probably a mess.
What breaks implementations most often?
After years of audits, the repeat offenders are boringly consistent:
- Deploys. The site changes, the tracking assumptions do not. Nobody tests tags in the release process.
- Consent wiring. The banner blocks some tags, half-blocks others, and nobody rechecks data volume after installing it. My piece on what your consent banner isn't blocking covers the mirror-image failure.
- Single-page-app routing. Virtual pageviews fire twice, or never, because the framework rerenders without a real page load.
- Duplicate tags. GA4 via GTM plus GA4 hardcoded in the theme plus GA4 inside a plugin. Every number inflated, nobody sure by how much.
- Naming drift. Three teams, three conventions, one property. The data is technically there and practically unusable.
How do you verify tracking without lying to yourself?
The GTM preview pane is a rehearsal, not the performance. It runs in your logged-in, consent-granted, ad-blocker-free browser. Real verification means three checks:
- Network tab: watch the actual requests leave the browser, with the parameters you expect, on the environment your customers use.
- Independent totals: compare purchase events against your shop or CRM order count for the same window. The gap is your measurement error, and you should know its size.
- Consent states: repeat the check with consent declined. What still fires is your compliance exposure.
The full procedure is in how to check if your GA4 tracking actually works.
What order should an implementation follow?
- Measurement plan: which business questions, which events answer them. Ten well-chosen events beat sixty accidental ones.
- dataLayer specification: the contract document. Event names, parameters, types, example payloads.
- Naming convention: pick one, write it down, enforce it in review. Steal mine if you want: a sane GA4 event naming convention.
- Implementation: developers push to the dataLayer, GTM maps dataLayer to tools. No tag reads the DOM directly unless there is no alternative.
- Verification: network-level QA, consent-state QA, totals reconciliation.
- Documentation and handover: the spec lives somewhere findable, with an owner.
Skipping to step 4 is the industry default. It is also why the industry default is broken tracking.
Patch or rebuild?
Patch when the container is documented, the naming is mostly consistent, and the problems are localized. Rebuild when nobody can say what half the tags do, when names collide, or when you are about to spend serious ad budget on top of numbers nobody has verified. A rebuild sounds expensive until you price the decisions being made on corrupted data every week.
If you are not sure which side you are on, that uncertainty is itself the answer to a different question: nobody currently owns your tracking. Start there. An audit that maps what actually fires, against what should, is a few days of work and usually settles the patch-or-rebuild question on evidence instead of mood.