Client-seitiges Tracking verliert Daten an Adblocker und Safari-Cookie-Limits. Mit Cloudflare Zaraz oder einem Worker-Proxy vor einem sGTM-Container holst du dir First-Party-Kontext und Datenhoheit zurück, ohne Google-Cloud-Zauber.
Warum client-seitiges Tracking 2026 nicht mehr reicht
Wenn du GA4 klassisch per gtag.js einbindest, läuft jede Messung im Browser deines Besuchers und geht direkt an google-analytics.com. Genau dort setzt das Problem an. Safari kappt client-seitig gesetzte Cookies nach sieben Tagen (ITP), Firefox blockt Third-Party-Kontexte, und je nach Branche laufen 15 bis 30 Prozent deiner B2B-Besucher mit uBlock Origin oder einem Pi-hole, die Requests an Google-Domains schlicht verwerfen. Das Ergebnis: Wiederkehrer werden als neue Nutzer gezählt, Conversions fehlen, und dein Attributionsmodell rechnet auf Sand.
Server-Side Tagging dreht den Datenfluss um. Statt dass der Browser direkt zu Google funkt, schickt er das Event an einen Endpunkt auf deiner eigenen Domain. Ein Tagging-Server nimmt es entgegen, und erst von dort geht die Messung per Measurement Protocol an GA4. Du gewinnst First-Party-Kontext, spürbar bessere Datenqualität und volle Kontrolle darüber, welche Felder Google überhaupt zu sehen bekommt.
Der Datenfluss im Detail
Technisch passieren drei Schritte. Erstens lädt der Browser weiterhin ein Tag (klassisch gtag.js oder ein serverseitig ausgespielter Client), aber die Konfiguration zeigt auf deinen First-Party-Endpunkt statt auf Google. Zweitens landet der GA4-Payload auf deinem Tagging-Server, wo du ihn lesen, anreichern, kürzen oder verwerfen kannst. Drittens leitet der Server das Event an google-analytics.com/g/collect weiter, jetzt Server-zu-Server, unsichtbar für Adblocker im Browser.
Der entscheidende Hebel ist server_container_url. In der GA4-Konfiguration setzt du:
gtag('config', 'G-XXXXXXX', { server_container_url: 'https://sst.deinedomain.de', transport_url: 'https://sst.deinedomain.de' });
Ab jetzt gehen alle Hits an sst.deinedomain.de. Weil diese Subdomain zu deiner Registrable Domain gehört, ist das ein echter First-Party-Request. Kein Cross-Site-Kontext, keine Third-Party-Blockliste greift.
Zwei Cloudflare-Wege: Zaraz oder Worker-Proxy
Cloudflare bietet dir zwei realistische Architekturen, je nach Anspruch.
- Cloudflare Zaraz: Ein am Edge laufender Tag-Manager, der GA4 als fertige Komponente mitbringt. Die Events werden direkt aus Cloudflares Netzwerk an Google geschickt, ohne dass du einen eigenen Container betreibst. Konfiguration komplett im Dashboard, kein
gtag.jsim Browser nötig. Ideal, wenn du schnell und ohne Infrastruktur starten willst. - Worker-Proxy vor sGTM: Du betreibst einen Server-Side-GTM-Container (typisch auf Google Cloud Run) und stellst einen Cloudflare Worker davor, der die First-Party-Subdomain terminiert. Der Worker reicht Requests an den Container weiter. Das gibt dir die volle sGTM-Oberfläche mit Triggern, Variablen und mehreren Zielen (GA4, Meta CAPI, Ads) an einer Stelle.
Faustregel: reines GA4 und wenig Aufwand, dann Zaraz. Mehrere Zielsysteme, komplexe Transformationen und ein Team, das GTM kennt, dann der Worker-Proxy vor sGTM.
Setup: First-Party-Endpunkt mit Worker und sGTM
Für die Worker-Variante brauchst du vier Bausteine. Erstens einen sGTM-Container in Google Tag Manager (Container-Typ Server) plus ein Cloud-Run-Deployment über die von Google generierte Setup-URL. Zweitens eine Subdomain wie sst.deinedomain.de, deren DNS-Eintrag in Cloudflare liegt und orange proxied (also über Cloudflare läuft, nicht grau/DNS-only).
Drittens der Worker, der die Subdomain-Route bedient und an Cloud Run weiterreicht. Im Kern reicht ein schlanker Fetch-Proxy:
export default { async fetch(request, env) { const url = new URL(request.url); url.hostname = env.SGTM_HOST; return fetch(url, request); } }
Deployen per npx wrangler deploy, die Route sst.deinedomain.de/* im Dashboard oder in wrangler.toml binden. Viertens passt du das Web-Tag an, sodass es gegen sst.deinedomain.de sendet. Ein Aufruf von https://sst.deinedomain.de/healthy sollte danach ok liefern, dann steht der Endpunkt.
First-Party-Cookies richtig setzen (FPID)
Der eigentliche Gewinn steckt im Cookie-Handling. Setzt der Browser das _ga-Cookie per JavaScript, gilt in Safari die ITP-Grenze von sieben Tagen. Danach ist der Nutzer für dich ein Fremder. Ein Tagging-Server umgeht das, indem er die Identität serverseitig als HttpOnly-Cookie schreibt, den sogenannten FPID (First Party Identifier).
Ein per Set-Cookie vom Server gesetztes Cookie unterliegt der ITP-7-Tage-Regel nicht und kann die volle Laufzeit behalten:
Set-Cookie: FPID=...; Max-Age=63072000; Path=/; Secure; HttpOnly; SameSite=Lax
In sGTM aktivierst du dafür im GA4-Client die Option FPID setzen. Der Server generiert die ID, spielt sie als HttpOnly-Cookie aus (für JavaScript und Adblocker unsichtbar) und nutzt sie zur Nutzer-Erkennung. Wiederkehrer bleiben dadurch auch nach zwei Jahren zuordenbar, statt alle sieben Tage neu gezählt zu werden.
Consent, DSGVO und Validierung
Server-Side Tagging verlagert die Datenverarbeitung, es hebelt keine Einwilligung aus. Nach TTDSG (§25) und DSGVO brauchst du weiterhin ein Consent-Banner, bevor du Analytics-Cookies setzt oder Daten an Google gibst. Nutze Consent Mode v2: Ohne Einwilligung sendet der Client nur pseudonyme, cookielose Pings, und dein Server darf so konfiguriert sein, dass er ohne analytics_storage=granted nichts an GA4 weiterleitet.
Der Vorteil des eigenen Servers: Du kannst PII vor der Weitergabe an Google entfernen. IP-Adresse kürzen oder gar nicht durchreichen, E-Mail-Parameter aus Query-Strings streichen, Roh-Payloads erst gar nicht loggen. Diese Kontrolle ist in vielen Auftragsverarbeitungs-Setups genau das Argument, das die Datenschutz-Abteilung überzeugt.
Zum Testen nutzt du GA4 DebugView und den Vorschaumodus von sGTM. Prüfe, ob Hits am Server ankommen, ob der FPID gesetzt wird und ob bei abgelehntem Consent wirklich nichts durchgeht. Ein kurzer Blick in die Cloudflare-Worker-Logs zeigt dir zusätzlich, ob die Subdomain sauber proxied.
Kosten und wann sich der Aufwand lohnt
Die Rechnung ist überschaubar. Cloudflare Zaraz ist bis etwa eine Million Events pro Monat kostenlos, danach nutzungsbasiert. Ein Worker liegt im Free-Tier bei 100.000 Requests pro Tag, der bezahlte Plan startet bei 5 US-Dollar im Monat für zehn Millionen Requests. Der sGTM-Container auf Cloud Run kostet dich je nach Traffic und Instanzkonfiguration ungefähr 30 bis 50 Euro im Monat für eine belastbare Always-On-Instanz.
Für einen kleinen Blog ist der Aufwand nicht nötig. Sobald aber Werbebudget an GA4-Signalen hängt (Meta CAPI, Google Ads Enhanced Conversions, Attribution über mehrere Sessions), zahlt sich der Umbau schnell aus. Agenturen und E-Commerce-Teams, die pro wiedergefundenem Nutzer und pro nicht verlorener Conversion rechnen, holen die 50 Euro Infrastruktur meist im ersten Kampagnen-Reporting wieder rein. Wichtig ist, dass eine Person das Setup versteht, sauber übergibt und dokumentiert, damit der First-Party-Endpunkt nicht zur Blackbox wird.