toolkit

Scenario · Something looks broken

The analytics numbers look wrong

“Traffic dropped off a cliff last month.” Or: “These conversion numbers can't be right.” Or: “Is Hotjar or Clarity installed, and is either loading twice?”

When traffic or conversions look wrong, the pressure is to explain a business decline — but the numbers might just be broken. This checks whether the site is actually being measured correctly before anyone tries to explain a drop that measurement itself may have caused: a missing tag, a duplicated one, or a consent banner blocking data before it's collected. Telling a real decline apart from a broken measurement pipeline is the whole job, and getting the order backwards wastes the investigation.

What to ask for

Analytics & tagsAnalytics & tag presence audit — reads a page's delivered HTML and inventories the measurement, advertising and session-replay tags firing on it: Google Tag Manager, GA4, legacy Universal Analytics, Google Ads, Meta Pixel, LinkedIn, TikTok, Microsoft Ads, Pinterest, Clarity, Hotjar, Segment, Matomo.GTM audit and fixUnified Google Tag Manager audit-and-fix workflow.GA4 behaviour seriesOptional integration — reads the GA4 Data API and writes the behaviour series, the sibling to Search Console series.Search Console seriesOptional integration — reads Search Console's Search Analytics API and writes the data series nothing else has.

See it work

A real run of Analytics & tags:

FAIL — 1 page(s)
      tags: Universal Analytics (legacy) (UA-12345-1) — legacy
      [error] legacy Universal Analytics present (UA-12345-1) — UA stopped processing data in July 2023; this tag is dead weight
      [warn] no analytics or tag manager detected — is this page being measured?

  playbook: local fallback

  report: ./out/analytics-and-tags-analytics-and-tags.html
  text:   ./out/analytics-and-tags-analytics-and-tags.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

Mostly raised internally, and the first thing to establish is which of two completely different problems this is: the site stopped being measured correctly, or the site genuinely got less traffic. Working the wrong one wastes the month.

  1. Find out what changed on the site, and when. Against the date the numbers moved. A redesign, a migration, a consent banner, a tag manager republish, or a plugin update are all capable of breaking measurement on a specific day, and the date is the strongest evidence available.
  2. Audit what is actually firing on the page. The analytics and tag audit inventories the measurement and advertising tags on the delivered page and grades the classic faults: a container missing on some pages, a duplicated GA4 tag double-counting, legacy Universal Analytics still present, a tag that stopped being present at all. A site-wide gap where one template lost its tag is the single most common cause of a cliff-edge drop.
  3. Look inside the tag manager container. The container audit shows every tag, trigger and variable it publishes, which is where a paused tag or a trigger that stopped matching becomes visible. The page audit in step 2 sees what fired; this sees what was supposed to.
  4. Pull the data series and look at the shape. The analytics series and the Search Console series together separate the cases: traffic down with impressions steady is usually a measurement fault; both down together is usually real. A drop that starts exactly at midnight on one day is a deployment; a drop over three weeks is a market.
  5. Check consent and geography. A consent banner that started blocking analytics before consent, or a change in how it categorises, reduces measured traffic without reducing traffic. This is a measurement fault that looks exactly like a business decline.
  6. [manual] Fix what step 2 or 3 found, then re-verify. A missing tag goes back in the template or the container; a duplicate gets removed. Then re-run the page audit to confirm one of each tag fires, and note that historic data does not backfill — the gap stays in the record.
  7. Report the conclusion as one of the two. “Measurement was broken from this date and is now fixed”, or “measurement is sound and the decline is real”. Anything vaguer sends the ticket back.

Both charts drop, only one is your problem

The reason this needs a written procedure is that the pressure on receipt is to explain the decline, and explaining requires assuming the numbers are true. Steps 2 and 3 are cheap and answer that assumption first, which is the opposite of the instinct.

What this does not cover

Whether the numbers are wrong or the business is. A measurement fault and a real decline produce the same chart, and separating them is the entire job — but nothing here can tell you the practice simply had a quieter month, lost a referrer, or stopped running ads. It reads what is measuring the site and what the data says; the causal question stays with whoever knows what changed off the website.

← All scenarios