Technical Guide
GA4 underreports real traffic by 30-60% on most properties: ITP, iOS 17 link tracking, ad blockers, consent banners, and AI-engine referrers each chew off a piece. Where the data goes, and how to recover it without breaking GDPR.
The first time I noticed the gap I was running $4,200/month in Google Ads and GA4 attributed $3,100 of revenue back to those campaigns. Stripe payouts said $5,400. I assumed I had a UTM tagging bug. I did not. I had six.
GA4 is not lying. It reports exactly what its script and channel-grouping rules can see, which on a 2026 web is a smaller subset of real traffic than founders assume. This article walks through each leak source with the hard number where one exists, then the architectural fix. I built Attrifast because the alternative was another spreadsheet.
| Spec | Value |
|---|---|
| Typical GA4 undercount vs first-party | 25-45% on consumer SaaS audiences |
| Safari ITP first-party cookie cap | 7 days (script-set) [1] |
| iOS 17 Link Tracking Protection launch | September 2023 in Mail, Messages, Safari private browsing [2] |
| Global desktop ad-block penetration | ~32% (Backlinko 2024 aggregate) [3] |
| EU consent banner refusal range | 40-60% on most properties (CNIL practitioner reports) [4] |
| ChatGPT referrer behavior | No Referer header on most outbound clicks (default policy) [5] |
| Safari + Firefox global share | ~28-32% (StatCounter late 2025) [6] |
| Brave browser users worldwide | ~78 million monthly active (Brave Q3 2024 transparency report) [7] |
| GA4 default channel grouping | 17 channels; no AI category until you build one [8] |
| Attrifast script size | ~4KB, proxied via your subdomain |
Not picking a fight with Google. GA4 is free and fine for top-of-funnel directionals. The argument is narrower: if you have opened GA4 and Stripe side by side and the numbers tell different stories, the rest of this is for you.
ITP 2.3 broke my paid-search dashboards. It caps first-party cookies set by JavaScript (the document.cookie API, which is how GA4 writes _ga) at 7 days. WebKit's ITP documentation is explicit that script-set cookies expire after 7 days regardless of the expires attribute. A returning Safari visitor on day 8 generates a new _ga, GA4 assigns a new client ID, and your dashboard reports two unique users where there was one.
For a SaaS with a 14-day trial:
/pricing, signs up. GA4 attributes the user to google / cpc./dashboard, decides to upgrade. ITP has expired the _ga cookie. GA4 sees a brand-new user via (direct) / (none).(direct), with no link back to the paid click.The paid channel is now under-credited. On my flagship property Safari is roughly 22% of sessions; on a Mac-developer audience it can hit 45-55%. WebKit's tracking prevention page lists every cap and partition. None of it is hidden; it just does not show up in GA4 as "data we lost," only as "more direct traffic than you expected."
iOS 17 shipped in September 2023 with Link Tracking Protection, default-on in Mail, Messages, and Safari private browsing. It strips known tracking parameters from URLs in real time. A friend pastes you https://yourapp.com/?utm_source=newsletter&fbclid=IwAR... over iMessage; iOS rewrites the link to https://yourapp.com/ before the click ever reaches your server.
Apple has not published the exact parameter list, but the WebKit Tracking Prevention Policy and practitioner reverse-engineering confirm fbclid, gclid, ttclid, mc_eid, and utm_* family members are stripped in covered surfaces. GA4 reads UTMs off the URL on landing. If the UTM is gone, GA4 assigns the session to organic or direct by default.
Email and social attribution disproportionately collapses for iOS users. A newsletter with utm_source=newsletter that performs identically on Android and iOS will show ~30-40% lower attribution on iOS in GA4, not because the campaign worked worse, but because iOS rewrote the URLs before the script could read them. The fundamental problem (parameter gone before page load) is not solvable client-side.
| Leak source | Estimated data loss | Who's most affected |
|---|---|---|
| Safari ITP cookie cap | 15-30% of returning Safari users misattributed | Properties with >2-week consideration cycles |
| iOS 17 Link Tracking Protection | 30-40% of iOS clicks from Mail/Messages/Safari Private | Newsletters, social DMs, affiliate links |
| Ad blockers blocking /collect | 30-40% desktop, 15-25% mobile | Developer/tech/privacy audiences (50%+) |
| EU consent banner refusal | 40-60% of EU/UK users refuse non-essential | B2C, news, EU-heavy SaaS |
| AI-engine referrer stripping | ~100% of ChatGPT/Perplexity sessions bucketed as Direct | Content-led products picked up by AI answers |
| Bot filter false positives | 1-5% of real human sessions | Privacy-aware users, headless-browser power users |
| Cross-device sessions | Variable; up to ~30% of multi-touch journeys | Long sales cycles, B2B, mobile-to-desktop flows |
The simplest and most underrated leak. Ad blockers do not "interfere with" GA4. They prevent the script from loading. Zero pageviews, zero events. GA4 sees nothing.
Default blocklists used by uBlock Origin, AdGuard, Brave Shields, Ghostery, and most Pi-hole configurations include googletagmanager.com, google-analytics.com/* (where /collect and /g/collect live), analytics.google.com, and the regional region1.google-analytics.com shards. EasyList, the foundational blocklist most blockers inherit from, has had these for over a decade. The Brave browser blocks them out of the box for ~78 million monthly active users per Brave's Q3 2024 transparency disclosures [7].
Per Backlinko's 2024 aggregate, roughly 32% of internet users worldwide have an ad blocker on at least one device. Desktop estimates from GlobalWebIndex run 35-43% on tech-heavy demographics. Mobile is lower (15-25%) because iOS Safari content blockers are less common and Chrome on Android does not support extensions.
For developer-tools audiences the number is much worse. On a 12,000-pageview/week developer SaaS where I ran a parallel-deploy test, the first-party server-side script reported 53% more pageviews than GA4. Most of the delta was ad blockers.
The fix is not "ask people to disable their blocker." It is to load the tracking script from your own domain. EasyList does not block analytics.yourdomain.com because the rule would break every site on the internet. A CNAME from your subdomain to your analytics provider's edge bypasses the blocklist. The technique is detailed in cookieless tracking solutions. Plausible, Fathom, and Attrifast all support this; GA4 does not, by design.
GDPR Article 7 and ePrivacy Article 5(3) require explicit, freely-given, informed consent before setting a non-essential cookie. The EDPB's Guidelines 2/2023 extended the regime to localStorage, fingerprinting, and any persistent client-side identifier. GA4's default install sets identifiers that fall under it.
Per CNIL audits and practitioner aggregates [4], EU consent banner refusal rates land in the 40-60% range on most properties, with 30% on the low end (well-designed banners on US-style sites) and 75%+ on the high end (German news properties under the TCF v2.2 framework). The IAB's TCF reporting and European DPC enforcement decisions reinforce that genuine consent rates are well below the 90%+ early CMP vendors marketed.
When a user refuses, Google's Consent Mode v2 kicks in. It does not write cookies, sends pings with reduced data, and Google fills the gap with "modeled conversions" from aggregate signals on consenting users. Coverage is uneven; practitioner reports describe wide variance with material drops on EU-heavy traffic. The cookieless tracking solutions guide walks the architectural decision tree.
The CNIL audience-measurement exemption carves out a banner-free path for analytics that meet four conditions: rotating salt, truncated IP, no cross-site linkage, no advertising use. Plausible, Fathom, and Attrifast meet all four and ship without a banner in France and several other EU jurisdictions, which itself recovers a chunk of the refused-consent loss. GA4 does not meet the exemption because it links across Google properties for ads.
The leak that hit me hardest in 2025. Roughly 8% of my organic-equivalent traffic was coming from ChatGPT and Perplexity, and 100% of it was sitting in (direct) / (none) in GA4.
Two-part mechanic. First, AI answer engines navigate users to source URLs via their chat UI. The browser default Referrer-Policy: strict-origin-when-cross-origin sends only the origin, not the path. Some AI surfaces override to no-referrer. ChatGPT's web app uses a CSP that often results in no Referer header reaching the destination [5].
Second, GA4's default channel grouping has no AI category. It ships with Direct, Organic Search, Paid Search, Organic Social, Paid Social, Email, Affiliates, Referral, Audio, SMS, Mobile Push, Display, Cross-network, Organic Shopping, Paid Shopping, Video, Organic Video. No AI. So a chat.openai.com referrer either lands in Referral (if the header arrives) or Direct (if it does not). Most land in Direct.
The fix is server-side. On first hit your server reads document.referrer and Sec-Fetch-Site, persists them in a first-party session row, and maps known AI domains (chat.openai.com, chatgpt.com, perplexity.ai, you.com, phind.com, claude.ai, copilot.microsoft.com) to an AI channel of your own definition. GA4 can be retrofitted with a custom channel grouping if you capture Sec-Fetch-Site as a custom dimension, but the default install will never do it. This is one of the specific gaps Attrifast was built for. More on the referrer chain in cross-site tracking explained.
GA4 silently filters traffic it believes is automated. The IAB/ABC International Spiders & Bots List is the canonical source, and GA4 applies it server-side with no opt-out. That is mostly good. It also catches false positives: developers running headless Chrome / Puppeteer / Playwright against your site, users behind corporate proxies that strip user-agent details, some iOS Private Relay traffic with shared egress IPs and normalized UAs, Brave power users with fingerprint randomization, and stale browsers whose UA matches old crawler signatures.
The false-positive rate is small in absolute terms (commonly 1-5% per practitioner audits) but biased: the misclassified users are disproportionately your high-intent technical buyers. Losing 1-5% of sessions that are 4x more likely to convert is a meaningful revenue hit. There is no public knob in GA4 to inspect or override the filter; the data is gone before it reaches your dashboard.
GA4 cannot stitch the same human across devices without a logged-in user ID. Signals/User-ID require explicit configuration and only work for authenticated sessions. For the typical SaaS journey ("saw ad on phone, signed up on laptop two days later"), GA4 treats the two touches as two different humans on two different channels.
On my own properties, when I cross-reference Stripe metadata session IDs against the original landing-page session, roughly one in five paid signups have an originating session on a different device than the conversion. The exact percentage varies; the direction does not. A server-side join with first-party storage preserves the link because the session ID rides through Stripe Checkout metadata and gets rejoined post-payment.
Structurally unfixable without a login. The anonymous-cross-device bridge is a fingerprint, which the EDPB put under consent. The realistic 2026 answer: capture an authenticated user ID at signup and stop pretending an anonymous tool can solve it. The GA4 vs first-party comparison covers what each architecture can and cannot do.
The leaks overlap (an EU Safari user with uBlock running through Brave is hit by four at once), so they do not add cleanly. The aggregate effect is consistent across the properties I have measured.
| Audience type | Approx. GA4 capture rate vs first-party | Dominant leak |
|---|---|---|
| US consumer SaaS, short cycle | 75-85% | Ad blockers |
| US B2B SaaS, 14-day trial | 65-75% | ITP cookie cap |
| EU-heavy B2C | 45-60% | Consent refusal + ad blockers |
| Developer/tech tooling | 50-65% | Ad blockers (50%+ install rate) |
| Content site picked up by AI engines | 70-80%; +8-15% mis-bucketed as Direct | AI-engine referrer stripping |
| Mobile-heavy news | 60-70% | iOS Link Tracking Protection + consent |
These are ranges, not guarantees. "GA4 misses 30%+" is the median across my measurements; your property could be 15% or 55%.
Five steps, in priority order, with expected recovery where one can be estimated.
Step 1: Proxy your analytics script through a subdomain you control (recovers most ad-block loss). CNAME analytics.yourdomain.com to your provider's edge. Script and collect-endpoint both live on your domain. EasyList does not block your domain because the rule would break the internet. GA4 does not support first-party proxying cleanly; Plausible, Fathom, and Attrifast do. Expected recovery: 80-95% of ad-block loss.
Step 2: Use server-side session identification instead of script-set first-party cookies (recovers ITP loss). A daily-rotating server-side hash of IP + UA + salt (the A1 architecture from cookieless tracking solutions) gives you a stable session identifier without a script-set cookie that ITP caps at 7 days. Expected recovery: most of the returning-Safari undercount past day 8.
Step 3: Capture document.referrer and Sec-Fetch-Site server-side on first hit, map AI domains explicitly. Maintain a list of AI engine domains and route them to your own AI channel. Expected recovery: visibility into the 5-15% of traffic that AI engines drive today, currently hidden in Direct.
Step 4: Pass a session ID through Stripe Checkout metadata and rejoin on checkout.session.completed. The join that turns "I think Google Ads drove $5,400" into "Google Ads drove $5,400, here are the 47 sessions and Stripe customer IDs." The Stripe Checkout Session metadata field supports 50 keys × 500 characters; one holds your session ID. Expected recovery: full revenue attribution for any Stripe Checkout conversion.
Step 5: For EU traffic, check the CNIL audience-measurement exemption and drop the banner if you qualify. Rotating salt, truncated IP, no cross-site linkage, no ads use. If all four hold, the CNIL guidance lets you skip the banner for analytics in France and several other EU jurisdictions. Expected recovery: most of the 40-60% consent-refusal loss for analytics (advertising pixels still need consent).
I built first-party tracking into Attrifast because I was tired of running this list as a spreadsheet. The 4KB script proxies through your own subdomain, the server-side hash sidesteps ITP, the AI-domain map ships by default, and the Stripe webhook handler does the revenue join out of the box. Not a Google replacement for everything; a parallel system that closes the leak the Google stack cannot. For the architectural comparison see /vs/google-analytics. The live channel-revenue dashboard view (sessions joined to Stripe payouts, AI broken out separately) lives at /dashboard.
Verify the leak on your own property first. Install a first-party server-side tool in parallel with GA4 for 14 days. Pull unique-visitor counts from both for the same window. If first-party is 5-10% higher you are mostly fine. 20%+ higher and you have a meaningful leak. Break the delta by browser (Safari + Firefox usually account for a disproportionate share). Cross-reference the first-party numbers against Stripe; the revenue-per-source view should now match Stripe payouts within a few percent. Across roughly 40 marketing channels on my own properties and client SaaS apps, the median GA4 undercount vs first-party is around 28%. Worst I have personally measured: 61% (developer-tools SaaS, Brave-on-Linux 18% of sessions, EU consent rate around 35%). Best: 6% (US-only SMB tool, non-technical audience).
A few things this article does not cover.
GA4 sits on top of a JavaScript file from googletagmanager.com plus first-party cookies that browsers like Safari and Firefox cap aggressively. Ad blockers strip the script before it loads, EU consent banners gate it behind opt-in, iOS 17+ Private Relay rewrites referrers, and AI engines like ChatGPT send no referrer header at all. The combined leak commonly runs 25-45% on consumer SaaS audiences. Stripe sees every paid customer because the checkout flow runs on your own domain and is not blockable. The gap is real; the question is which leak source dominates for your audience.
Yes. Apple's Intelligent Tracking Prevention caps script-set first-party cookies at 7 days, and iOS 17's Link Tracking Protection strips known tracking parameters from URLs shared in Messages, Mail, and Safari private browsing. Returning Safari visitors past day 8 look like brand-new users to GA4. Self-reported numbers from privacy-analytics vendors and W3C presentations describe Safari undercounting in the 15-30% range for returning-user metrics, depending on the attribution window. Chrome is less aggressive but Privacy Sandbox plus Enhanced Tracking Protection on Edge will narrow the gap over the next two years.
Global ad-block penetration sits in the 30-40% range on desktop and 15-25% on mobile per published reports from GlobalWebIndex and Backlinko. uBlock Origin, AdGuard, Brave's built-in shield, and Ghostery all block requests to googletagmanager.com, google-analytics.com, and the /collect endpoint by default. On a technical or developer-heavy audience that number climbs above 50%. The leak is binary: when the blocker fires, GA4 sees zero pageviews and zero events for that user, not a degraded version.
AI answer engines either omit the Referer header entirely (browser default for cross-origin navigation from chat.openai.com to your site uses strict-origin-when-cross-origin or no-referrer policies) or send a referrer that GA4 does not have in its default channel grouping. Both cases land in (direct) / (none). I have watched ChatGPT-driven trial signups appear in Stripe metadata while GA4 attributed the same sessions to Direct. The fix is server-side referrer capture plus a custom channel grouping that maps known AI domains to an AI channel.
Three things. The script loads from your own subdomain so ad blockers do not match it against their domain lists. The session identifier lives in a server-side hash so ITP does not cap it at 7 days. And the AI-engine referrer is captured server-side on first hit so it survives Referer-header stripping. None of this fixes consent refusal in the EU, but a CNIL-compliant rotating-hash architecture can drop the banner for analytics in France and several other jurisdictions, which itself recovers a chunk of EU loss.
For a deeper dive on related ground, see AI Overviews Killed My Traffic: A 2026 Recovery Playbook.
Discover which marketing channels bring customers so you can grow your business, fast.
Start free trial →5-day free trial · $29/mo · cancel anytime