Measurement Truths · No. 8

Installed is not the same as working: a ten minute analytics check

A tracking tag in your page source proves it was installed. It does not prove your analytics property ever recorded a visit, and here is the short check that tells you which one you have.

A flat illustration of a magnifying glass beside a stopwatch without numerals, in charcoal linework on a warm white background.

Open the page, view source, and there it is: the tracking snippet, sitting in the head, carrying the right ID. That looks like the job is done. We built a check that tests for exactly that one thing, a string in a page's source, and nothing else. It passes every time someone pastes the snippet correctly, and it has nothing to say about whether the property behind that ID ever recorded a single visit.

The gap decides whether any report you read means something. Every dollar spent on ads and every hour spent writing a page meant to rank gets judged against a report pulled from that property. A property collecting nothing cannot judge any of it, no matter how carefully the report itself is built. The fix means watching the browser, not the source.

To check if Google Analytics is working, load the page with the network panel open, watch your own visit land in the real time report, then confirm it in the standard report a day or two later.

The short answer

  • A tag in your page source proves it was installed, nothing about whether it works.
  • Three quick checks from your browser prove whether data is landing in the property.
  • A presence check can also miss a second copy of the tag hiding inside a tag manager container.

Why a tag in the source proves nothing

A build check that scans a deployed page for the right analytics ID proves exactly one thing: the string is there. Ours does that and stops. It never opens a browser, never fires a request, and never asks the analytics property whether it received anything. A page can pass that scan on the same day its property has been silently empty for a month.

There are a handful of reasons a string can be perfect and a property can still be quiet. A consent banner can block the request until someone clicks accept, and in the stricter setup a quick test visit that never clicks accept sends nothing at all. Run the test in a private window with extensions off. A blocker on your own machine hides the very request you are looking for.

A string in the page source is a receipt, not a pulse.

A tag manager container can also hold a version with the right ID that was saved but never published, so the code sits there, correct and inert. None of these show up in a scan of the page's source. They only show up once you watch what the browser does after the page loads, the part a source scan was never built to see.

The three checks you can run in about ten minutes

You do not need developer access. A browser and a login to the property whose reports you read cover all three checks, start to finish. Watch one network request fire when the page loads. Watch that same visit land in a real time report. Then come back a day later and confirm the property still shows it.

The ten minute check

  1. Load the page with the network panel open

    Open developer tools, filter the network tab for the word collect or the word google, then load the page in a private window so old data and browser extensions stay out of the way. You want to see exactly one request fire when the page loads, not zero and not several.

  2. Watch your own visit land in real time

    Open the property's real time report in a second tab and reload the page you just tested. Your visit should show up as an active user within a few minutes. If it never appears, check two things: the ID in the page, and any active internal traffic filter that matches your own connection.

  3. Come back the next day and check the standard report

    Real time only proves the pipe is open right now. Wait a day or two, then look at the standard report for that same page. If your test visit shows up there too, the property is receiving data and keeping it.

A few things can make this check lie to you. Rule them out before you trust the result. Test from a private or incognito window, since a browser extension built to block trackers will block your own test the same way it blocks everyone else's. Give the real time report a few minutes before deciding it failed. A report does not update the instant a request lands, and a check called too early looks the same as one that genuinely failed. Google says reports can take 24 to 48 hours to process, so an empty report on the same day usually just means the data has not caught up yet.

One more case is easy to miss on a modern site built with client side page transitions. A tag can fire correctly on the very first page load and then go quiet on every page after that. The page content swaps without a full reload, and nothing tells the analytics script a new page just appeared. A site does not have to call itself an app to behave this way. Test by clicking through to a second page inside the site instead of only loading the first page directly.

Where one test visit can go missing

From page load to report

  1. Page loads The tag sits in the source A blocker or an unaccepted consent banner can stop it here
  2. Request fires Look for exactly one collect request A wrong ID sends it to a different property
  3. Data filters Applied as data comes in An active internal traffic filter can drop your own visit
  4. Real time report Your visit appears within a few minutes
  5. Standard report Shows the visit a day or two later

One break anywhere leaves the report quiet

Each checkpoint matches one of the checks above. A source scan only sees the first box.

What each result tells you

A failed check rarely means the same thing twice. No request at all means the tag never loaded or something blocked it before it could run. A request with no matching real time hit usually means either the wrong ID is wired into the page or an active data filter removed the visit. Google says the effect of a data filter is permanent: data an exclude filter removes is never processed and never becomes available in Google Analytics, so it will not show up in any report. A real time hit with an empty standard report on the same day usually means processing has not caught up.

Common patterns behind a tag that looks right while its property stays quiet.
What you seeWhat it meansWhere to look next
No network request firesThe tag never loaded, or something blocked it before it could runCheck consent settings and any ad or privacy blocker on your test browser
A request fires but real time stays emptyA wrong measurement ID, or an active filter dropping your own visitCompare the IDs, then check internal traffic filters for your connection
Real time works, the standard report is empty the same dayProcessing has not caught up yetCheck the standard report again in a day or two

A stale internal traffic filter survives a redesign because nobody re-checks old settings once only the pages and the design change. The wrong ID follows a copied template because the snippet still looks right sitting in the page, even when it points at the wrong property. A blocked request is the one you cannot fix from your side alone, since it depends entirely on a visitor's own browser choices and privacy settings. Google Ads has a similar list to keep tidy, and the IP exclusion list has a ceiling worth knowing before you fill it.

The check a source scan will never catch

A presence check confirms the right analytics ID sits in the page. It says nothing about a second copy of that tag, or a different tool entirely, pasted into a tag manager container weeks or months later by someone else. A second copy of the same analytics tag on one page double counts some events, and the affected counts cannot be trusted until the duplicate is removed.

This is the gap a build check cannot close by scanning harder. The extra tag is not wrong. It is just unexpected. To a machine reading the page it looks like any other tag. It takes a person, on a schedule, opening the container and reading what is inside it. List every tag inside it and match each one against what the build check expects to find.

A duplicate usually arrives like this: a well meaning teammate or a new agency adds a tag through the container's own interface, not realizing an identical one is already built into the page itself. The person adding it has no reason to think anything is wrong, which is exactly why a scheduled look is the only thing that catches it. We explained why we keep those two tools out of the container in permanent analytics belongs in the code.

Make this a standing habit

A quick check like this one is worth little if you only run it once, at launch. Templates get swapped during a redesign, and a tag manager container gets edited by more than one person over time. A tag rarely announces its own failure. Treat a quiet property as a reason to stop trusting a report and start checking it again.

What this check touches

None of this replaces a second set of eyes when the numbers still do not add up after every check above comes back clean. When the wiring itself turns out to be the problem, tracking setup like this is part of what our technical SEO work covers, especially on a site that has changed hands or agencies more than once. When the pipe is fixed but paid traffic still is not converting the way the spend suggests it should, that is a question our Google Ads work looks at next.

If you want help closing the gap, get in touch.

Run the ten minute check

Ready to ship

Talk to Offer before you decide anything.

You'll talk with Offer, not a sales rep. A short call, no pitch deck.

Talk to Offer

This post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.

Related Articles

Want to talk through your marketing?

Tell us where things stand and we'll tell you plainly what we'd do next.