'You have no analytics' is a claim about a list
An audit reports that analytics is missing from most of your pages. It sounds like a statement about your data. It is not — it is a statement about which tag names were on a list, and which of those appeared in the HTML that was fetched. Those are very different claims, and the gap between them has produced two instructive mistakes.
The number with no evidence under it
On one large site, across hundreds of crawled pages, the only analytics-family tag found anywhere in the served HTML was a single session-recording tool, on one page. The finding said analytics was missing from almost every page.
Read that sentence as an owner. It describes a deployment with gaps — some pages tagged, some not, sessions breaking as visitors cross the boundary, traffic landing in the wrong bucket. That is a real and common problem, and it is not this one. What had actually been measured was one stray tag and no analytics at all.
Those two situations have nothing in common. One is "your tagging is inconsistent, find the templates that miss it". The other is "you are not measuring anything, choose a tool". A reader given the first description will go looking for a gap that does not exist.
The repair was to name the tools. "This tool appears on one page of the crawl, and no other analytics tag was found anywhere" is checkable in ten seconds. "Analytics is missing from most of your pages" is a number with no evidence under it — and a reader cannot audit a percentage.
Testing one name when the question was about a category
The second case is sharper, because the information needed to avoid it was already in the file.
A job board carried a genuine tag for a retired analytics product, with a real property identifier, and none of that product's replacement. The audit told it, at high severity, that only the retired tag was installed and that it had therefore had no data since the retirement date.
The site also carried a modern product-analytics tool, and a tag manager. It had been collecting data the whole time.
The branch had tested for one replacement product by name. The list of every analytics tool the check knows about was defined at the top of the same file and used by the check immediately above it. The most common way a check goes wrong is asking about a name when the question is about a category — and the giveaway is a finding that mentions one product where your situation involves another.
Why a tag manager changes what can be claimed
Worth its own section because it is the honest limit, and it cuts both ways.
A tag container collects nothing by itself. Its presence is not evidence that you have analytics. But it can load an analytics tag at runtime, where a static fetch of the HTML cannot see it — so its presence is evidence that absence cannot be concluded.
That is the whole of it: a container turns "you have no analytics" into "this tool could not tell". A report that says the first when the second is true has overstated what it looked at, and any audit reading served HTML rather than running the page is in that position by construction.
Reading an analytics finding on your own report
- Does it name the tools it found? If not, that is the first thing to distrust. A list of what was present and where is the evidence; a coverage percentage is a summary of it.
- Does the count match the URLs shown? A claim about most of your pages should be accompanied by the pages.
- Is a tag container present? If so, treat any "no analytics" claim as unverified rather than false, and check what the container is configured to load.
- Open your own dashboard. If it has data for yesterday, the finding is about what a fetcher could see, not about whether you are measuring.
When the finding is real and worth acting on
Two shapes deserve immediate attention, and neither is about the tool's name:
- A money page with no tag while the rest of the site has one. This is the genuine deployment gap, and it is usually one template — a checkout, a thank-you page, a landing page built outside the main site.
- A funnel tagged inconsistently. One missing step in a sequence of four does not cost a quarter of your visibility into it; it can cost the attribution for the whole path.
The fixes that make it worse
- Installing a second analytics product to clear a finding. You now have two sources of truth that will disagree, and a slower site, because a report did not recognise the one you had.
- Removing a retired tag before the replacement is verified. The retired tag may be the only thing still collecting. Confirm the new one is receiving data first.
- Adding tags to pages that already report through a container. Double-counting is harder to notice than under-counting and corrupts every comparison you make afterwards.
How to pass this check without measuring anything
Put a tag container on every page. Every page now carries something an audit recognises as analytics infrastructure, the coverage number goes to full, and the container can be configured to load nothing at all.
Which is the argument for the whole page: a tag in the HTML is evidence that a tag is in the HTML. Whether anything is being recorded, whether it reaches a report you read, whether the numbers are right — none of that is visible from outside, and an audit that implies otherwise is selling you a conclusion it did not reach.
Where this sits in an audit
The registered check is mar.analytics, which covers whether analytics is installed.
For the tracking lane as a whole — what the six checks look for, what was found across real sites,
and what the lane deliberately does not do — see
the marketing tag audit →.
For the related habit of reading what a finding actually counted, see a finding's count is not decoration →.
Common questions
My audit says I have no analytics but my dashboard has data. Why?
Because it read the served HTML and looked for known tag names. If your tags load through a container at runtime, or your tool is not on its list, a static fetch cannot see them.
Does a tag manager mean I have analytics installed?
No. A container collects nothing by itself. What it does mean is that absence cannot be concluded, because it can load a tag where a static fetch cannot see it.
Why did my audit only mention one analytics product?
Some checks test for a specific product by name rather than for the category. If the finding names a tool you do not use and ignores the one you do, that is the failure.
Is 'analytics missing from most pages' the same as having no analytics?
No, and the two need opposite work. Missing from some pages is a deployment gap in a template; missing everywhere means nothing is being measured at all.
Should I add a second analytics tool to clear the finding?
No. You would gain two sources of truth that disagree and a slower site, because a report did not recognise the one you already had.