Server-side tracking in 2026: why client-side GA4 isn't enough for DACH companies

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.

Ad blockers in DACH: roughly 30% of your visitors

Germany has some of the highest ad blocker adoption rates in the world. According to PageFair’s 2024 ad blocking report, approximately 29-32% of German internet users run an ad blocker — and that number skews higher in the B2B and tech demographics that many of our clients target. In Austria and Switzerland, the rates are similar.

Here’s the problem: ad blockers don’t just block ads. They block tracking scripts. The standard GA4 JavaScript snippet (gtag.js loaded from googletagmanager.com) is on every major ad blocker’s default filter list. If a visitor has an ad blocker active, your GA4 tag never fires. That visitor does not exist in your analytics. No pageview, no events, no conversion — nothing.

This isn’t a fringe issue. If your website gets 100,000 monthly visitors, roughly 30,000 of them are invisible to your GA4 setup. You’re making marketing decisions based on 70% of reality.

Safari ITP and cookie limits

Apple’s Intelligent Tracking Prevention (ITP) in Safari limits client-side cookies to a maximum lifetime of 7 days. For visitors who come to your site via a campaign link or ad click (any URL with query parameters that Safari classifies as tracking-related), that window drops to 24 hours.

What this means in practice: a returning Safari user who visited your site 8 days ago looks like a new user. Your returning visitor metrics are inflated with false “new” visits. Attribution is broken because the original source was forgotten. Multi-touch attribution models become unreliable because Safari users — who represent 20-25% of web traffic in DACH — keep resetting.

This isn’t something you can fix with a cookie consent banner or a GA4 configuration change. It’s enforced at the browser level.

Consent rejection rates: 30-45% in Germany

Since the Telekommunikation-Telemedien-Datenschutz-Gesetz (TTDSG) took effect and German data protection authorities started actively enforcing cookie consent requirements, properly implemented consent banners in Germany see rejection rates between 30% and 45%. Usercentrics published benchmark data in 2024 showing average opt-in rates of 54-65% across their DACH customer base — meaning 35-46% of visitors either reject analytics cookies or simply close the banner without consenting.

If you’re running a GDPR-compliant consent setup (and you should be — the BayLDA has been issuing fines for non-compliant banners since 2023), then a third to nearly half of your visitors never load GA4 at all.

Add up these three factors. Ad blockers take 30%. ITP corrupts Safari data. Consent rejection removes another 30-45%. The overlap between these groups isn’t total — some visitors have an ad blocker and would have rejected consent anyway — but the combined data loss is real and significant.

Client-side GA4

Data path breaks in ~25–40% of sessions.

Three independent breakage points in the client-side path — ad blockers, ITP cookie expiry, consent rejection — each cutting a slice of visible traffic.

Server-side tracking

First-party endpoint. Full path. EU-controlled.

Every hop runs on infrastructure you control. Consent and IP handling happen server-side, where you can enforce them. Data stays in the EU end-to-end.

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.

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. Here’s what a typical migration looks like for a company running standard client-side GA4.

Typical timeline: 4-6 weeks

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.

Phase 1: Audit existing tracking (week 1)

We map every tag, trigger, and variable in your current GTM container. We document which events actually matter for your reporting and which are noise. We check your consent management integration. My brother Denis and I have a running joke that 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.

Phase 2: Architecture and GTM Server-Side setup (week 2-3)

We 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 the server-side tags, and set up the first-party domain mapping.

Phase 3: Parallel run and data validation (week 3-5)

This is the critical phase. We run both client-side and server-side tracking simultaneously and compare the data. This tells us 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 during this phase — that’s the data you’ve been losing.

Phase 4: Cutover and monitoring (week 5-6)

Once we’ve validated the data, we cut over to server-side as the primary tracking method, set up monitoring and alerting, and document everything for your team.

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.

Frequently asked questions

The FAQ section at the top of this page covers the most common questions we hear. If yours isn’t answered there, get in touch.

Ready to fix your tracking?

We’ve migrated tracking for companies with 5 to 120+ web properties. If your GA4 data doesn’t match reality, book a 20-minute call or see our Data Engineering practice.