The MeasureProof Method
What we check · How we bound each claim · What we don’t claim
How the scan works
The free scan is a live-site observation. We load your page in a clean, sandboxed browser — no cookies, no prior state — and watch the tracking requests it makes, the same way a first-time visitor’s browser would. Validations run against that captured observation. Nothing is installed on your site and no access to your accounts is required or used.
Because the evidence source is the rendered page, every claim is bounded by it. The scan reports the tracking requests sent during that visit; anything that requires seeing inside your GA4 or GTM configuration is named as exactly that — something we cannot prove from the page alone.
The free scan validation set
Each validation states a bounded claim and renders the evidence behind it. The current set:
- Tag and pixel inventory. Claim: “we observed these tags and IDs loading, via these paths.” Evidence: the request log — tag type, ID, load path.
- GA4 pageview counted more than once. Claim: “the same measurement ID received more than one pageview hit for a single load.” Evidence: the duplicate /g/collect requests with timestamps, plus any loaders observed sending them.
- Duplicate or conflicting ad pixels. Claim: “two distinct pixel IDs for the same platform fire on the same page.” Evidence: the duplicate requests.
- Tags firing before consent. Claim: “this tag fired before any consent interaction was possible.” Evidence: the outgoing hit timing against the recorded consent observation — prompt state, interaction state, region, and the wait window — scoped strictly to that observable state, plus which hits were considered.
- Consent signals on outgoing hits. Where consent findings are made, we render the consent-mode parameters observed on the outgoing requests as part of the evidence.
- Hygiene. Claim: “a legacy Universal Analytics snippet is still present” or “a tracking snippet loads but never fires.” Evidence: the snippet, and the absence of corresponding requests.
A validation that cannot be proven mechanically gets cut, not polished. When site behavior falls outside what a validation can evaluate reliably — an unsupported consent banner, ambiguous timing, regional variance — the report records a coverage gap, not a finding.
What we don’t claim
- No composite score. A single 0–100 number hides more than it shows. The summary is the finding count and top severity, each linked to its evidence.
- No verdicts without outcome truth. From the live site, we say “this changed” or “this looks off” — never “your business is fine, it’s the tracking.” That adjudication requires reconciling against real orders and leads, which is a deeper, connected rung of the product.
- No account-specific impact claims. We can see a tag fire twice; we cannot see which of your reports or conversions it inflates without read-only access to your setup. The report says so per finding.
- No bare “all good.” A clean result still shows its work — every validation that ran and passed, listed by name.
Evidence handling
Raw browser capture is ephemeral. We persist only the minimized observation needed for findings — cookies, auth headers, request bodies, and unneeded query parameters are dropped before storage. Measurement IDs are partially masked in evidence rendered on shareable surfaces, so a report stays verifiable by the site owner without being harvestable. See the privacy policy and security model for data handling and retention.
Mistakes
A false finding in a trust product is fatal, so validations under-claim by design and are tested against known sites before they ship. If you believe a finding on your report is wrong, tell us at [email protected] — a confirmed false finding takes the validation out of the shipped set until it is fixed.
Last updated: June 13, 2026