Why Google Analytics undercounts your real traffic

If you've ever compared Google Analytics against server logs or a payment processor's own visitor count and found GA's number noticeably lower, that gap is real and has specific, well-understood causes — not a mystery, and not unique to GA4. Here's what's actually happening, mechanism by mechanism.

Ad blockers block the request outright

Popular ad-blocking filter lists (EasyPrivacy is the common one) specifically target requests to google-analytics.com and googletagmanager.com. When a visitor has one installed, the tracking request is blocked before it ever leaves the browser — the pageview isn't sampled out or discounted, it's simply never sent. On sites with a technically-inclined audience (developer tools, privacy-conscious products), this can meaningfully undercount real traffic.

Safari's Intelligent Tracking Prevention

Safari's ITP restricts how long client-side identifiers can persist and actively limits known tracking patterns. The practical effect: a real returning visitor on Safari or iOS can get counted as a brand-new visitor on a later visit once their identifier expires, or miss being recorded consistently at all — inflating "new visitor" counts while quietly undercounting true return traffic. Firefox's Enhanced Tracking Protection does something similar by default.

Consent banners that gate the script itself

This one's almost ironic: a compliant setup that correctly waits for consent before loading GA means anyone who declines, or who navigates away before deciding, is never recorded at all. Doing consent right — as you should — is itself a source of undercounting, not a bug in the analytics tool.

What this means practically

None of this makes GA4's numbers useless — but it means they're better read as a consistent lower bound and a directional trend than an exact headcount. If your actual visitor count matters (capacity planning, honestly reporting real reach), treat cookie-based analytics numbers as "at least this many," not "exactly this many."

Worth being honest about the other side too: cookie-free tools aren't immune to this either. Ad blockers that specifically target known analytics domains can eventually catch any hosted tracking script, cookie-free or not, the same way they've learned to catch GA's. What cookie-free tools do avoid is the consent-banner gate specifically, since there's no persistent identifier requiring one — that's a real, structural difference, not a claim of total immunity from every blocking method. Embaze is built around that one specific difference, if it's the piece of your GA4 numbers you're trying to fix.