A tracking setup is correct on the day it ships and then it starts to rot. Not because anyone did anything malicious, but because a website is a living thing and the tracking was wired to a particular version of it. Here are the seven ordinary events that break tracking most often, roughly in order of how often we see them in public audits.
1. A theme or template update
The install snippet lived in the theme's header file. The theme updated, the header file was replaced, and the snippet went with it. This is the single most common way a site loses GA4 entirely. The site looks fine, the store takes orders, and the analytics property quietly flatlines.
2. An app or plugin that brings its own pixel
Every ecommerce app that touches checkout wants to "help with tracking". Install a reviews app, a bundle app or an upsell app and you may get a second Meta Pixel or a second GA4 tag injected on checkout. Now purchases are counted twice on some pages and once on others, and the ad platforms learn to bid on inflated numbers.
3. A consent banner change
A new consent management platform, or a changed category mapping on the old one, and tags that used to fire for everyone now fire for nobody in the EU, or the other way round. Consent Mode v2 signals can also be lost in the swap, which degrades Google Ads modelling without any visible error.
4. A checkout change
Express checkouts, a new payment provider, a redesigned thank-you page. The purchase event was listening for a page URL or a dataLayer push that no longer happens on the new flow. The classic case is Shop Pay on Shopify: the purchase completes on a different path and the old thank-you-page trigger never sees it.
5. A dataLayer rename
A developer tidies up the dataLayer and renames transactionTotal to value, as the GA4 spec recommends. The GTM variable still reads the old key. The purchase event now arrives with no revenue attached. Event counts look healthy; revenue reports read zero.
6. A migration to a new site
Everything above, all at once. Migrations are where tracking most often ends up copied from a screenshot rather than re-implemented, and where IDs from a staging property sneak into production.
7. A quiet GTM change by someone with access
A marketer pauses a tag "for a test". A contractor publishes a workspace that was meant to stay unpublished. There is no alert when a container changes, so the first sign is a reporting gap weeks later.
Why nobody notices
All seven have the same property: the website keeps working. Orders are placed, pages load, nothing throws an error. The only thing that changes is a number in a dashboard somebody checks weekly at best, and the first instinct when that number drops is to blame the market, the campaign or the season.
What actually prevents it
- A tracking plan. A written statement of which events should fire, with which fields, on which pages. Without one, nobody can say what "broken" means.
- Continuous comparison. Something that checks the live site against the plan every day, not a quarterly manual audit.
- Baselines per event. A 20 percent drop in purchase against its own baseline is a page; a 20 percent drop in total events is noise.
- Revenue reconciliation. Compare tracked revenue against the order system daily. The two will never match exactly, but a gap that opens on a particular day points straight at the cause.
FAQ
How often does tracking break on a typical site?
In the public audit corpus, most sites that score well on one audit and poorly on a later one changed something in between: a theme, an app or a consent tool. A few times a year is normal for an actively maintained store.
Does server-side tagging stop tracking from decaying?
It moves some of the risk, it does not remove it. The browser still has to send the server container the right events, and a theme update can still delete that snippet. Server-side forwarding does protect you from ad blockers and cookie limits, which is a different problem.
What is the fastest way to find out whether my tracking has decayed?
Audit the live site and compare against what you believe is installed. The free audit at tageasy.io/check reports what the page actually loads, including on a second page past the homepage, which is where theme-level breakage shows first.