Measurement verified clean on an e-commerce homepage

Anonymized, and generated from a report you can read: the scan report itself is published alongside this study. Both come from a real MeasureProof production scan of a public direct-to-consumer homepage, with the site’s address and every identifier withheld. The site is not a customer, and we don’t publish customer reports — anonymized studies of public sites are how we show what a scan produces.

This is the other outcome. A scan that finds nothing is not a scan that did nothing: it produces a receipt naming every check that ran and passed, which is the artifact you keep as a baseline. Anonymizing costs the same thing it costs elsewhere — because the site is not named, you cannot re-run this and confirm it yourself.

What we observed

A working measurement stack, behaving correctly within everything the scoped checks can prove. The scanner recognized 15 vendor-and-ID rows across 10 vendor families — GA4, GTM, Google Ads, TikTok, Pinterest, Meta, Microsoft UET, Reddit, Hotjar and Amazon Ads — some loading only, others firing, with no findings and no coverage gaps: no duplicate page_view per GA4 measurement ID, no conflicting Meta or TikTok pixel IDs, no legacy Universal Analytics, no orphaned GA4 or Meta loaders.

The stack is more sophisticated than most: the same pageview is sent to three distinct GA4 measurement IDs, one of them via a collection endpoint on the site’s own domain — consistent with first-party proxying or server-side routing, a setup many tools misread. Each measurement ID received the pageview exactly once.

Why three streams passed the duplicate check

The duplicate check asks whether any single GA4 measurement ID was sent the same pageview more than once. Here, three distinct measurement IDs were each sent it exactly once — so the check passes for all three. The two standard streams share one client identity (same client and page-load IDs); the first-party stream keeps its own.

One thing external observation cannot tell you: a measurement ID identifies a GA4 data stream, and one GA4 property can contain several streams. Whether these three streams feed one property or three — and therefore what any single property’s reports actually total — is a configuration question, not a wire question.

What “clean” means here, exactly

Verified for page-level signals on the observed homepage loads: the checks passed, on the wire, on every load we captured, each within its stated scope. It does not cover conversion or checkout events — those fire on interaction, which a page-load observation does not reach — and it cannot say whether the three GA4 streams are intentional, or how they map to properties. A migration mid-flight, a legacy stream still receiving data, or a deliberate backup all look identical under external observation; the answer lives in the GA4/GTM configuration only the site’s owner or their agency can see.

How it was verified

Two independent legs: a MeasureProof production scan on 20 July 2026 (the site serves it without challenge), and a plain Chrome browser across three fresh sessions on 16 July. The per-measurement-ID counts were identical on every load. We publish an observation only after it holds in a browser independent of our own scanner.

A note on time

This receipt is true as of the dates above — that is its nature. A stack this size (71 distinct third-party hosts on one page load) changes constantly: new campaign pixels, theme updates, GTM publishes. A clean baseline is an asset worth keeping current, which is what the watch does: it re-checks on a schedule and reports what changed.

The report this study is drawn from: the anonymized scan report.
The opposite outcome on the same class of site: duplicate GA4 pageviews on an e-commerce homepage.

See it on a site you manage: run a free scan.