Why can't client-side tracking collect complete data?

Client-side tracking collects data by executing JavaScript in the browser. Bot traffic, ad blockers, browser privacy policies (ITP, ETP), and page abandonment before JS loads break this mechanism at four different points. Each source alone can cause 10-50% data loss, and these sources stack on top of each other.

How can I collect data from ad blocker users?

Proxy-based solutions like Cloudflare Zaraz route tracking requests through your own domain, bypassing ad blockers. Server-side GTM provides partial protection. Self-hosted analytics tools like Umami don't appear on blocker lists when running on your own domain.

How does Safari ITP affect GA4 data?

Safari ITP deletes JS-created cookies (including GA4's _ga cookie) after 7 days of no user interaction. Safari users who don't return within 7 days are counted as new users on every visit. For visitors from ad clicks, this window drops to 24 hours.

Does server-side tracking completely solve these problems?

Server-side tracking provides advantages in bot filtering, ad blocker bypass, and cookie management, but it's not a silver bullet. Consent requirements still apply server-side. Additionally, ITP has started capping CNAME-cloaked cookies to 7 days as well.

Client-Side Tracking Problems: Bot Traffic, Ad Blockers, and Browser Privacy

TL;DR

Client-side analytics tools (GA4, GTM, pixels) cannot measure all internet traffic. Bot traffic accounts for 51% of total traffic (Imperva 2025), ad blockers erase 15-30% of GA4 data, Safari ITP caps cookies at 7 days causing returning users to be counted as new, and some users leave before JavaScript loads. When these four loss sources stack up, GA4 may see less than half of actual traffic.

View Subscription Sign In