Understand analytics and tag checks

Learn which measurement packages TechDash detects and which changes open incidents.

Last checked 21 August 2026

TechDash monitors SEO analytics and tag-management packages on each monitored page. Missing analytics is not a direct search-ranking failure, but it can break organic reporting, attribution, consent behavior, release measurement, and campaign diagnosis. A pass can mean stable packages, baseline stored, or still unrecognized. It does not prove that every tag fired for every visitor or that dashboards remain complete.

What TechDash detects

Detection combines bounded raw HTML, rendered DOM, script URLs, inline JavaScript snippets, iframe and image sources, and up to 400 observed crawl network requests. Low-confidence matches are discarded. TechDash does not use CSS class names as evidence for Google measurement IDs.

Supported packages include Google Analytics (v4), Universal Analytics, Google Tag Manager, Adobe Analytics, Fathom, Simple Analytics, Plausible, Matomo, Piwik PRO, Cloudflare Web Analytics, Microsoft Clarity, Hotjar, Yandex Metrica, Jetpack Stats, Snowplow, FullStory, Mixpanel, Heap, Amplitude, and New Relic Browser.

Where possible, the snapshot records a vendor and property or container ID. For Google, IDs are normalized and must match valid G-, UA-, or GTM- patterns. Google Ads, Floodlight, Meta Pixel, TikTok Pixel, LinkedIn Insight, Microsoft Advertising, and other paid-media tags are intentionally outside this check.

Analytics tags removed

Analytics tags removed is Warning because a page that previously had recognized measurement now has none. Organic traffic may continue, but you lose reliable proof of performance, conversion, and experiment outcomes.

A fail means the previous baseline contained one or more recognized analytics tokens and the current crawl contains none. A pass means recognized packages remain present, the page never had a recognized package, or the first successful observation is still establishing the useful baseline. The current check does not open this incident when tags appear on a page that previously had no recognized package. It records that state as stable. Site Resources coverage can still show the newly detected package.

Evidence summarizes the previous vendor and ID set and the current empty state. If Google Tag Manager remains while Google Analytics disappears, that is treated as a change rather than a full removal, and the evidence calls that out specifically. A container being present does not prove that its analytics tag fired.

Likely repercussions include broken organic reporting, split or missing conversion history, silent measurement loss after a release, and delayed discovery of consent or Content Security Policy regressions. A deliberate removal can be benign when the page should no longer load analytics, but confirm that decision with the analytics owner before treating the Warning as noise.

Restore the intended container or property in the theme, tag manager, or consent setup. Confirm the tag loads and, where possible, sends a collection request in a normal browser. Then use Check & Verify on the page. Recovery means the Warning no longer appears and the recognized package summary returns, not that every historical dashboard series is repaired.

Analytics tags changed

Analytics tags changed is Advisory because the page still has recognized measurement, but the vendor set or normalized IDs differ from the baseline. Severity is lower than full removal because reporting may continue, yet history can become hard to compare.

A fail means both the previous and current observations contain recognized tokens and their normalized summaries differ. A pass means the recognized set is unchanged, only one side has tokens so removal or first detection applies instead, or the baseline is still being stored. Evidence shows previous and current vendor and ID summaries.

Likely repercussions include accidental production-to-staging ID swaps, split historical reporting, duplicated or orphaned properties, and consent mappings that no longer match the live container. Intentional migrations, property consolidations, and planned vendor replacements are common benign cases.

Confirm the new property or container with the analytics owner. Update dashboards, alerts, and consent mappings if the change was intentional. If it was accidental, restore the previous production IDs. Use Check & Verify after publication. Recovery means the Advisory clears or you accept the new baseline after verifying the intended IDs. An unchanged pass after acceptance means the new set is stable, not that the migration was complete.

Deliberate false-positive controls

A bare gtag('config') call is not enough to count as Google Analytics. TechDash also requires evidence such as loading googletagmanager.com/gtag/js or sending a request to a Google Analytics collection endpoint. This avoids counting copied snippets, documentation, or inert configuration.

A vendor name in ordinary page text is weak evidence. Detection prioritizes scripts, initialization patterns, IDs, and network activity. Consent tools, regional rules, browser blocking, delayed tag-manager triggers, and interaction-only tags can still change what the TechDash crawl observes. Those limitations can look like removals or changes even when a human visitor later loads the tag.

Sitewide coverage

The Site Resources card aggregates recognized packages across checked Monitored Pages and shows each package's percentage coverage. Coverage is calculated from the available page snapshots, so it only represents the monitored set. It does not prove that every page on the public website carries the tag, and it is not itself an incident.

A package shown at 50% may be correct if only half the monitored pages should load it, or it may reveal a template or consent problem. Compare pages by template and intended measurement policy before treating less than 100% as a failure. Coverage can improve when a previously empty page gains a package even though no removal or change incident opens.

What to do and how to verify

For Analytics tags removed, inspect the current page in a normal browser and its network requests. Check recent theme or tag-manager releases, consent settings, container publication, CSP, regional conditions, and whether the property moved to a new ID. A tag visible in source but blocked from loading can produce different evidence from a tag that actually sends a request.

For Analytics tags changed, confirm the new property or container with the analytics owner before restoring or accepting it. Accidental production-to-staging ID swaps can split reporting history. If the change was an intentional migration, confirm dashboards and consent mappings before marking the incident resolved.

After correcting the implementation:

  1. Open the page in TechDash.
  2. Select Check & Verify or Run now.
  3. Confirm the page-level analytics result returns to pass or matches the accepted new baseline.
  4. Review Site Resources coverage if several templates should share the same package.
  5. Leave the incident open until the intended measurement policy is restored or intentionally accepted.

If the tag only fires after an interaction or consent action that the crawl does not perform, document that limitation and judge the coverage result accordingly. Use a custom check when you need to enforce one exact ID in a specific page location. If repeated restored tags still fail while a normal browser shows the correct package, collect the page URL, previous and current evidence, consent state, and recent release notes, then open Help & Support.

Related articles