The symptom

The release went out on Thursday. Nothing about it looked risky, a cleaner checkout step, a tidied contact form, a component library upgrade. The site works. Orders arrive, the sales inbox fills up, nobody files a bug.

Then the numbers drift. Conversions in one client account sit lower than the week before, not low enough to be obviously broken. Google Ads reports fewer conversions than the client's own back office. A funnel step that used to convert now shows almost nothing, so the CRO test on top of it produces results nobody can defend.

Two weeks later somebody builds the monthly report and the dip is undeniable. By then you are explaining a number instead of fixing a tag, and the client has already drawn their own conclusion about what last month's campaigns did.

Why it happens

Because a tracking setup is not self-contained. It is a standing agreement with the website about details the website is entitled to change, and a release is when they change. Nobody edits the tracking to break it. The release moves the ground it stands on.

Four kinds of dependency account for most of it.

Triggers keyed to a location

The classic one. A conversion fires on a confirmation URL, the release renames the route or swaps the redirect for an in-page success message, and the trigger's condition is never true again. The visitor still sees a confirmation, which is why walking the journey by hand passes while the measurement of it does not.

Triggers keyed to the markup

Anything watching an element on the page is coupled to how that page is built. Tag Manager Help is explicit that the element visibility trigger either "selects a single element based on the value of an element's ID attribute" or "selects one or more elements based on a specified CSS selector pattern". A component rewrite that changes an id or a class name is invisible to the developer shipping it and decisive for that trigger. Anything reading text out of the page has the same problem.

The navigation model

Move a site to client-side routing and the definition of a page view shifts underneath you. GA4's enhanced measurement has a setting for it, and Google Analytics Help documents what it watches: "this measurement option listens for pushState, popState, and replaceState". Whether that setting is on, and whether the site fires its own page view too, decides between page views disappearing and page views doubling. Both are wrong, and doubled is worse, because it looks like growth.

Delivery and load order

These two rarely get connected to marketing data. A release that introduces or tightens a Content Security Policy decides which scripts may run at all, and MDN is blunt about anything outside the allowlist: it "is blocked and won't be loaded or executed". Consent is the other. Google's consent mode documentation states that "by default, no consent mode values are set", that the default command has to run "before any commands that send measurement data", and that asynchronous consent platforms need an explicit wait. Change the order scripts load in, defer the banner, or swap the consent platform in the same release, and tags that used to see a decision now see something else.

A fifth class is smaller: GA4 caps most event parameter values at 100 characters and event names at 40, so a release that renames things can cross a line nobody knew was there.

And why nobody catches it in time

None of this errors. That is the whole problem. A trigger that never matches does not log a failure, it simply does not fire, and a metric that stopped arriving looks identical to a metric that went down.

The two release trains also have separate owners and separate histories. Per Tag Manager's own documentation, "Tag Manager maintains its own version history", and that history holds no record of the website deploy that changed its assumptions. Open the container after a bad release and it looks untouched, because it is.

Testing afterwards helps less than people expect. GA4's DebugView shows events collected from a device where debug mode is enabled, so what you verify is the path you thought to walk, on the browser you happened to use, with the consent choice you gave. Breaks prefer the flow nobody tested.

And the feedback loop is slower than the release cadence. Google's data freshness table puts intraday processing for a standard property at 2 to 6 hours and daily processing at 12 hours, and notes report data can keep shifting for 24 to 48 hours. Ship on Thursday and the first solid read lands when nobody is looking at it. Meanwhile the baseline you compare against was never whole, 15-30% of conversions are consistently uncaptured before any release goes out, so a fresh gap has existing noise to hide in. Where that share goes is the subject of why conversions never reach GA4.

What good looks like

The answer is not a longer checklist, since a checklist run from memory only covers the breakages you have already lived through. Three things change the outcome.

First, write the dependencies down. Every client setup makes a short list of assumptions about the site: which URLs matter, which ids and selectors are load-bearing, which data layer keys the site pushes, what the consent bootstrap looks like, which hosts may run scripts. That list is what a release gets checked against, and it takes an afternoon per client to produce. Without it, "did this release affect tracking" is unanswerable, which is why it gets answered with a shrug.

Second, put tracking in the release path. Not a gate that slows the developers down, just the release note reaching whoever owns the container before it ships rather than after the client asks a question. Most breaks here are cheap to prevent once somebody who knows the setup reads the change list.

Third, detect independently of the release calendar, because plenty of releases are never announced. That is what Archon Alert does: it learns what normal looks like per client and per metric, then flags a genuine break rather than a threshold crossing, so a release-day drop reaches you as an alert instead of arriving as a question from the client. Getting that sensitivity right is its own discipline, which is why tracking alerts fire on noise and get muted.

Detection matters more the better the underlying setup is. In the performance agency case, recovering the 38% of client traffic affected by tracking prevention produced a 26% average uplift in measured conversions and saved 14 hours per project. That work decays quietly. One unwatched release can hand a client account back to where it started while the dashboards keep rendering.

FAQ

Our developers say they never touched the tracking code

They are almost certainly right, and it changes nothing. The container was not edited, its assumptions were. A renamed route, a rebuilt component with different ids, a stricter script policy, a deferred consent banner, none of that is tracking work and all of it changes what the tracking sees.

Can we not just test after every release?

Testing is worth doing and will not carry this alone. You test the journeys you think of, on your own browser, and DebugView only surfaces devices where debug mode is on. Use the written dependency list to decide what to test, and keep independent detection for what the test missed.

Does server-side tracking make this go away?

Partly, and it depends on which dependency broke. Moving collection server-side shrinks the surface exposed to client-side blocking and browser storage limits, and gives you one place to correct a payload instead of many tags. It does nothing for a trigger that no longer matches, because the event still starts on the website. The agreement between site and tracking survives any architecture change.

How quickly should we find out?

Before the client does, which in practice means the same day. The data lands within hours, so the constraint is not the platform, it is whether anything is watching the arrival. Month-end reporting is not a detection method, it is an explanation method.

Who should own this, the developers or us?

Somebody by name, which is the part usually missing. Developers cannot own an outcome invisible in their tooling, and an agency cannot own a release calendar it is not on. The workable split is that releases get announced and the tracking owner reads them, with monitoring underneath for the ones nobody announces.

If you want to know which parts of your clients' tracking rest on assumptions the next release can move, a free tracking audit maps it per account and shows what a break there costs.