What do you do if analytics stops reporting?
Check sources that do not depend on your tracking code before concluding anything — server logs, Search Console, business profile insights, and whether the phone is ringing normally. Broken tracking is far more common than a real traffic collapse, and the usual cause is the tag being removed in a deployment.
Confirm whether it is measurement or reality
Check sources that do not depend on your analytics:
- Server logs. They record every request regardless of any script. If traffic is present in the logs and absent from analytics, the tracking is broken.
- Search Console. Independent of your site's tracking code.
- Your business profile insights. Also independent.
- Actual enquiries and calls. The most reliable signal of all. If the phone is ringing normally, traffic did not collapse.
That comparison answers the question in ten minutes and it prevents an expensive overreaction.
The usual causes
The tag was removed in a deployment. The most common cause by a distance. A theme update, a rebuild, or a template change removes the tracking code and nobody notices because nothing visibly breaks.
A consent banner blocking it. Configuration changes to consent handling can block tracking for most visitors. Whether that is correct depends on your obligations, which is a question for your own adviser — but it produces a sudden drop that looks like lost traffic.
A tag manager container change. A published change that broke or removed a tag.
Property or configuration change. A filter added, a data stream misconfigured, or the wrong property being viewed.
Ad and tracking blockers. These affect a share of visitors continuously rather than suddenly, so they explain a persistent undercount, not an overnight drop.
A platform migration where the tracking was never re-added.
Diagnose it directly
Open the site and check:
- View source and search for the tracking identifier — is it present?
- Open the network panel and confirm the tracking request fires on page load
- Check the real-time report while browsing your own site
- Test with any browser extensions disabled
- Test on a page type that is not the homepage — often the tag survives on one template and not another
That last point catches a common partial failure where the homepage reports and service pages do not.
Fix and then verify properly
After fixing, confirm in the real-time report from a device on a different network, and check that events — form submissions, phone taps — are recording as well as page views. Page views returning does not mean conversions are.
Do not delete the gap
Annotate the period rather than trying to reconstruct it. Anyone comparing year-on-year later will otherwise draw wrong conclusions from a hole in the data.
Reduce the dependence
Analytics is one measurement, and businesses that rely on it alone are blind whenever it fails. Better arrangements:
- Call tracking, which measures the outcome that actually matters
- Enquiries stored in a database, not only counted in analytics
- Search Console reviewed monthly
- A simple record of enquiries and jobs by source, kept independently
A business that knows how many enquiries it received and where they came from does not depend on any script for its most important number.
Add a check to deployments
After every release, load the site and confirm the tracking request fires. Thirty seconds, and it prevents months of missing data — which is the real cost here, since the data cannot be recovered afterwards.
Frequently asked questions
How do I know if it is real?
Check sources independent of your tracking code — server logs, Search Console, business profile insights, and actual calls and enquiries. If the phone is ringing normally, traffic did not collapse.
What causes tracking to stop?
Most often the tag being removed in a deployment, theme update or rebuild. Also consent banner changes, tag manager container changes, property misconfiguration, and migrations where tracking was never re-added.
How do I diagnose it directly?
View source for the tracking identifier, confirm the request fires in the network panel, watch the real-time report while browsing, test with extensions disabled, and test a page type other than the homepage.
What is a common partial failure?
The tag surviving on one template and not another — the homepage reports normally while service pages do not, which produces a partial drop that is easy to misread.
How do I depend on analytics less?
Call tracking, enquiries stored in a database rather than only counted, Search Console reviewed monthly, and an independent record of enquiries and jobs by source.