Duplicate GA4 pageviews 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.

Anonymizing has a cost worth stating up front: because the site is not named, you cannot re-run this check and confirm it yourself. What follows carries the same evidence a named study would, minus the identifiers that would let you reproduce it. The failure mode itself is common enough to find on plenty of sites, which is what the free scan is for.

What we observed

One load of the site’s homepage sends two GA4 page_view beacons for the same measurement ID. A single, correct install sends one per pageview.

How we know it is one pageview, not two

The two beacons carry identical identifiers. These values differ on every fresh visit; their equality within a load is the evidence that this is one pageview sent twice, not two visits:

• Client ID (cid) — identical in both beacons
• Session ID (sid) — identical in both
• Page-load ID (_p) — identical in both
• Page URL (dl) — the same homepage URL in both

That places both beacons in one page load, from one browser, in one session. The literal values are withheld here regardless of anonymity — they are visitor-adjacent data. The equality is the evidence.

What that does to the numbers

Pageview counts for affected loads are inflated by the double-counting. Engagement rate and bounce rate may also be distorted. Whether sessions and conversions are affected depends on how the duplicate is wired: here the beacons share a session ID, so sessions are not inflated by this shape, and no conversion event was observed, so we make no claim about conversions.

How it was verified

The duplicate held across six checks on four dates: production scans on 15, 27 and 29 July 2026, plus independent checks in a plain Chrome browser on 15, 16 and 29 July. We publish an observation only after it holds in a browser independent of our own scanner.

One production scan six minutes before the current one saw a single page_view on its first load, but could not complete the site’s consent interaction. The scan we are reporting completed that interaction and observed two page_view beacons on both its first and its consent-interaction loads. The earlier incomplete scan was not evidence that the issue had gone away, and we did not treat it as such.

Where external observation stops

The wire shows duplicate pageview instrumentation. It cannot show the cause: a hardcoded tag alongside a GTM-managed one, an automatic-plus-manual pageview send, or overlapping platform behavior all produce this same signature. Which mechanism it is, and which reports depend on the inflated stream, lives in the GA4/GTM configuration that only the site’s owner or their agency can see. From inside GA4, that is a five-minute check once you know to make it. A connected scan, once available, would read that configuration and distinguish these causes.

A note on time

This observation was true on the dates above. A theme update, a plugin update, or a GTM publish can change it silently, in either direction. That is what the watch exists for: it re-checks a baseline like this on a schedule and reports what changed.

This study is scoped to one finding. The same report also carries a warning-severity finding — measurement requests firing before any consent interaction was possible — which is not examined here.

The report this study is drawn from: the anonymized scan report.
The failure mode in general: duplicate GA4 pageviews.

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