Tracking breaks silently. Nothing errors, the site works, and the first sign is a chart that looks wrong days or weeks later. The fastest way to tell a broken tag from a real change in traffic is to stop reading reports and look at what the browser actually sends. This page is that check, in the order that finds the cause soonest.
Tracking problem or real drop? Ask this first
A real change in traffic or conversions moves gradually and shows up in other sources too. A tracking failure is a step: one day normal, next day a fraction, and other sources disagree with it.
| sign | points to |
|---|---|
| The drop begins on the day of a deploy, theme update, plugin update, tag-manager publish, consent-banner change or migration | tracking |
| Search Console clicks, ad-platform clicks or server logs stay flat while analytics falls | tracking |
| Only one report family falls (conversions but not sessions, or one device type, or one page template) | tracking |
| Everything falls together, and the ad platforms and Search Console fall with it | real |
| The drop is seasonal, or matches a campaign ending | real |
If the first three rows describe you, treat it as a measurement incident until proven otherwise, and continue.
What changed on the site the day it broke?
List every change in the 48 hours before the step: deployments, theme or plugin updates, tag-manager container versions, consent-banner or consent-mode settings, DNS or CDN changes, a new checkout or booking domain, a redirect. Nine times out of ten the cause is on that list. Tags live in templates, in the tag manager and in third-party scripts, and any of them can be replaced in a release without anyone noticing that the analytics snippet went with it.
Is the tag still on the page, on every template?
Open the affected page types in a fresh browser profile, with DevTools → Network open and Preserve log ticked. Load the homepage, a content page, a product or service page, and the page where conversions happen.
- No request to the analytics endpoint at all → the snippet or the tag-manager container is gone from that template. Common after a theme update or a plugin that "manages" scripts.
- The container loads but no analytics request follows → the tag is in the container but its trigger no longer matches, or a consent check is blocking it. See the next two sections.
- The request goes out with a different measurement or container id than you expect → a staging id, an old property, or a second install. Compare the id in the request with the one your reports read from.
- It fires on some templates and not others → a template-level omission, common on checkout, landing-page builders and sub-domains.
Did the consent banner start blocking everything?
A consent change is the most frequent hidden cause. If the banner, its defaults or its consent-mode settings changed, tags may now wait for a signal that never comes, or fire only for the minority who click Accept. Test it the way a visitor experiences it: fresh profile, load the page, click Accept, watch for the analytics request; then repeat with Reject. If nothing fires even after Accept, the wiring between banner and tags is broken. If everything fires only after Accept and your accept rate is low, your reports are showing that minority, and the "drop" is the day enforcement started working. That is not a bug, but it is a change you need to know about.
Does the tag fire, but the data never arrives?
The tag manager's preview can say a tag fired while nothing reaches the report. Look at the network request rather than the tag manager:
- The request is sent but returns an error → wrong endpoint, a blocked domain, or a server-side tagging endpoint that stopped forwarding.
- The request is sent to the wrong property → an id mismatch, as above.
- The event name or parameters changed → a renamed dataLayer event or a case change (
Purchaseis notpurchase) means the tag fires with a name the reports do not recognise. - Two requests go out for one action → duplicate tags. The chart goes up, not down, but the data is just as wrong.
- Requests only go out after a click, never on load → the page-view trigger broke while event triggers survived.
Did a cross-domain step break?
If conversions happen on a different domain — a checkout, a booking engine, a payment page — check that the analytics id is the same on both sides and that links into it carry the cross-domain linker (this last check is a manual one: look for the _gl parameter on the outbound link). A missing linker shows up as a fall in attributed conversions and a rise in "direct" or self-referred traffic on the same day. The payment or booking domain appearing as a referrer in your reports is the tell.
How do I confirm the fix?
Repeat the same network check after the fix, on the same templates, in a fresh profile, with Accept and with Reject. Keep the before and after. A scan of the site before a release and another after it is the cheapest regression test tracking can have, and it is the one most teams never run. Running TagAudit's free scan before and after a release gives you the two readings to compare, without access to the tag manager or the analytics property.
What this check can and cannot find
The check above, and a TagAudit scan, work from outside: they see what the browser sends. That decides what they can diagnose.
| can find | cannot find |
|---|---|
| Tag missing on some templates and present on others | Attribution model differences between platforms |
| Two copies of a tag, or two page views per load | Sampling, thresholding, reporting identity or data-retention settings |
| A different measurement or container id across pages or domains | Unpublished tag-manager workspaces |
| What fires on a visit where the cookie banner is declined, or left unanswered where there is no reject control | Whether your order count matches the store's database |
| Which of scroll, click and form-fill produce a request at all | Modeled or imported conversions, or bot traffic inside the reports |
| Anything a form submission, add-to-cart or checkout step would send — those actions are switched off in our current configuration, on every site |
How often should tracking be checked?
At every release that touches templates, the tag manager, plugins or the consent banner; after every migration; and once a quarter regardless. Tags are added far more often than they are reviewed, and the person adding one rarely knows what else is on the page. TagAudit today is a one-off scan you run when you want it; scheduled re-scans are not something we offer.
FAQ
GA4 shows zero for one day and then recovers. Broken? Possibly a reporting delay rather than a tag; check the following day. A one-day gap that coincides with a deploy and recovers on a rollback is a tag.
The tag manager preview says the tag fired. Why is there no data? Preview shows the tag manager's decision, not the network result. Read the request itself: its destination, its id, its status and its event name.
My traffic halved the day we changed the cookie banner. Which is wrong, before or after? Neither, necessarily. Before, you may have been measuring everyone regardless of consent; after, only those who accept. Test both paths with a fresh profile to see which one is true now.
Can I run this on a client's site before I have access? Yes. Everything above works from the browser, and the free scan needs only a public URL.