Why Is Analytics Data Becoming Less and Less Reliable?

Web analytics has been under pressure for years, and the problem has accelerated significantly over the past two years. Privacy restrictions, script blocking by browsers and extensions, and the rollout of Consent Mode in European markets have progressively eroded the coverage of traditional measurement systems.

Ad blockers prevent requests to third-party domains like google-analytics.com or googletagmanager.com from reaching their destination, affecting a relevant share of users — particularly in technical audiences. Safari’s Intelligent Tracking Prevention (ITP) limits the lifespan of first-party cookies to seven days and blocks third-party cookies entirely. Firefox blocks third-party trackers by default. And in the European Union, when cookie banners present accept and reject options with equal prominence, studies from the USENIX Security Symposium conducted in collaboration with France’s CNIL document rejection rates of up to 60–70%.

The result is that many GA4 accounts are measuring only a fraction of actual traffic without marketing teams realising it. Campaign optimisation decisions, attribution analysis, and behavioural insights are all built on incomplete data. Understanding how the data collection chain works is the first step toward identifying where it breaks down and how it can be strengthened. If you also want to understand the impact AI traffic is having on these figures, we recommend reading our article on how to measure AI traffic in GA4.

What Is Client-Side Tracking and What Are Its Limitations?

Client-side tracking is the standard model for web measurement. A JavaScript snippet (GA4, GTM, Meta pixels, etc.) loads in the user’s browser and, from there, sends events directly to the analytics or advertising platform’s servers. All data collection logic runs on the visitor’s device.

✔️ Simple to implement: any tag can be deployed in minutes through GTM without touching server-side code.

✔️ Broad behavioural coverage: running in the browser gives access to the DOM, clicks, scroll depth, form interactions, and everything else happening on the page.

✔️ Zero infrastructure cost: no dedicated server or additional maintenance required.

❌ Vulnerable to ad blockers: requests to third-party domains are easily blocked. In technical audiences, the blocking rate can be significant and affect a meaningful portion of traffic.

❌ Consent-dependent: in markets with active Consent Mode, a large share of traffic never triggers the measurement scripts.

❌ Limited by ITP and cookie restrictions: Safari shortens first-party cookie lifespans and blocks third-party cookies, truncating the attribution window.

❌ No control over outgoing data: data flows directly to the vendor (Google, Meta) with no ability to filter, enrich, or transform it before it leaves.

💡 Tip: A clear symptom of client-side tracking degradation is an abnormally high direct traffic percentage in GA4 (above 20–25% on mature sites). Part of that “direct / none” is not actually sourceless traffic — it is sessions from users with blockers or ITP-enabled browsers where the attribution cookie has already expired.

What Is Server-Side Tracking and What Does It Offer?

Server-side tracking moves the data collection logic from the user’s browser to a server controlled by the advertiser. In practice, this means deploying a server container in Google Tag Manager (sGTM), hosted on Google Cloud or a managed provider like Stape.io or Addingwell, and configuring the site to send events to that server rather than directly to Google or Meta.

The flow works as follows: the browser sends a request to a first-party subdomain (for example, metrics.yourdomain.com), the server processes it and forwards it to GA4, Google Ads, Meta, or other destinations. From the browser’s perspective, all communication happens with a first-party domain, which bypasses most blockers. To go deeper on how GTM works and its underlying architecture, check out our Google Tag Manager guide for digital marketing professionals.

✔️ Resistant to ad blockers: requests go to your own domain, not google-analytics.com. Most blockers do not filter first-party domains.

✔️ Full control over data: you can transform, filter, or enrich events before sending them to any destination. Useful for stripping PII, normalising parameters, or enriching events with server-side context such as actual order value, margin, or CRM data.

✔️ Better signal for Smart Bidding: more accurately recorded conversions improve the learning of Google Ads automated bidding strategies.

✔️ Compatible with multiple platforms: a single server container can distribute events to GA4, Google Ads, Meta Conversions API, TikTok, LinkedIn, and others simultaneously.

❌ Infrastructure cost: an sGTM container on Google Cloud carries a monthly cost ranging from approximately €30 to €150 depending on traffic volume. Managed providers like Stape reduce complexity but still involve a fixed cost.

❌ Higher technical complexity: requires knowledge of server configuration, DNS, and event debugging beyond standard GTM.

❌ Does not eliminate the consent problem: server-side tracking improves technical coverage but does not replace Consent Mode. Without user consent, sending data remains a legal question, not just a technical one.

💡 Tip: If you manage Google Ads campaigns with budgets above €2,000/month, the ROI of implementing sGTM is clear. More accurately recorded conversions translate directly into better algorithm learning and lower CPA. Below that threshold, evaluate whether Google Tag Gateway covers your needs first.

What Is Google Tag Gateway and How Do You Implement It Without Breaking Your Analytics?

Google Tag Gateway (GTG) is an intermediate solution that allows Google’s scripts (gtag.js, gtm.js) to be served from your own domain via a CDN, without the need to deploy a full server. Unlike sGTM, it does not process data on a dedicated server — it acts as a proxy for Google’s libraries, serving them from a first-party subdomain.

GTG is compatible with Cloudflare, Akamai, Fastly, and Google Cloud CDN. Cloudflare is the most common starting point, partly because of its free tier. Configuration in Cloudflare is done from the GTM panel under Admin → Container → Google Tag Gateway, and the full setup takes between 5 and 10 minutes.

The key architectural constraint is that GTG only works with Google tags: GA4, Google Ads, Floodlight, and Google Tag. It does not support external platforms like Meta, TikTok, LinkedIn, or any other third-party tag. For those use cases, a full sGTM setup remains the only option.

Cloudflare Risks That Can Destroy Your Qualitative Analytics

Cloudflare offers several performance optimisation features that, when misconfigured, interfere directly with analytics script execution and produce completely distorted data.

Rocket Loader is the most frequent culprit. Its purpose is to improve render time by loading all JavaScript files asynchronously, prioritising visible content for the user. The problem is that it can delay GA4 script execution long enough that a visitor leaves the page before the script fires. When that happens, the session is never recorded. The symptom in GA4 is an artificially inflated bounce rate and sessions with zero or near-zero duration — not reflecting real user behaviour but a technical loading issue.

Aggressive cache rules of the “Cache Everything” type can also serve static HTML snapshots that never re-execute GA scripts. On static sites, this behaviour is particularly relevant.

Auto Minify applied to JavaScript can alter GTM or gtag.js script code in unpredictable ways, causing silent errors that are difficult to diagnose.

How to Diagnose and Fix the Problem

The diagnosis is straightforward. Enable GA4’s real-time report and browse your own site. If sessions do not appear or show up with zero duration, the script is not firing correctly. Complement this by checking the browser console (DevTools → Console) for JavaScript errors during page load.

To fix it, the options are the following in order of preference:

✔️ Disable Rocket Loader in the Cloudflare panel (Speed → Optimization → Content Optimization). This is the most direct solution and has no meaningful performance impact if scripts are properly optimised.

✔️ Disable Auto Minify for JavaScript in the same optimisation section.

✔️ Implement Google Tag Gateway, which by serving scripts from your own domain eliminates Rocket Loader’s interference with Google’s third-party domains.

✔️ Exclude GTM script URLs from cache rules by creating a Page Rule or Cache Rule that applies “Bypass Cache” to paths */gtm.js and */gtag.js.

Why Is Cloudflare Analytics More Reliable Than GA4 for Measuring Real Traffic?

Cloudflare Web Analytics operates in a completely different layer from GA4, measuring traffic at the network level rather than in the browser. This has direct implications for data reliability.

GA4 depends on a JavaScript script loading and executing correctly in the user’s browser. As we have seen, ad blockers, ITP, Cloudflare configurations, and lack of consent can all prevent that execution. GA4 only sees what the script sees, and the script does not always make it.

Cloudflare Web Analytics, by contrast, records HTTP requests arriving at its network before they reach the server. A visitor who blocks GA4, rejects cookies, or uses Safari with ITP active still generates an HTTP request that Cloudflare records. There is no script to block because measurement happens at the infrastructure level, not in the browser.

In addition, Cloudflare Analytics does not use cookies or store personally identifiable data, making it compatible with privacy regulations without requiring consent. It applies no sampling to the data and, by operating at the network level, is better equipped to distinguish real human traffic from bots, filtering a large portion of automated traffic before it reaches the origin. For a broader look at analytics tools that do not depend on cookies, you can expand on this in our article on alternatives to Google Analytics without cookies.

The practical consequence is that Cloudflare Analytics figures will be higher than GA4’s, and that gap is not noise — it is real traffic that GA4 is not capturing. Using Cloudflare Analytics as a reference for total traffic volume and GA4 for behavioural analysis and attribution is the most robust combination available today for most sites.

💡 Tip: Periodically compare unique visits in Cloudflare Analytics against GA4. If the difference is consistently significant over time, you have a coverage problem in your tracking that is affecting your optimisation decisions. That gap is your starting point for prioritising an implementation improvement.

Which Tracking Solution Fits Your Case?

There is no single right answer. The choice depends on traffic volume, advertising budget, available technical complexity, and privacy requirements.

✔️ Standard client-side: suitable when traffic is low, advertising investment is not significant, and the audience is not particularly technical. Easy to implement and maintain, accepting variable coverage loss depending on audience profile and geographic market.

✔️ Client-side + Google Tag Gateway: the next level with no additional infrastructure cost. Reduces ad blocker interference for the Google ecosystem, improves script reliability in Cloudflare environments, and requires no dedicated server. Recommended for any site using GA4 or Google Ads that is already on Cloudflare.

✔️ Server-side GTM (sGTM): necessary when managing multiple advertising platforms (Google, Meta, TikTok), when paid media budgets justify the infrastructure investment, or when granular control over data is required before sending it to third parties. Monthly cost of €30–€150.

✔️ Cloudflare Analytics as a complementary layer: recommended in all cases as a reference for real traffic. It does not replace GA4 for behavioural analysis or attribution, but it provides an unbiased view of total visit volume.

Conclusions on Tracking and Analytics Accuracy

Incomplete data is not a tooling problem — it is a decision-making problem. Optimising campaigns, allocating budget, or evaluating content performance on a partially covered data set produces systematically incorrect conclusions.

Understanding the difference between client-side and server-side, knowing when Google Tag Gateway is sufficient and when it is not, and complementing GA4 with Cloudflare Analytics are concrete steps that improve data quality without requiring large investments in every case.

At Vision by Data, we audit and implement measurement architectures tailored to each situation, from lightweight configurations to full server-side implementations. If you want to know what share of your real traffic you are not measuring and how to fix it, find out how we can help.