The Traffic Drop That Wasn't: GA4 Double-Counted Pageviews

A brand replatformed its website, and within two days the analytics looked alarming: pageviews on key landing pages appeared to have fallen by nearly half. The new site was faster and converting fine, but the chart said traffic had cratered. The chart was wrong, and it had been wrong for years, in the other direction. The old site had been firing GA4 twice on every page load, and the relaunch had quietly fixed it, making an inflated baseline look like a healthy site in decline.

The short answer: two tags, one measurement ID

The old site carried both a hardcoded gtag('config', 'G-XXXX') snippet in the page template and a Google Tag Manager container that loaded its own Google tag for the same GA4 measurement ID. Every page load produced two page_view events. Users and sessions were unaffected, because GA4 deduplicates those by client and session ID, and that selective accuracy is precisely what made the problem invisible: the metrics people sanity-check against each other mostly still agreed.

The arithmetic was sitting in plain sight once someone looked. Views per user was 2.8 on the old site and 1.3 on the new one, almost exactly a factor of two. The new implementation was browser-verified to fire exactly one page_view per load. After deduplicating the old baseline, the "crashed" landing page was actually receiving more traffic after the relaunch than before it.

The red herring: consent mode took the blame first

The relaunch had also wired up a consent banner properly for the first time, with Consent Mode v2 connected. That gave everyone a plausible villain: declined visitors now sent cookieless pings and dropped out of standard reports. The mechanism is real. Google documents that consent-affected hits are recoverable only through behavioral modeling, and modeling has traffic thresholds that small and mid-sized properties do not meet, so on those properties declines simply vanish from reports. Google's own consent mode behavior documentation describes what is and is not collected in each state.

But the consent explanation had a size problem. It explained why numbers might dip, not why they would halve overnight. That distinction, the shape fits but the magnitude does not, is the single most useful instinct in this kind of investigation. The first plausible mechanism you find is usually not the dominant one; it is just the first one. Proving the real cause took tag forensics on the old site: archived page HTML plus the still-published tag manager container, which showed both tags configured against the same measurement ID.

How to check your own site this week

1. View source on your key templates and search for gtag('config' with your measurement ID. Note whether a GTM container also loads on the page, and check inside the container for a Google tag with the same ID.
2. Open GA4 DebugView or your browser's network panel and load a page once. Count the page_view hits. The answer must be exactly one.
3. Sanity-check views per user against reality. If your content site shows 3 pages per visitor but recordings and scroll data say people read one page, believe the recordings.
4. When comparing before and after any migration, diff both sides. Verify what the old implementation actually did, with archived HTML if needed, before treating its numbers as the baseline. We apply the same rule to event delivery between platforms: never assume either side of a comparison is clean.

What to do with years of inflated history

You cannot retroactively fix the data, so document it. Annotate the migration date in GA4 as a permanent series break, state the deduplication factor plainly in any report that crosses it, and move the KPIs that matter to sources the bug never touched, such as Search Console clicks, sessions, and actual orders or bookings. The worst outcome is not the inflated history; it is a team quietly halving its performance targets because the baseline was fiction.

If a migration just made your numbers weird

Before-and-after discrepancies around replatforms are one of the most common things we untangle in a tie-out audit: we verify what each implementation actually sent, reconcile the series, and give you a baseline you can defend. The chart that says your relaunch failed may be the first honest chart the property has ever produced.