GA4 Server-side Tracking: So richten Sie GA4 in einem Server-Container ein

Leiten Sie GA4 über einen Server-Container: Google-Tag, GA4-Client und -Tag, Server-Managed-Cookies, das Measurement Protocol und ein Test auf Doppelzählung.

Małgorzata Poddębniak

Content-Marketerin

13. August 2024

Aktualisiert am 13. November 2026

21 Min. Lesezeit

GA4 Server-side Tracking sendet Ihre Google-Analytics-4-Events über einen Server-Container, den Sie kontrollieren, bevor sie Google erreichen. Sie gehen also nicht mehr direkt aus dem Browser Ihrer Besucher an Google. Das Google-Tag läuft weiter auf Ihrer Website, sendet seine Requests aber an Ihre eigene Subdomain. Dort nimmt der Server-Container sie an und leitet sie an GA4 weiter.

An der Übergabe zwischen den beiden Containern scheitern die meisten GA4-Setups. Sendet ein Tag im Browser ein Event weiter direkt an Google, während dasselbe Event auch über den Server läuft, zählt GA4 es doppelt. GA4 hat keine Event-ID, um die beiden Kopien zusammenzuführen. Nur Käufe, die eine Transaktions-ID wiederholen, werden verworfen.

Dieser Guide zeigt, was Web-Container und Server-Container jeweils tun, welche zwei serverseitigen Routen es zu GA4 gibt, wie Sie beide Container in fünf Schritten einrichten und wie Sie testen, dass jedes Event genau einmal ankommt.

Was ist GA4 Server-side Tracking?

GA4 Server-side Tracking leitet Ihre Google-Analytics-4-Events über einen Server-Container auf Ihrer eigenen Subdomain. Das Google-Tag im Browser sendet jedes Event dorthin, ein GA4-Client nimmt es an, und ein GA4-Tag leitet es an Ihre Property weiter. Dazwischen entscheiden Sie, welche Parameter Google erhält.

Sie behalten Ihre bestehende GA4-Property. Browserseitige und serverseitige Erfassung können darin parallel laufen, solange jedes Event nur einen der beiden Wege nimmt.

Warum GA4-Zahlen von denen Ihrer Werbeplattformen abweichen, lesen Sie in warum Ihr GA4 ROAS ungenau ist.

Die wichtigsten Vorteile

Wiederkehrende Besucher bleiben erkennbar

GA4 erkennt einen wiederkehrenden Besucher an einer Client-ID, die in einem Cookie gespeichert ist. Löscht der Browser dieses Cookie zu früh, zählt der nächste Besuch als neuer Nutzer, und eine spätere Conversion verliert ihre ursprüngliche Quelle. Ein Server-Container auf Ihrer eigenen Domain kann das Client-ID-Cookie selbst setzen, und Browser gehen damit großzügiger um als mit einem Cookie, das JavaScript schreibt. Der Expertentipp unten erklärt die Details.

Weniger Events gehen im Browser verloren

Das Google-Tag sendet seine Requests an Ihre eigene Subdomain statt an die Erfassungsendpunkte von Google. Filter, die Requests an diese Domains blockieren, greifen dann nicht mehr, sodass mehr Seitenaufrufe und Conversions Ihre Property erreichen.

Kontrolle darüber, was Google erhält

Jedes Event läuft durch einen Server-Container, den Sie kontrollieren. Sie können Parameter entfernen oder umschreiben, bevor sie weitergeleitet werden, etwa um personenbezogene Daten zu entfernen, die in eine Seiten-URL geraten sind. Und Sie können dasselbe Event aus diesem einen Datenstrom auch an Google Ads oder andere Plattformen senden.

Daten von außerhalb Ihrer Website

Der Server-Container nimmt auch Requests aus Ihren eigenen Systemen an. Ein qualifizierter Lead in Ihrem CRM oder eine Rückerstattung im Backend Ihres Shops kann neben den Website-Events in GA4 landen, sodass Ihre Berichte zeigen, was nach dem Besuch passiert ist.

Server-side Tracking kann keine Interaktion wiederherstellen, die Ihre Website nie erfasst hat, und es ändert nichts daran, wozu ein Besucher eingewilligt hat. Es ändert aber, wohin Ihre Daten nach dem Browser gehen und wer sie kontrolliert.

Reines Browser-Tracking und Server-side Tracking für GA4
Kriterium	Nur Browser	Server-side mit TAGGRS
Client-ID-Cookie	Nachteil: Browser können es früh löschen	Vorteil: Von Ihrer eigenen Subdomain gesetzt
Filter, die Google-Domains blockieren	Nachteil: Anfragen können blockiert werden	Vorteil: Anfragen gehen an Ihre eigene Subdomain
Personenbezogene Daten in Seiten-URLs	Nachteil: Wird mit dem Event gesendet	Vorteil: Vor dem Versand entfernt
Events aus Ihrem CRM oder Backend	Nachteil: Nicht erfasst	Vorteil: Neben Website-Events gesendet
Kontrolle darüber, was GA4 erhält	Nachteil: Begrenzt	Vorteil: Parameter entfernen oder umschreiben

„Bevor wir auf serverseitiges Tracking umgestiegen sind, haben wir immer öfter gemerkt, dass die Daten in unseren Dashboards weit auseinanderlagen. Klicks in Google Ads waren überhaupt nicht mit dem vergleichbar, was wir in Google Analytics gesehen haben. Bei Meta Ads war es genauso. Deshalb haben wir nach einer Lösung gesucht, und die war serverseitiges Tracking.“

Romy BrookhuisOnline Content Marketer, byteffekt

Web-Container, Server-Container oder beides?

GA4 Server-side Tracking braucht immer beide Container. Sie haben unterschiedliche Aufgaben, und keiner ersetzt den anderen.

Der Web-Container	Der Server-Container
Führt das Google-Tag und Ihre GA4-Event-Tags aus	Nimmt die Requests mit dem GA4-Client an
Liest den Data Layer: Seiten, Produkte, Bestellungen, Formulare	Leitet Events mit dem GA4-Tag an Ihre Property weiter
Erfasst Browserkontext wie die Seiten-URL und den Referrer	Entfernt oder ändert Parameter, bevor sie den Server verlassen
Liest den Einwilligungsstatus aus Ihrem Consent-Banner	Kann das Client-ID-Cookie von Ihrer eigenen Subdomain setzen

Einen Deduplizierungsschritt wie bei Meta gibt es hier nicht. Lassen Sie das Google-Tag auf Ihren Server-Container zeigen, dann nimmt jedes Event, das es sendet, genau einmal den Weg über den Server. Google bezeichnet hybride Setups, in denen einige Events direkt an GA4 gehen und andere über den Server, als üblich. Sie funktionieren, solange kein Event beide Wege nimmt.

Das einzige Sicherheitsnetz ist die Transaktions-ID. GA4 verwirft einen Kauf, der eine bereits vom selben Nutzer erhaltene Transaktions-ID wiederholt, und das nur bei Web-Streams. Senden Sie nie eine leere Transaktions-ID: GA4 behandelt jeden Kauf mit leerem Wert als Duplikat der anderen.

Wählen Sie im folgenden Checker Google Analytics 4 aus, um zu sehen, in welchen Container es gehört und wie Sie es einrichten.

Interaktives Tool

In welchen Container gehört deine Plattform?

Wähle eine Plattform und sieh, in welchen Container sie gehört, warum, und wie du sie richtig konfigurierst.

Google Analytics 4
Container:Beide ContainerWeb-Container + Server-Container.
Warum
GA4 ist die Grundlage jedes Server-side-Setups. Der GA4 Config-Tag läuft im Web-Container und sendet Daten an den Server-Container, der damit jeden nachgelagerten Tag versorgt, auch Google Ads. Ohne Server-side GA4 bekommt keine andere Plattform im Server-Container korrekte Daten.
Konfigurationsschritte
1. Füge den GA4 Config-Tag hinzuFüge in deinem Web-Container einen GA4-Konfigurationstag hinzu. Trag die Measurement ID ein und lass die Server-Container-URL auf deine First-Party-Tagging-Subdomain zeigen (z. B. sst.deinedomain.de).
2. Verbinde den Server-Container mit TAGGRSVerbinde deinen GTM-Server-Container mit TAGGRS. Deine Tagging-Subdomain muss eine First-Party-Subdomain der getrackten Domain sein.
3. Füge den GA4-Server-Tag hinzuFüge in deinem Server-Container den GA4-Tag hinzu. Er empfängt automatisch die Events, die der GA4 Config-Tag im Web-Container weiterleitet.
4. Prüfe den DatenflussNutze den Vorschaumodus von GTM und die GA4 DebugView, um vor dem Livegang zu prüfen, ob Events im Server-Container ankommen.
Zur Server-Seite wechseln (Google Analytics 4)
Google Ads
Container:Nur Server-ContainerAlle Daten kommen vom Server. Kein Browser-Tag.
Warum
Server-side Measurement für Google Ads hängt komplett davon ab, dass GA4 zuerst in beiden Containern eingerichtet ist. Sobald GA4 steht, laufen alle Google Ads-Tags (Conversion Tracking und Remarketing) ausschließlich im Server-Container.
Konfigurationsschritte
1. Richte zuerst GA4 in beiden Containern einGoogle Ads ist fest von GA4 abhängig. Schließ das Server-side-Setup von GA4 ab, bevor du Google Ads-Tags hinzufügst.
2. Füge den Conversion Linker-Tag hinzuFüge in deinem Server-Container den Conversion Linker-Tag hinzu. Er verknüpft Klickdaten mit Conversion-Events. Dieser Schritt wird am häufigsten vergessen, und ohne ihn stimmt die Attribution nicht.
3. Füge den Google Ads Conversion Tracking-Tag hinzuFüge in deinem Server-Container den Google Ads Conversion Tracking-Tag hinzu. Trag Conversion-ID und Conversion-Label aus deinem Google Ads-Konto ein.
4. Füge den Google Ads Remarketing-Tag hinzu (optional)Wenn du Remarketing-Kampagnen schaltest, füge den Google Ads Remarketing-Tag im Server-Container hinzu. Er hat dieselbe Abhängigkeitskette wie Conversion Tracking.
5. Teste mit dem Tag AssistantPrüfe die ganze Kette: GA4 Config (Web) → GA4-Server-Tag → Conversion Linker → Google Ads-Tag. Prüfe, ob Conversions in Google Ads → Messung → Conversions erscheinen.
Zur Server-Seite wechseln (Google Ads)
Meta / Facebook
Container:Beide ContainerWeb-Container + Server-Container.
Warum
Meta empfiehlt, Browser-Pixel und Server-CAPI gleichzeitig laufen zu lassen, um Match-Raten und Event-Abdeckung zu maximieren. Mit beiden steigt die Chance, dass jede Conversion korrekt zugeordnet wird, auch wenn das Browsersignal blockiert oder abgeschwächt ist.
Deduplizierung erforderlich. Wenn Browser-Pixel und Server-CAPI für dasselbe Event feuern, erhält Meta es doppelt. Übergib im Browser- und im Server-Event dieselbe event_id. Meta dedupliziert anhand dieser ID und zählt die Conversion einmal.
Konfigurationsschritte
1. Lass das Meta Pixel im Web-ContainerDein bestehender Meta Pixel-Tag bleibt im Web-Container. Entferne ihn nicht: Das Browsersignal verbessert die Match-Raten.
2. Füge den Meta CAPI-Tag im Server-Container hinzuFüge in deinem Server-Container den Meta Conversions API-Tag hinzu. Trag deine Pixel-ID und deinen Meta-Zugriffstoken ein.
3. Richte die Deduplizierung mit event_id einErzeuge für jedes Event eine eindeutige event_id (z. B. eine UUID oder einen String auf Basis eines Zeitstempels). Übergib dieselbe event_id im Pixel-Event im Browser und im CAPI-Event auf dem Server. Meta gleicht sie ab und zählt einmal.
4. Teste im Meta Events ManagerGeh im Meta Events Manager auf Test Events. Prüfe, ob Events aus Browser und Server ankommen und ob doppelte Events korrekt dedupliziert werden.
Zur Server-Seite wechseln (Meta / Facebook)
TikTok
Container:Beide ContainerWeb-Container + Server-Container.
Warum
TikTok empfiehlt, Pixel und Events API zusammen mit Event-Deduplizierung zu nutzen, um die Performance zu maximieren. Das Pixel allein verpasst Conversions durch Browser-Unterschiede und Verbindungsprobleme. Die Events API schließt diese Lücken. Lass beide parallel laufen und übergib eine übereinstimmende event_id, damit TikTok Duplikate zusammenführt.
Deduplizierung erforderlich. Wenn Pixel und Events API für dasselbe Event feuern, erhält TikTok es doppelt. Übergib im Browser- und im Server-Event dieselbe event_id. TikTok führt Duplikate anhand dieser ID zusammen und zählt die Conversion einmal.
Konfigurationsschritte
1. Lass das TikTok Pixel im Web-ContainerDein bestehender TikTok Pixel-Tag bleibt im Web-Container. Entferne ihn nicht: TikTok empfiehlt Pixel und Events API als doppeltes Setup.
2. Füge den TikTok Events API-Tag im Server-Container hinzuFüge in deinem Server-Container den TikTok Events API-Tag hinzu. Trag deine Pixel-ID und deinen TikTok-Zugriffstoken ein.
3. Richte die Deduplizierung mit event_id einErzeuge für jedes Event eine eindeutige event_id (z. B. eine UUID oder einen String auf Basis eines Zeitstempels). Übergib dieselbe event_id im Pixel-Event im Browser und im Events API-Event auf dem Server. TikTok gleicht sie ab und zählt einmal.
4. Prüfe das Hashing der NutzerdatenDer Server-Tag wandelt Nutzerdaten (E-Mail, Telefon) automatisch in Kleinbuchstaben um und hasht sie mit SHA256, bevor sie an TikTok gehen. Prüfe in den Tag-Einstellungen, ob das aktiv ist.
5. Prüfe im TikTok Events ManagerGeh zu TikTok Ads Manager → Assets → Events → Web Events (oder Test Events). Prüfe, ob Events aus Browser und Server ankommen und ob übereinstimmende Events dedupliziert werden.
Zur Server-Seite wechseln (TikTok)
Pinterest
Container:Beide ContainerWeb-Container + Server-Container.
Warum
Pinterest folgt derselben Logik mit zwei Signalen wie Meta: Browser-Tag und Conversions API laufen parallel. Zusammen geben sie Pinterest das genaueste Bild deiner Conversions und verbessern Attribution und Kampagnenoptimierung.
Deduplizierung erforderlich. Sind Browser-Tag und Conversions API beide aktiv, erhält Pinterest jedes Event aus zwei Quellen. Übergib im Browser- und im Server-Event denselben Deduplizierungsschlüssel, damit Pinterest jede Conversion einmal zählt.
Konfigurationsschritte
1. Lass den Pinterest Tag im Web-ContainerDein bestehender Pinterest Tag bleibt im Web-Container. Er feuert weiterhin bei Events im Browser.
2. Füge den Pinterest Conversions API-Tag im Server-Container hinzuFüge in deinem Server-Container den Pinterest Conversions API-Tag hinzu. Trage deine Tag-ID und den Zugriffstoken ein, den du im Ads Manager erzeugst.
3. Richte die Event-Deduplizierung einÜbergib im Browser- und im Server-Event denselben Deduplizierungsschlüssel. Pinterest gleicht damit Conversion-Events ab und dedupliziert sie.
4. Teste mit dem Pinterest Tag HelperNutze die Chrome-Erweiterung Pinterest Tag Helper und den Pinterest Events Manager, um zu prüfen, ob Events über beide Kanäle ankommen und korrekt dedupliziert werden.
Zur Server-Seite wechseln (Pinterest)
LinkedIn
Container:Beide ContainerWeb-Container + Server-Container.
Warum
Der LinkedIn Insight Tag läuft client-side im Web-Container, für den Aufbau von Zielgruppen und für Seitenaufrufe. Conversion-Events werden zusätzlich server-side über LinkedIn CAPI gesendet. LinkedIn nennt das ein redundantes Setup: Stimmen beide überein, behält LinkedIn das Insight Tag-Event und verwirft die CAPI-Kopie. Der Serverweg deckt trotzdem die Fälle ab, in denen der Browser-Tag nie feuert.
Deduplizierung erforderlich. LinkedIn nutzt eine eventId, um Conversion-Events aus Browser und Server abzugleichen. Übergib in beiden dieselbe eventId. Stimmen sie überein, behält LinkedIn das Insight Tag-Event und verwirft die Kopie aus der Conversions API.
Konfigurationsschritte
1. Lass den LinkedIn Insight Tag im Web-ContainerDer Insight Tag bleibt im Web-Container, für den Aufbau von Zielgruppen und das Tracking von Seitenaufrufen.
2. Füge den LinkedIn CAPI-Tag im Server-Container hinzuFüge in deinem Server-Container den LinkedIn Conversions API-Tag hinzu. Trag deine LinkedIn Ad Account ID und deinen Zugriffstoken ein.
3. Richte die Deduplizierung mit eventId einÜbergib im Insight Tag im Browser und im CAPI-Event auf dem Server dieselbe eventId. LinkedIn dedupliziert damit. Hinweis: conversion_id kennzeichnet die Conversion-Regel und ist nicht der Deduplizierungsschlüssel.
4. Prüfe im LinkedIn Campaign ManagerGeh im LinkedIn Campaign Manager auf Analyze → Conversion Tracking. Prüfe, ob Insight Tag- und CAPI-Events angezeigt werden und ob redundante Treffer von der CAPI-Zahl abgezogen werden.
Zur Server-Seite wechseln (LinkedIn)
Snapchat
Container:Beide ContainerWeb-Container + Server-Container.
Warum
Snap Pixel läuft im Web-Container, die Snap Conversions API im Server-Container. Beide Kanäle laufen parallel. Der Server-Tag normalisiert und hasht Nutzerparameter automatisch, darunter E-Mail, Mobile-ID, IP-Adresse und Telefonnummer, bevor sie an Snap gehen.
Deduplizierung erforderlich. Übergib auf beiden Seiten dieselbe ID: client_dedup_id im Snap Pixel im Browser und event_id in den Conversions API-Events auf dem Server. Snapchat dedupliziert damit und zählt jede Conversion einmal.
Konfigurationsschritte
1. Lass das Snap Pixel im Web-ContainerDein bestehender Snap Pixel-Tag bleibt im Web-Container. Er sendet weiterhin Events aus dem Browser.
2. Füge den Snapchat Conversions API-Tag im Server-Container hinzuFüge in deinem Server-Container den Snapchat CAPI-Tag hinzu. Trag deine Snap Pixel-ID und deinen Zugriffstoken ein.
3. Prüfe die Normalisierung der NutzerdatenDer Tag normalisiert und hasht E-Mail, Telefon, IP-Adresse und Mobile-ID automatisch mit SHA256. Prüfe in der Tag-Konfiguration, ob das aktiviert ist.
4. Richte die Deduplizierung einÜbergib eine ID als client_dedup_id im Snap Pixel und als event_id in der Conversions API, damit Snapchat korrekt dedupliziert.
5. Teste im Snap Events ManagerGeh zu Snap Ads Manager → Events Manager. Prüfe, ob Events über beide Kanäle ankommen und dedupliziert werden.
Zur Server-Seite wechseln (Snapchat)
Klaviyo
Container:Nur Server-ContainerAlle Daten kommen vom Server. Kein Browser-Tag.
Warum
Klaviyo unterstützt keine Event-Deduplizierung. Laufen Browser- und Server-Tracking gleichzeitig, kommt jedes Event doppelt an. Richte Klaviyo deshalb nur server-side ein. Der Tag kommuniziert direkt mit der Klaviyo API und kann Kontakte anlegen, Aktivitäten auf deiner Website tracken und Event-Parameter senden.
Konfigurationsschritte
1. Entferne einen bestehenden Klaviyo-Browser-TagWenn du ein Klaviyo-JavaScript-Snippet in deinem Web-Container oder im Code deiner Website hast, deaktiviere es, bevor du den Server-side-Tag hinzufügst. Mit beiden entstehen doppelte Events.
2. Füge den Klaviyo-Tag im Server-Container hinzuFüge in deinem Server-Container den Klaviyo-Tag hinzu. Trag deinen Klaviyo Public API Key und Private API Key ein.
3. Konfiguriere die unterstützten AktionenDer Tag unterstützt drei Aktionstypen: Events tracken, einen Kontakt anlegen oder aktualisieren und einen Kontakt anlegen oder aktualisieren und gleichzeitig ein Event tracken. Leg den Aktionstyp pro Trigger fest.
4. Teste über den Aktivitäten-Feed in KlaviyoGeh in deinem Klaviyo-Konto zu Profiles. Löse ein Test-Event aus und prüfe, ob es ohne Duplikate im Aktivitäten-Feed des Profils erscheint.
Zur Server-Seite wechseln (Klaviyo)
ActiveCampaign
Container:Nur Server-ContainerAlle Daten kommen vom Server. Kein Browser-Tag.
Warum
ActiveCampaign wird über die API aus dem Server-Container angebunden. Der Tag trackt Events, legt Kontakte an oder aktualisiert sie und kann beide Aktionen in einem Aufruf kombinieren. Richte es nur server-side ein, damit saubere Daten ohne Duplikate in deinem CRM landen.
Konfigurationsschritte
1. Hol dir deine API-Zugangsdaten von ActiveCampaignGeh in deinem ActiveCampaign-Konto zu Settings → Developer. Dort findest du deine API URL und deinen API Key.
2. Füge den ActiveCampaign-Tag im Server-Container hinzuFüge in deinem Server-Container den ActiveCampaign-Tag hinzu. Trag API URL und API Key in der Tag-Konfiguration ein.
3. Wähle den AktionstypWähle einen von drei Aktionstypen: Track event, Create or update contact oder Create or update contact + track event. Leg für jede Aktion den passenden Trigger fest.
4. Ordne Event- und Kontaktparameter zuLeg fest, welche Data-Layer-Variablen zu den Event-Namen in ActiveCampaign, der E-Mail-Adresse des Kontakts und eventuellen benutzerdefinierten Feldern gehören.
5. Teste in ActiveCampaignLöse ein Test-Event aus und prüfe, ob es in ActiveCampaign unter Contacts → Activity oder Reports → Event Tracking erscheint.
Zur Server-Seite wechseln (ActiveCampaign)
Hotjar
Container:Nur Web-ContainerKein Server-side-Setup nötig.
Warum
Hotjar zeichnet Sessions auf, erstellt Heatmaps und erfasst Nutzerverhalten direkt im Browser. Es beobachtet dafür Interaktionen im DOM (Mausbewegungen, Scrolltiefe und Klicks), die es nur im Browser gibt. Es gibt keine server-side Variante, und sie wird auch nicht gebraucht: Hotjar sendet keine Conversion-Signale an Werbeplattformen, also gibt es hier kein Signalverlust-Problem zu lösen. Lass es im Web-Container und lass deinen Server-Container unverändert.
Konfigurationsschritte
1. Lass Hotjar im Web-ContainerFüge den Hotjar-Tracking-Code über einen benutzerdefinierten HTML-Tag in deinem Web-Container hinzu oder bau ihn direkt in den <head> deiner Website ein. Beides ist richtig.
2. Keine Änderungen am Server-Container nötigFüge Hotjar nicht zu deinem Server-Container hinzu. Es gibt keine API-Entsprechung, und server-side geroutet würde es gar nicht mehr funktionieren.
Microsoft Clarity
Container:Nur Web-ContainerKein Server-side-Setup nötig.
Warum
Microsoft Clarity funktioniert wie Hotjar: Session Recordings und Heatmaps, direkt im Browser erfasst. Es beobachtet echte Interaktionen im DOM und kann außerhalb des Browsers nicht funktionieren. Es ist kostenlos, lässt sich nativ mit GA4 verbinden und wird oft neben Server-side-Setups genutzt, nur eben nicht als Teil davon.
Konfigurationsschritte
1. Füge Clarity über den GTM-Web-Container hinzuFüge in deinem Web-Container einen benutzerdefinierten HTML-Tag mit dem Microsoft Clarity-Skript hinzu. Lass ihn auf allen Seiten feuern.
2. Mit GA4 verbinden (optional)Verknüpfe im Clarity-Dashboard deine GA4-Property, um Session Recordings neben GA4-Segmenten zu sehen. Diese Verbindung richtest du in Clarity ein, in GTM ändert sich nichts.
3. Keine Änderungen am Server-Container nötigClarity hat keine Server-side-API. Lass es rein client-side.
LiveChat
Container:Nur Web-ContainerKein Server-side-Setup nötig.
Warum
LiveChat fügt ein Chat-Widget in das DOM des Browsers ein und erkennt Seitenaktivität, Inaktivität und Scrollverhalten, um Gespräche im richtigen Moment zu starten. Dafür braucht es direkten Zugriff auf den Browser. Das Widget lässt sich nicht aus einem Server-Container laden oder steuern.
Konfigurationsschritte
1. Füge LiveChat über den GTM-Web-Container hinzuFüge in deinem Web-Container einen benutzerdefinierten HTML-Tag mit dem LiveChat-Tracking-Snippet hinzu. Lass ihn auf allen Seiten feuern.
2. Keine Änderungen am Server-Container nötigLiveChat hat keine Server-side-API für die Auslieferung des Widgets. Es ist bewusst ein reines Browser-Tool.
Zendesk Chat
Container:Nur Web-ContainerKein Server-side-Setup nötig.
Warum
Zendesk Chat (Web Widget) zeigt eine Live-Chat-Oberfläche direkt im Browser. Es nutzt clientseitiges JavaScript, um das Widget anzuzeigen, Besucherverhalten zu erkennen und Gespräche in Echtzeit zu steuern. Wie alle Chat-Widgets dieser Art hängt es komplett vom Browser ab und lässt sich nicht über einen Server-Container leiten.
Konfigurationsschritte
1. Füge das Zendesk Web Widget über den GTM-Web-Container hinzuFüge in deinem Web-Container einen benutzerdefinierten HTML-Tag mit dem Web Widget-Snippet aus deinem Zendesk-Konto hinzu (Admin Center → Channels → Messaging). Lass ihn auf allen Seiten feuern.
2. Keine Änderungen am Server-Container nötigDas Zendesk Web Widget funktioniert nur im Browser. Eine Server-side-Konfiguration ist weder nötig noch möglich.
Typeform
Container:Nur Web-ContainerKein Server-side-Setup nötig.
Warum
Eingebettete Formulare und Pop-ups von Typeform laufen komplett im Browser. Sie nutzen clientseitiges JavaScript, um das Formular anzuzeigen, auf Eingaben zu reagieren und die Anzeigelogik auszulösen (nach Scrollen, Zeit oder Exit Intent). Typeform bietet zwar eine Responses API, um Einsendungen von Server zu Server abzurufen, aber das Embed selbst funktioniert nur im Browser und gehört in den Web-Container.
Konfigurationsschritte
1. Bette Typeform über den GTM-Web-Container einFüge in deinem Web-Container einen benutzerdefinierten HTML-Tag mit dem Typeform-Embed-Snippet hinzu oder nutze die Standard-Einbettung mit <script> und <div>. Leg den Trigger nach deiner Anzeigelogik fest (alle Seiten, eine bestimmte Seite oder ein benutzerdefiniertes Ereignis).
2. Keine Änderungen am Server-Container nötigDas Typeform-Embed läuft nur client-side. Wenn du Einsendungen für das Conversion-Tracking in deinen Data Layer schreiben willst, nutze die Hidden Fields von Typeform oder eine Integration über Webhook → Server. Das Embed selbst bleibt im Web-Container.

Wählen Sie Ihre serverseitige Route

Es gibt zwei Wege, serverseitige Daten in GA4 zu bringen. Sie decken unterschiedliche Events ab, deshalb nutzen viele Setups beide.

Route	Geeignet für	Gut zu wissen
Server-side GTM mit dem GA4-Client	Website-Events: Seitenaufrufe, E-Commerce-Events, Formularübermittlungen	Erfordert das Google-Tag im Browser und einen Server-Container. Volle Kontrolle über Parameter und Cookies.
Measurement Protocol	Events außerhalb der Website, etwa eine CRM-Aktualisierung oder eine Rückerstattung	Google hat es als Ergänzung zur Tag-basierten Erfassung entwickelt. Ein Event braucht die Client-ID aus dem Browser, um in die Customer Journey eines Nutzers zu passen, und eine Session-ID, gesendet innerhalb von 24 Stunden nach Sitzungsbeginn, um dieser Sitzung zugerechnet zu werden.

Measurement-Protocol-Requests können über einen Measurement-Protocol-Client auch an Ihren Server-Container gehen, sodass Events aus Ihrem Backend dieselben Filter durchlaufen wie Ihre Website-Events.

Server-side Tracking und die DSGVO

Mit Server-side Tracking haben Sie einen zentralen Ort, an dem Sie Einwilligungsentscheidungen und Datenminimierung anwenden, bevor etwas Google erreicht. Mit TAGGRS entscheiden Sie, welche Parameter weitergeleitet werden, und Sie können sensible Felder wie IP-Adressen oder User-IDs filtern oder anonymisieren, bevor sie die Server von TAGGRS verlassen.

Beim server-side GTM-Hosting wählen Sie, wo Ihr Server Daten verarbeitet, auch an Standorten innerhalb der EU. Google gibt an, dass Google Analytics keine einzelnen IP-Adressen von Nutzern in der EU, der Schweiz oder dem Vereinigten Königreich protokolliert oder speichert.

Den Consent Mode richten Sie nur im Web-Container ein. Das Google-Tag sendet den Einwilligungsstatus des Besuchers mit jedem Request mit, und die Google-Tags in Ihrem Server-Container richten sich danach. Das unterstützt Grundsätze der DSGVO wie Datenminimierung und Zweckbindung. Eine Rechtsgrundlage für die Verarbeitung ersetzt es nicht, und Ihre Consent-Management-Plattform (CMP) muss weiterhin die Einwilligungsstatus setzen, bevor ein Tag auslöst. Mehr dazu in Server-side Tracking und die DSGVO, auf unserer Sicherheitsseite und in unserem Beitrag zu Google Consent Mode V2.

Expertentipp. GA4 erkennt einen wiederkehrenden Besucher an der Client-ID im _ga-Cookie, das das Google-Tag mit JavaScript schreibt. Safari löscht Cookies, die JavaScript schreibt, nach sieben Tagen ohne Besuch. Kommt jemand von einer Domain, die Safari als Cross-Site-Tracker eingestuft hat, auf eine URL mit Query-String, etwa mit UTM-Tags, begrenzt Safari sie auf 24 Stunden. Ein Besucher, der danach zurückkommt, zählt als neuer Nutzer, und seine Conversion verliert ihre ursprüngliche Quelle. Stellen Sie im Server-Container die Cookie-Option des GA4-Clients auf Server Managed. Das Client-ID-Cookie setzt dann Ihr eigener Server in der HTTP-Antwort, und dafür gelten diese Begrenzungen nicht, solange der Server auf Ihrer eigenen Domain läuft (siehe Schritt 1). Jeder GA4-Request muss dann allerdings über den Server-Container laufen.

GA4 Server-side Tracking einrichten

Unsere Dokumentation enthält Schritt-für-Schritt-Anleitungen für jeden Teil des Setups. Arbeiten Sie sie in dieser Reihenfolge durch.

Im folgenden Video zeigt Lowie Verschelden Schritt für Schritt, wie Sie GA4 Server-side Tracking einrichten.

1. Erstellen Sie einen Server-Container in Google Tag Manager

Im Server-Container kommen Ihre Events an, bevor sie an GA4 weitergeleitet werden. Er läuft auf einer First-Party-Tagging-URL auf Ihrer eigenen Domain, etwa sending.example.com. Eine Subdomain nur auf einen externen Dienst zeigen zu lassen, reicht nicht, denn Safari vergleicht IP-Adressen, bevor es entscheidet, ob es die Lebensdauer eines Cookies verlängert. Mehr zur Sieben-Tage-Begrenzung für Cookies in Safari und Same-Origin-Tracking.

Doku: Google Tag Manager einrichten

2. Richten Sie GA4 im Web-Container ein

Erstellen Sie in Ihrem Web-Container ein Google-Tag mit Ihrer GA4 Measurement ID, die Sie unter Admin, Data streams finden. Fügen Sie den Konfigurationsparameter server_container_url hinzu, mit der URL Ihres Server-Containers als Wert. Ab dann sendet das Tag seine Requests an Ihre Subdomain statt an Google.

Lösen Sie das Tag mit dem Trigger Initialization - All Pages aus. Er greift vor dem normalen Trigger All Pages, sodass UTM-Parameter zuverlässig erfasst werden und weniger Sitzungen als nicht zugewiesener Traffic enden. Mehr dazu, wie Sie nicht zugewiesenen Traffic in GA4 beheben.

Doku: GA4 in GTM einrichten

3. Erstellen Sie Ihre E-Commerce-Events

GA4 liest Käufe, Warenkörbe und Produktaufrufe aus dem Data Layer. Pushen Sie jedes Event mit den von Google empfohlenen Event-Namen, etwa add_to_cart und purchase, damit sich die Standard-E-Commerce-Berichte füllen. Geben Sie jedem Kauf eine eindeutige transaction_id, etwa die Bestellnummer. Das ist der einzige Wert, anhand dessen GA4 einen doppelten Kauf verwirft.

Doku: E-Commerce-Events in GTM

4. Erstellen Sie GA4-Event-Tags

Jedes Event, das Sie in GA4 haben möchten, bekommt im Web-Container ein GA4-Event-Tag, ausgelöst durch das passende Data-Layer-Event. Das Tag nutzt dieselbe Measurement ID wie Ihr Google-Tag, übernimmt also die URL des Server-Containers und sendet ebenfalls an Ihre Subdomain. Fügen Sie Parameter wie value, currency und items hinzu, um dem Event Kontext zu geben.

Doku: GA4-Event-Tags erstellen

5. Richten Sie GA4-Client und GA4-Tag im Server-Container ein

Im Server-Container nimmt der GA4-Client die Requests aus dem Browser an. Google installiert ihn in neuen Server-Containern standardmäßig, prüfen Sie aber unter Clients, ob er vorhanden ist. Erstellen Sie dann ein GA4-Tag, das mit einem benutzerdefinierten Trigger auslöst, Client Name equals GA4, damit es nur Events weiterleitet, die der GA4-Client angenommen hat.

Im GA4-Client wählen Sie auch zwischen JavaScript-Managed- und Server-Managed-Cookies. Beginnen Sie mit JavaScript Managed. Wechseln Sie zu Server Managed, sobald Ihr Server-Container auf Ihrer eigenen Domain läuft und der gesamte GA4-Traffic über ihn geht.

Doku: GA4-Tag im Server-Container einrichten

Testen Sie Ihr Setup

Öffnen Sie den Vorschaumodus Ihres Server-Containers und surfen Sie im geöffneten Fenster durch Ihre Website. Jeder Seitenaufruf und jedes Event sollte als Request erscheinen, den der GA4-Client annimmt und das GA4-Tag weiterleitet. Prüfen Sie danach DebugView oder den Echtzeitbericht in GA4.

Stellen Sie sicher, dass jedes Event genau einmal ankommt. Zwei page_view-Events bei einem Seitenaufruf bedeuten, dass ein Tag im Browser noch direkt an Google sendet. Im Netzwerk-Tab Ihres Browsers sollten GA4-Requests nur an Ihre eigene Subdomain gehen. Lösen Sie auch einen Testkauf aus und prüfen Sie, ob die Transaktions-ID im Server-Container zu Ihrer Bestellnummer passt. Tun Sie das, bevor Sie GA4 mit Ihren Werbeplattformen vergleichen, denn eine verdoppelte Event-Zahl verändert jede Rate in Ihren Berichten.

Doku: Setup testen

So hilft TAGGRS

TAGGRS hostet Ihren Server-Container, sodass Sie GA4 Server-side Tracking nutzen können, ohne selbst einen Server zu verwalten.

Server-side GTM-Hosting auf Ihrer eigenen Subdomain, für First-Party-Requests und längere Cookie-Laufzeiten, mit Serverstandorten in der EU.
Cookie Recovery hält das _ga-Cookie und die serverseitig verwalteten Client-ID-Cookies bis zu 13 Monate. Lesen Sie, wie Cookie Recovery funktioniert.
Das Enhanced Tracking Script ersetzt das Standard-GTM-Snippet, sodass Ad-Blocker weniger Requests erkennen und blockieren.
Fertige Vorlagen und eine Copy-Paste-Option für GTM, die das Setup beschleunigen.

Das TAGGRS-Dashboard zeigt, wie viele Ihrer Events Tracking Prevention im Browser und Werbeblocker sonst gestoppt hätten.

Das TAGGRS-Analytics-Dashboard: GA4-Events gesamt, die Auswirkung der Tracking Prevention und ein Diagramm mit dem täglichen Anteil der Events, die von Browser-Tracking-Prevention und Werbeblockern zurückgewonnen wurden

Häufig gestellte Fragen

Brauche ich für Server-side Tracking eine eigene GA4-Property?

Nein. Browserseitige und serverseitige Erfassung können in derselben GA4-Property laufen. Achten Sie darauf, dass jedes Event nur einen Weg nimmt, direkt zu Google oder über Ihren Server-Container, sonst zählt GA4 es doppelt.

Warum zählt GA4 meine Events nach der Umstellung auf server-side doppelt?

Meist, weil ein Tag im Browser dasselbe Event weiter direkt an Google sendet. GA4 hat keine Event-ID, um zwei Kopien zusammenzuführen. Es verwirft nur einen Kauf, der eine Transaktions-ID desselben Nutzers wiederholt. Lassen Sie das Google-Tag auf Ihren Server-Container zeigen und entfernen Sie alle direkten Tags für dieselben Events.

Kann ich CRM- oder Offline-Events serverseitig an GA4 senden?

Ja, mit dem Measurement Protocol, das Sie auch über Ihren Server-Container leiten können. Google hat es als Ergänzung zum Website-Tracking entwickelt. Senden Sie die Client-ID des Besuchers mit, damit das Event in seine Customer Journey passt, und eine Session-ID innerhalb von 24 Stunden nach Sitzungsbeginn, wenn das Event zu dieser Sitzung gehört.

Sollte ich JavaScript-Managed- oder Server-Managed-Cookies nutzen?

Beginnen Sie mit JavaScript Managed. Server Managed setzt das Client-ID-Cookie von Ihrem eigenen Server, und es hält in Safari länger. Das funktioniert aber nur, wenn Ihr Server-Container auf Ihrer eigenen Domain läuft und alle GA4-Requests über ihn gehen.

Ist GA4 Server-side Tracking DSGVO-konform?

Es unterstützt die DSGVO, weil Sie steuern und minimieren können, was Google erreicht, und weil Sie Daten in der EU verarbeiten können. Eine Rechtsgrundlage oder Einwilligung ersetzt es nicht. Der Consent Mode wird im Web-Container eingerichtet, und die Google-Tags im Server-Container folgen ihm. Mehr dazu in unserem Leitfaden zu Server-side Tracking und der DSGVO.

Über die Autorin oder den Autor

Małgorzata Poddębniak

Content-Marketerin

Gosia Poddębniak ist eine erfahrene Content-Marketerin und Autorin mit mehr als fünf Jahren Erfahrung in den Bereichen SaaS, Analytics und SEO. Bei TAGGRS entwickelt sie Marketingmaterialien für verschiedene Kanäle und betreut die Inhalte der Website, mit Themen wie Datenerfassung, Marketingoptimierung, Datenschutz, Tracking und Analytics.