Client-side GA4 leaks 25-40% of your data to ad blockers and consent rejections. Server-side tracking is how DACH companies actually fix it.

Server-side tracking is an analytics architecture where data collection happens on your own server infrastructure instead of in the user’s browser — eliminating ad blocker interference, improving data accuracy, and enabling GDPR-compliant data processing by design.

If you’re running a marketing team or data function at a DACH company, here’s the short version of why you should care: your client-side GA4 setup is probably missing 25-40% of your actual traffic. That’s not a guess. It’s what we consistently find when we audit GA4 implementations for mid-market companies in Germany, Austria, and Switzerland. The data you’re using to make budget decisions, evaluate campaigns, and report to leadership is significantly incomplete. Server-side tracking closes that gap — and it does so in a way that actually improves your GDPR posture instead of undermining it.

The rest of this post explains why the gap exists, how server-side tracking fixes it, and what a migration actually looks like in practice.

Why client-side GA4 is losing your data

Three forces are working against your standard GA4 implementation right now. Each one independently causes significant data loss. Combined, they make client-side analytics unreliable as a single source of truth.

The overlap between these groups isn’t total — some visitors have an ad blocker and would have rejected consent — but stacked, the data loss is real and significant.

How server-side tracking works

The concept is straightforward. Instead of your website loading a Google JavaScript file that sends data directly from the visitor’s browser to Google’s servers, you insert your own server in the middle.

The flow looks like this: Browser -> Your Server -> Analytics Platform.

The visitor’s browser sends events to an endpoint on your domain — say, analytics.yourcompany.com. This looks like a normal first-party request. It doesn’t trigger ad blockers because it’s your domain, not google-analytics.com. Your server receives the raw event data, applies whatever logic you need (consent checks, IP anonymization, data filtering), and then forwards the processed data to GA4 (or any other analytics tool).

There are several ways to set this up:

• GTM Server-Side is the most common approach. Google provides a server-side container that you host on Google Cloud, AWS, or any cloud provider. It receives events from the client-side GTM container (or a lightweight custom tag) and processes them before forwarding to GA4, Google Ads, Facebook, etc.
• Cloudflare Workers or similar edge computing platforms can act as a tracking proxy, particularly useful if you already use Cloudflare.
• Custom endpoints — if you have specific requirements or want to avoid Google infrastructure entirely, a simple API endpoint (Node.js, Python, whatever your team knows) can receive events and forward them via the GA4 Measurement Protocol.

The key insight: because the data collection happens on your infrastructure, ad blockers don’t interfere. The request goes to your own domain. There’s no third-party script to block. You still need consent for analytics (the GDPR hasn’t changed), but the technical implementation is no longer fragile.

The GDPR advantage

Server-side tracking isn’t just about recovering lost data. It changes your compliance posture fundamentally — and once you bring AI into the analytics pipeline, the technical controls below also feed the documentation the EU AI Act expects from deployers.

Data stays on your servers

With client-side GA4, the visitor’s browser sends data directly to Google’s servers. You’re trusting Google’s data processing agreement and their infrastructure decisions. With server-side tracking, the raw data hits your server first. You decide what happens next.

You control what gets forwarded

Before any data leaves your infrastructure, you can strip, transform, or enrich it. Remove IP addresses. Drop user-agent strings. Redact URL parameters that contain personal data. Forward only the aggregated or anonymized data that your analytics actually needs.

Consent enforcement happens server-side

Client-side consent enforcement relies on JavaScript running correctly in the browser. If a consent management platform has a bug, loads slowly, or is blocked by an ad blocker, consent logic can fail silently. Server-side, you enforce consent in code you control on infrastructure you manage. If a user hasn’t consented, the server simply doesn’t forward the event. There’s no race condition, no client-side JavaScript dependency.

IP anonymization before data leaves your infrastructure

The CNIL in France and the BayLDA in Bavaria both flagged standard GA4 implementations for transferring personal data (including IP addresses) to US servers without adequate safeguards. The Austrian DSB went further, ruling in January 2022 that Google Analytics violated the GDPR’s transfer rules entirely. While the EU-US Data Privacy Framework has since provided a legal basis for transfers, the regulatory scrutiny hasn’t disappeared — and server-side tracking gives you a technical control that doesn’t depend on the current legal framework surviving its next court challenge. You anonymize before the data ever leaves your EU infrastructure.

What a migration looks like

We’ve done this enough times that the process is predictable. For a standard website (one domain, server-rendered or a single SPA, existing GTM setup), plan for 4-6 weeks from kickoff to cutover. Multi-domain setups, complex SPA architectures, or mobile app tracking push that to 8-12 weeks.

1. 01

   Audit existing tracking

   Map every tag, trigger, and variable in the current GTM container. Document which events actually matter for reporting and which are noise. Check the consent management integration. The audit phase is where we discover the five abandoned tags from three agencies ago that nobody remembers adding — it happens on nearly every project.

   ⏱ Week 1

2. 02

   Architecture and GTM Server-Side setup

   Design the server-side architecture, spin up the GTM Server-Side container (typically on Google Cloud Run in the europe-west3 Frankfurt region for DACH clients), configure server-side tags, and set up first-party domain mapping.

   ⏱ Weeks 2-3

3. 03

   Parallel run and data validation

   Run client-side and server-side tracking simultaneously and compare the data. This shows exactly how much data the client-side setup was missing and validates that the server-side implementation is capturing events correctly. We typically see a 15-30% increase in recorded sessions in this phase — that's the data you've been losing.

   ⏱ Weeks 3-5

4. 04

   Cutover and monitoring

   Cut over to server-side as the primary tracking method, set up monitoring and alerting on event volumes, error rates, and consent flow integrity. Document the architecture, runbook, and decision log for the in-house team.

   ⏱ Weeks 5-6

Cost reality check

I want to be honest about this: server-side tracking is not free.

You need server infrastructure. For GTM Server-Side on Google Cloud Run, expect monthly hosting costs of EUR 30-100 for low-traffic sites and EUR 100-500 for sites doing millions of monthly pageviews. Cloudflare Workers-based setups can be cheaper at scale. You also need someone to maintain the server-side container — updates, monitoring, debugging when something breaks.

The total additional cost for most mid-market companies is EUR 100-400 per month in infrastructure, plus a few hours of maintenance per quarter. Compare that to the value of the data you’re currently losing. If your marketing budget is EUR 50,000/month and 30% of your conversion data is invisible, you’re making half-blind decisions with serious money. The infrastructure cost pays for itself quickly.

That said, if you’re a small company with a simple website and modest ad spend, the ROI calculation is tighter. We tell prospective clients this upfront — not every company needs server-side tracking today.

Wondering how much your tracking is actually missing?

We’ll audit your GA4 setup and tell you the gap — sessions, conversions, and attribution lost to blockers, ITP, and consent. No commitment.