How the tracking score is calculated

Scored checks

Pass earns the full weight, warn earns half, fail earns nothing. The weights are relative rather than percentages — a site with every check run against it has 145 points available, and the score is the fraction of the available points earned, so 100 means every applicable check passed.

Reported but not scored

Some findings appear on the report card without affecting the number. Either the behaviour they describe is legitimately a judgement call, or the check is new and scoring it now would make fresh scores incomparable with the existing corpus.

• Single GA4 propertyMultiple GA4 IDs on one page are sometimes deliberate (parallel reporting), so this is reported without penalty.
• Consent bannerWhether a consent management platform is detected. Informational — jurisdiction decides whether one is required.
• DataLayer initialisedWhether window.dataLayer is set up in the initial HTML. Common to omit on JS-rendered sites without it being wrong.

How the audit runs

1. 1. Fetch the page. One request, 10-second timeout, 2 MB body cap. Redirects are re-validated at every hop, and requests to private or loopback addresses are refused.
2. 2. Fetch the published GTM container. Modern stores load Meta, TikTok, and Google Ads pixels inside the container rather than as page scripts. Reading the container body is what makes those detectable at all — and it is also what the configuration checks analyse.
3. 3. Render the page headlessly. Sites that ship a near-empty HTML shell and load tracking after hydration are invisible to static scanning. Every outgoing request URL from a real browser load is added to the search corpus.
4. 4. Probe one deeper page. A product or content page linked from the homepage is fetched and checked for the same GA4 property and GTM container. Tracking that stops one click in is the failure that costs the most and shows up the least.
5. 5. Score and store. The weighted composite is computed, the findings are stored, and the aggregate feeds /benchmarks. Page contents are never stored — only the per-check result, the vendor list, and the platform guess.

What the audit cannot see

Publishing the limits matters as much as publishing the weights. A score is only worth something if you know what it does not cover.

• It does not complete a purchase. The audit never adds to cart or checks out, so it cannot confirm a purchase event fires with the right value. It reads the container configuration to infer whether it would. Verifying that events actually fire needs scripted journeys against a real session.
• It sees two pages, not a site. The homepage and one deeper page. A container missing from a third template goes undetected.
• Interaction-triggered tags are invisible. Tags that fire on a click, scroll, or form submit do not appear during a page load.
• Bot protection can hide a real stack. Some sites serve automated visitors a page with all tracking stripped. When that is detected the report says so explicitly rather than reporting an absence of tracking.
• Detection is identity-based. Finding a Meta Pixel means the pixel is present, not that it fires on the right events with the right parameters.

How the benchmark corpus is built

The corpus is every completed audit of a reachable site — those requested by visitors on /check, plus a nightly seed run across a fixed list of public domains, plus scheduled rescans for domains someone has subscribed to. Aggregates are recomputed hourly over the most recent 5,000 rows — the same window and cadence on every page that reports them.

Audits where the page never loaded are stored as unreachable and excluded from every published statistic. This has not always been true: until August 2026 an unreachable site was recorded as a completed audit scored zero, which pulled the published median down and put “Page load — 100% fail” at the top of the failure leaderboard. Those rows have been reclassified, and the current numbers exclude them.

Questions