Tracking monitoring: how to know when your tracking breaks
The short answer: watch the implementation, not just the numbers. Platform alerts and anomaly detection tell you a metric moved. A scheduled check that loads your site and verifies the tags and events tells you why, often before the metric has had time to move.
The goal is simple: shorten the gap between the moment tracking breaks and the moment someone knows.
Tracking that was verified at launch is only verified for launch day. After that, every theme update, app install, consent change and tag manager publish is a chance for it to break, and none of them will tell you when it does.
What breaks tracking
- Theme and template changes that overwrite a customised snippet or rename an element a trigger relied on.
- App and plugin installs that inject a second copy of a tag, or remove one.
- Checkout changes, including platform-driven migrations, that move where the purchase happens.
- Consent banner updates that change what fires before consent.
- Tag manager publishes made outside your normal release process.
- Redirect changes that strip UTM parameters or click IDs.
What they have in common: the site keeps working. That is why the gap between break and discovery is so often measured in weeks.
Your monitoring options, and what each can see
| Method | Catches | Misses |
|---|---|---|
| Platform notifications (e.g. Google Ads conversion status) | A conversion action going quiet | Slow to trigger; doubled or malformed data |
| GA4 custom insights / anomaly detection | Sudden drops in a metric | Why it dropped; low-volume sites; other platforms |
| Dashboards someone checks | Whatever that person notices | Everything on the days nobody looks |
| Scheduled synthetic checks | A tag or event disappearing or changing shape, usually the same day | What the platforms actually did with the data |
| Post-deploy checks in CI | Breaks caused by your own releases, before or straight after they ship | Changes that bypass your pipeline (apps, publishes) |
No single row is enough. The strongest setup combines a metric alert (something moved) with an implementation check (here is what changed).
Setting up the free layers today
- GA4: in Insights, create custom insights that alert you when
purchaseevents or revenue drop sharply day on day. - Google Ads: make sure account notifications reach someone who reads them, and check conversion action statuses weekly.
- Meta: check Events Manager Diagnostics weekly for new warnings.
- A change log: keep a dated list of deploys, app installs and publishes. When a metric moves, the first question is always "what changed that day?".
Want a snapshot of what's installed today, to compare against later? The free AuditTag audit records which tracking tags are detectable on your public pages. Run a free audit →
Adding implementation checks
A monitoring check that tests the implementation re-runs a defined set of tests on a schedule and compares each run with the last good one:
- Are the expected tags still present on the templates that carry revenue?
- Do the ecommerce dataLayer pushes still match their schema?
- Did anything that passed last time fail this time?
The rule that makes this useful rather than noisy: only alert on regressions. An alert that fires every day for a known, accepted issue gets muted, and then the real one is missed too.
How AuditTag handles it
This is what Guardrails is for. It re-runs the same deterministic checks as the free audit on a daily schedule and on demand after a deploy, compares the result with the previous run, and alerts only when something got worse.
What Guardrails checks
- Daily re-audit of each monitored site, diffed against the last run
- Alerts only on regressions, with what changed and where, sent to a webhook (Slack-compatible)
- A post-deploy trigger URL so your pipeline can run a check straight after a release
- dataLayer schema drift, when a captured dataLayer is supplied for the site
What this doesn't prove
Guardrails checks what your site sends, not what the platforms recorded, so keep the platform-side alerts too. It is in early access: the first sites are onboarded and watched hands-on while the self-serve dashboard ships, and some capabilities on the Guardrails page are labelled as roadmap.
Stop finding out from next month's report
Every Guardrails site starts from the free audit. Run it now and see what's detectable on your public pages today, in about a minute.
Run a free audit →Questions people ask
How do I get alerted when my tracking breaks?
Use layers. Turn on the platforms' own notifications (Google Ads flags conversion actions with no recent conversions), set up GA4 custom insights for sudden drops in purchases or revenue, and add a scheduled check that loads your site and verifies the tags and events are still there, so you hear about a break from a test rather than from a report.
Why does tracking break without anyone noticing?
Because a tracking failure does not stop the site working. Pages load, orders go through, dashboards still show numbers. Nothing errors. The only symptom is data that is slightly or completely wrong, and that usually surfaces days or weeks later when someone questions a report.
Is GA4 anomaly detection enough?
It helps, but it only sees what GA4 received. It cannot tell a real drop in sales from a broken tag, it needs volume to spot anomalies, and it says nothing about Meta or Google Ads. It works best alongside a check that tests the implementation directly.
What is marketing observability?
It is applying the monitoring practices software teams use for production systems to marketing data: continuously checking that tracking tags, events and data pipelines behave as expected, and alerting when they change, instead of trusting that a setup verified at launch is still correct.