Wir geben Ihnen einen Überblick über die wichtigsten Aspekte von Serverside Tracking:
Was ist Serverside Tracking?
Beim herkömmlichen Clientside Tracking erfasst der Browser die gewünschten Daten und sendet diese direkt an verschiedene Analysedienste/Datenempfänger (z.B. Google Analytics, Google Ads, Facebook).
flowchart LR Browser -->|direkt| GA4[GA4] Browser -->|direkt| Meta[Meta Pixel] Browser -->|direkt| Ads[Google Ads]
Client-Side Tracking: Datenfluss
Beim Serverside Tracking (Serverseitiges Tracking) werden die Daten hingegen zunächst an einen eigenen Server (Serverside Tag Manager) gesendet, der zwischengeschalten ist und die Daten an verschiedene Endpunkte weiterleiten kann.
flowchart LR Browser -->|1 Request| Server[Eigener Server] Server -->|kontrolliert| GA4[GA4] Server -->|kontrolliert| Meta[Meta CAPI] Server -->|kontrolliert| Ads[Google Ads]
Server-Side Tracking: Datenfluss
Daraus ergeben sich verschiedene Vorteile gegenüber dem klassischen Ansatz.
„Serverside Tagging" und „Serverside Tracking" werden meistens synonym verwendet. Sie sind konzeptionell ähnlich, aber genau genommen nicht ganz dasselbe. Wir erklären den Unterschied.
Vorteile von Serverside Tracking
Besserer Datenschutz
Beim Clientside Tracking werden Daten direkt vom Browser des Nutzers erfasst und an Drittanbieter (z.B. Google Analytics, Facebook) gesendet. Dabei werden technisch unvermeidlich die IP-Adressen der Nutzer sowie gewisse Browser-Fingerprints übertragen.
Beim Serverside Tracking hingegen werden die Daten zunächst an einen eigenen Server gesendet, der unter der Kontrolle des Website-Betreibers oder eines Auftragsverarbeiters steht. Dieser Server kann die Daten anonymisieren und nur die wirklich notwendigen Daten an die Drittanbieter weiterleiten. Dadurch wird der Datenschutz deutlich verbessert.
Bei der Übertragung von Daten in sogenannte unsichere Drittstaaten, deren Datenschutzstandards nicht dem europäischen Standard entsprechen, ist Serverside Tracking bzw. die Entfernung von personenbezogenen Daten aus den Datenströmen sogar zwingend notwendig, um die DSGVO einzuhalten.
Bessere Datenqualität / weniger Datenverlust
Serverside Tracking kann auch die Datenqualität verbessern, was vor allem zwei Gründe hat:
Eigene Domain
: Im Clientside Tracking werden Daten über bekannte Tracker-URLs (z.B.
google-analytics.com
,
googletagmanager.com
) übertragen. Viele Tracking-Blocker, Ad-Blocker und Sicherheitssoftware blockieren diese URLs, was zu
Datenverlust führt. Bei Serverside Tracking hingegen werden die Daten über die eigene Domain übertragen (z.B.
tagmanager.traffic3.net
), was die Blockade-Wahrscheinlichkeit deutlich reduziert.
Cookie-Qualität : Browser unterscheiden unterschiedliche Cookies nach ihrer Herkunft (Third-Party-Cookies, Client-Side First-Party-Cookies, Server-Side First-Party-Cookies) und behandeln sie unterschiedlich. Server-Side First-Party-Cookies haben die höchste Qualität und sind am wenigsten von Browser-Limitierungen betroffen.
Wichtig ist zudem, dass die Steigerung der Datenqualität nicht bei allen Toolanbietern und Implementierungsvarianten gleich stark ausfällt. Insbesondere die Standard-Installation des Serverside Google Tag Manager (SGTM) bringt weniger Datensteigerungen als andere Lösungen, weil die Vermeidung von Tracker-Blockern beim SGTM nicht so sehr im Vordergrund steht. Der SGTM ist zwar die günstigste Lösung, aber keinesfalls die beste Lösung.
Basierend auf unseren Erfahrungen sind folgende Steigerungen der Datenmenge realistisch:
| Implementierungsvariante | Tag Management System | Typische Steigerung der Datenmenge |
|---|---|---|
| Client-to-server | Google Serverside Tag Manager | 2–5 % |
| Client-to-server | Andere Lösungen mit verstecktem Tracking | 5–15 % |
| Server-to-server | diverse Anbieter | Bis zu 100 % (mit Consentless Tracking), ansonsten 100 % der zustimmenden Nutzer |
Die Höhe der Datensteigerung hängt zudem von weiteren Zielgruppen-Charakteristika ab. Beispielsweise ist in Desktop-Zielgruppen die Datensteigerung tendenziell höher als in Mobile-Zielgruppen, weil Mobile-Nutzer tendenziell weniger Tracking-Blocker verwenden.
Wann ist Consentless Tracking möglich?
Tracking ohne Einwilligung ist möglich, wenn weder Cookies noch personenbezogene Daten verarbeitet werden. Die DSGVO greift nur, sobald Personenbezug vorliegt. Aggregierte Messungen wie Umsatzzahlen oder Seitenaufrufe ohne Nutzersegmentierung lassen sich so consentlos erfassen. Der entscheidende Unterschied liegt im Empfänger: Die Übertragung an externe Dienste wie Google Analytics ist auch serverseitig nicht consentlos möglich, weil dabei IP-Adressen übermittelt werden. Auf dem eigenen Server hingegen ist die Verarbeitung ohne Consent zulässig, solange konsequent auf Personenbezug verzichtet wird.
Quantitative Datensteigerung ist aber nur ein Teil des Bildes. Oft wichtiger ist die Verbesserung der Attribution. Bei Apple-Geräten werden clientseitig gesetzte Cookies durch ITP nach 7 Tagen gelöscht, bei Klicks aus Werbenetzwerken sogar nach 24 Stunden. Eine Bestellung, die drei Tage nach dem ersten Werbekontakt erfolgt, wird im Clientside Tracking zwar gezählt, aber nicht mehr der richtigen Kampagne zugeordnet. Sie erscheint als "Direktzugriff" oder wird einer späteren Session mit anderem Touchpoint zugeschrieben. Das verfälscht nicht die Gesamtzahl der Conversions, aber die Zuordnung zu Kampagnen, Keywords und Kanälen, und damit die Grundlage für jede Budgetentscheidung. Server-Side First-Party-Cookies überleben ITP und lösen dieses Problem an der Wurzel.
Erfassung von Rohdaten im eigenen Data Warehouse
Plattformen wie GA4 oder Google Ads speichern Daten aggregiert und mit begrenzter Aufbewahrungsdauer. Wer Rohdaten auf dem eigenen Server mitschreibt, hat mehr Kontrolle und mehr Möglichkeiten:
- Unbegrenzte Aufbewahrung: GA4 löscht Rohdaten nach 14 Monaten; eigene Daten bleiben so lang wie gewünscht verfügbar
- Zusammenführung von Daten aus verschiedenen Quellen: Event-Daten mit CRM, ERP oder Support-Daten verknüpfen und vollständige Customer Journeys rekonstruieren
- Eigene Attributionsmodelle: Jeder Anbieter hat ein Interesse daran, sich selbst möglichst viel Erfolg zuzuschreiben. Eigene Attributionsmodelle auf Basis der Rohdaten sind neutral und nachvollziehbar.
- Fortgeschrittene Analysemöglichkeiten: Segmentierungen, Trichteranalysen und Pfadanalysen, die keine Plattform standardmäßig anbietet
- Grundlage für Integration in eigene Systeme: strukturierte Rohdaten direkt in BI-Tools, Data Warehouses und interne Dashboards einspeisen
- Grundlage für ML-Modelle: strukturierte Rohdaten als Input für eigene Prognose- und Segmentierungsmodelle
Anreicherung von Daten
Serverside Tracking ermöglicht die Anreicherung von Mess-Daten mit Daten aus externen Datenquellen. Dies inkludiert auch Daten aus Datenquellen, die nicht öffentlich einsehbar sein sollen (alle Daten, die im Clientside Tracking erfasst werden, sind unvermeidlich für jeden technisch versierten Website-Besucher einsehbar).
Was clientseitig übertragen wird, ist im Browser sichtbar: Produktpreise, Umsatz, Bestellwert. Wenn Sie das nicht für technisch versierte Mitbewerber sichtbar machen wollen, lösen Sie es besser serverseitig.
Mit Serverside Tracking wird die Bestellung serverseitig mit den Margendaten aus dem ERP oder der Warenwirtschaft angereichert. Google Ads und Meta erhalten als Conversion-Wert nicht den Bruttoerlös, sondern den echten Gewinn. Smart Bidding optimiert damit auf Profitabilität statt auf Umsatz.
Ein Formular-Submit ist kein Indikator für Qualität. Ob eine Anfrage zu einem Auftrag wird, entscheidet sich im CRM, oft Tage oder Wochen später.
Mit Serverside Tracking kann der Lead-Score oder der qualifizierte Status aus dem CRM nachträglich als Conversion-Signal an Google Ads und Meta zurückgespielt werden. Kampagnen optimieren damit nicht auf Rohanfragen, sondern auf Leads, die tatsächlich konvertieren.
Nutzerspezifische Daten wie Abo-Status, Kundensegment oder Lifetime Value sollten nicht im Browser liegen. Clientseitig wären sie für jeden technisch versierten Besucher auslesbar.
Serverseitig lassen sich Events mit dem Segment des Nutzers anreichern, bevor sie an Werbeplattformen übertragen werden. Kampagnen können so auf hochwertige Segmente ausgesteuert werden, ohne die Segmentierungslogik im Frontend zu exponieren.
Verbesserung der Ladezeiten
Häufig genannt wird auch die Verbesserung der Ladezeiten durch Serverside Tracking. Dieser Vorteil ist zwar gegeben, allerdings machen die Ladezeiten von Tracking-Skripts in der Praxis nur einen kleinen Teil der Gesamtladezeit einer Website aus. Daher sollte dieser Vorteil nicht überbewertet werden und keinesfalls der Hauptgrund für den Einsatz von Serverside Tracking sein.
Sicherheit
Wer Clientside Tracking betreibt, bindet externen Code direkt in die eigene Website ein. Dieser Code läuft im Browser der Nutzer mit denselben Rechten wie der eigene Code: Er kann Formulareingaben lesen, Logins mitspeichern und Seiteninhalte manipulieren.
Das eigentliche Risiko liegt dabei nicht im Normalfall, sondern in zwei unkontrollierbaren Szenarien. Erstens können Anbieter ihr Script jederzeit aktualisieren, ohne Vorwarnung und ohne Einverständnis des Website-Betreibers. Was heute nur Klicks trackt, kann morgen mehr tun. Zweitens genügt es, wenn der Anbieter selbst kompromittiert wird: Ein gehacktes CDN oder ein manipuliertes Script bedeutet, dass schadhafter Code automatisch auf allen einbindenden Websites ausgeführt wird.
Beim Serverside Tracking läuft kein externer Code im Browser. Der Website-Betreiber kontrolliert vollständig, welche Daten den Server verlassen und wohin sie gehen.
Serverside Tracking jetzt umsetzen
Von der Tool-Auswahl über den Implementierungsplan bis zur Umsetzung: alles aus einer Hand.
Nachteile und Limitierungen von Serverside Tracking
Serverside Tracking ist nicht für jedes Setup geeignet. Die wichtigsten Einschränkungen im Überblick:
Kosten
Clientside Tracking ist in vielen Fällen kostenlos, jedenfalls aber kostengünstiger als Serverside Tracking. Serverside Tracking ist mit Kosten für den Betrieb des Servers und ggf. für die Software verbunden. Mehr dazu in unserer Kostenübersicht zu Serverside Tracking . In der Regel empfehlen wir Serverside Tracking daher erst ab einem Marketing-Budget von rund EUR 5000 monatlich.
Zielkonflikte
Bei den oben genannten Vorteilen ist zu beachten, dass nicht alle Vorteile gleichzeitig in vollem Umfang realisiert werden können. Insbesondere muss die richtige Balance zwischen Datenschutz und Datenqualität gefunden werden, beides kann niemals gleichzeitig maximiert werden. Hier ist professionelle Beratung notwendig, um die für Sie optimale Lösung zu finden.
Nicht jedes Tool unterstützt Serverside Tracking
Für Remarketing und Post-View-Tracking sind zwingend Clientside Tracking-Methoden notwendig. Auch A/B-Testing-Tools, Personalisierungs-Tools, Heatmaps und Session-Replay-Tools sind meistens auf Clientside Tracking angewiesen.
Nachfolgend eine Übersicht, welche Technologien mit Serverside Tracking kompatibel sind und welche nicht:
| Kompatibilität | Verwendete Technologie | Beispiele |
|---|---|---|
| ✓ Kompatibel | First Party Cookies | Webanalyse (z.B. Google Analytics), Conversion Tracking Post-Click und Customer Match (z.B. Google Ads, Facebook) |
| ✗ Nicht kompatibel | Third Party Cookies | Remarketing-Tags (alle Anbieter), geräteübergreifende Conversions und View-Through-Conversions ohne Customer Match |
| ✗ Nicht kompatibel | DOM-Manipulation / DOM-Überwachung | A/B Testing Tools (alle Anbieter), Heatmap- und Video-Replay-Tools |
Daher ist in vielen Fällen eine Kombination von Clientside und Serverside Tracking notwendig, wobei sich beides problemlos kombinieren lässt.
Wann macht Serverside Tracking keinen Sinn?
Serverside Tracking ist kein Allheilmittel. Für manche Setups ist es schlicht nicht gerechtfertigt.
Laufende Kosten und Implementierungsaufwand lohnen sich erst ab einem gewissen Marketing-Budget. Als Faustregel: wenn die Serverkosten mehr als 3 % des monatlichen Online-Marketing-Budgets ausmachen würden, ist das Kosten-Nutzen-Verhältnis in der Regel nicht gegeben.
In Mobile-lastigen Zielgruppen und Märkten mit geringer Ad-Blocker-Verbreitung ist der Datenverlust durch Clientside Tracking oft marginal. Wenn eine Messung der Datenlücke zeigt, dass weniger als 10 % der Daten verloren gehen, rechtfertigt das in der Regel kein Serverside-Projekt.
Serverside Tracking ist kein einmaliges Projekt. Mit externem Managed-Hosting (traffic3, JENTIS, Stape) und einer Agentur für die laufende Betreuung ist das gut lösbar. Wer es intern betreibt, muss sowohl Software-Updates am Server als auch Tag-Konfigurationen aktiv pflegen: Datenempfänger ändern ihre APIs, neue Events kommen hinzu, Plattformen stellen Anforderungen um.
Serverside Tagging vs. Serverside Tracking
Die beiden Begriffe werden oft synonym verwendet, bezeichnen aber unterschiedliche Dinge.
Serverside Tagging bedeutet, dass Tags wie Google Analytics oder Meta Pixel nicht im Browser laufen, sondern durch einen server-seitigen Tag Manager (z.B. SGTM) verarbeitet werden. Der Browser sendet weiterhin einen Request, aber an den eigenen Server, der die Daten kontrolliert weiterleitet. Es geht um die Verlagerung der Tag-Management-Schicht, nicht um die Abschaffung des Browser-Requests.
Server-to-Server Tracking geht einen Schritt weiter: Das Backend sendet Daten direkt an Plattformen, ohne Browser-Beteiligung. Eine Bestellung im Shop löst direkt einen API-Call an Google Ads oder Meta aus, unabhängig davon, ob der Browser noch offen ist, ob Cookies gesetzt wurden oder ob der Nutzer einen Adblocker verwendet.
Serverside Tracking ist der Oberbegriff für beides. In der Praxis wird er häufig als Synonym für Serverside Tagging verwendet, was die Begriffsverwirrung erklärt.
Wie sich C2S, S2S und Hybrid in der Praxis unterscheiden, erklären wir im Abschnitt Implementierungsansätze.
Tool-Anbieter für Serverside Tracking
Die entscheidende Weichenstellung ist die Wahl des Tracking-Ansatzes: SGTM-basierte Lösungen sind der günstige Einstieg mit moderater Wirkung; spezialisierte EU-Lösungen liefern höhere Datensteigerungen und eignen sich für anspruchsvollere Anforderungen.
| Ansatz | Beispiele | Datensteigerung | Kosten |
|---|---|---|---|
| SGTM-basiert | Google Cloud, Stape, selbst gehostet, traffic3-Hosting | 2–5 % | Günstig bis Mittel |
| Spezialisierte EU-Lösung | JENTIS, individuelle Lösung durch traffic3 | 5–15 % (mit Consentless-Anteil bis zu 100 %) | Premium |
SGTM-basierte Lösungen (ob in der Google Cloud, über Stape, selbst gehostet oder durch traffic3 betrieben) unterscheiden sich vor allem in Datenschutz und Betriebsmodell, nicht in der Tracking-Wirkung. Der SGTM ist primär auf Datenverarbeitung ausgelegt, nicht auf die Umgehung von Tracker-Blockern, weshalb die Datensteigerung bei allen Varianten ähnlich ausfällt. Stape ist ein US-amerikanischer Hosting-Dienst mit wählbaren EU-Serverstandorten; wer einen EU-Anbieter bevorzugt, nutzt das traffic3-Hosting oder betreibt den Server selbst.
Spezialisierte EU-Lösungen wie JENTIS oder individuelle Lösungen durch traffic3 erzielen höhere Datensteigerungen, weil sie gezielt auf Tracker-Resistenz und Consentless-Szenarien ausgelegt sind. JENTIS bietet mit dem "Essential Mode" eine datenschutzkonforme Consentless-Erfassung ohne personenbezogene Daten; individuelle traffic3-Lösungen können durch serverseitiges Erfassen von Conversion-Daten Datensteigerungen von bis zu 100 % erreichen.
Welche Lösung für Ihr Setup die richtige ist, hängt von Budget, Datenschutzanforderungen und den konkreten Datenempfängern ab.
Wir beraten bei der richtigen Lösung
SGTM oder spezialisierte EU-Lösung: was für Sie Sinn ergibt, klären wir in einem kurzen Gespräch.
Kosten von Serverside Tracking
Die laufenden Kosten reichen von EUR 20 monatlich für einfache SGTM-Setups bis in den vierstelligen Bereich für Premium-Lösungen wie JENTIS. Als Faustregel: Serverside Tracking lohnt sich, solange die Kosten nicht mehr als 3 % des monatlichen Online-Marketing-Budgets ausmachen. Eine vollständige Aufschlüsselung nach Traffic-Volumen, Toolanbieter und Implementierungsaufwand finden Sie in unserem Artikel zu den Kosten von Serverside Tracking .
Implementierung von Serverside Tracking
Die genaue Implementierung hängt von der gewählten Technologie ab. Bei einfachen Setups (ein bis zwei Datenempfänger, bestehender GTM) ist das Projekt typischerweise in zwei bis vier Wochen abgeschlossen. Komplexe Setups mit Server-to-Server Tracking und mehreren Datenempfängern dauern ein bis drei Monate.
Vor Projektstart sollten folgende Voraussetzungen geklärt sein:
- Zugriff auf DNS-Einstellungen (für die Subdomain-Einrichtung)
- Bestehendes Consent Management Tool (CMP) im Einsatz
- Entscheidung über Toolanbieter und Hosting-Modell
- Klärung der gewünschten Datenempfänger
Die Implementierung erfolgt typischerweise in folgenden Schritten:
| Schritt | Verantwortlichkeit | Beschreibung |
|---|---|---|
| 1. Einrichtung des Servers | Toolanbieter | Einrichtung des Servers, auf dem der Serverside Tag Manager läuft. Bei Self-hosted Lösungen übernimmt das der Betreiber selbst. |
| 2. Einrichtung einer Subdomain | Webentwickler / IT-Dienstleister | Einrichtung einer Subdomain, über die die Daten an den Serverside Tag Manager gesendet werden, z.B. tagmanager.traffic3.net. |
| 3. Einbau des neuen Tag Manager Codes | Webentwickler | Einbau des neuen Tag Manager Codes auf der Website. Initialer paralleler Betrieb zum bestehenden Tag Manager empfohlen, bis die korrekte Datenübertragung sichergestellt ist. |
| 4. Server-to-Server Tracking (optional) | Webentwickler | Nur bei besonders wichtigen Conversions (z.B. Shop-Bestellungen) sinnvoll, weil hier der größte interne Aufwand anfällt. |
| 5. Migration der Tags | Tracking-Verantwortlicher / Externe Agentur | Migration der bestehenden Tags (z.B. Google Analytics, Facebook Pixel) vom Clientside auf den Serverside Tag Manager. Kann Schritt für Schritt erfolgen. |
| 6. Testen und Qualitätssicherung | Tracking-Verantwortlicher / Externe Agentur | Datenkontrolle, um sicherzustellen, dass alle Daten korrekt übertragen werden. |
| 7. Entfernung des alten Tag Manager Codes | Webentwickler | Entfernung des alten Tag Manager Codes von der Website, sobald die Migration abgeschlossen ist. |
Implementierung jetzt angehen
Wir begleiten den Aufbau von Anfang an: von der Tool-Auswahl bis zur vollständigen Migration.
Implementierungsansätze: C2S, S2S und Hybrid
Serverside Tracking ist kein einheitlicher Ansatz. Je nach Ziel und technischen Möglichkeiten gibt es drei Varianten, die sich in Aufwand und Wirkung deutlich unterscheiden.
Client-to-Server Tracking (C2S)
Der Browser sendet einen Request an den eigenen Server (z.B. den Serverside Google Tag Manager), der die Daten kontrolliert an GA4, Meta CAPI oder Google Ads weiterleitet. Das ist die am häufigsten umgesetzte Variante und der typische Einstieg in Serverside Tracking.
C2S bringt klare Vorteile gegenüber reinem Clientside Tracking: First-Party Domain, längere Cookie-Laufzeiten und die Möglichkeit, Daten zu filtern bevor sie Drittanbieter erreichen.
Die Einschränkung: der Browser-Request existiert weiterhin. Technisch ausgefeilte Adblocker können ihn erkennen; ohne Browser-Request, etwa nach dem Schließen des Tabs, gibt es keine Daten.
Server-to-Server Tracking (S2S)
Das Backend der Website oder des Shops sendet Ereignisse direkt an Plattform-APIs oder an den Serverside Tag Manager, der sie an die APIs weiterleitet, ohne Beteiligung des Browsers. Eine Kaufbestätigung löst zum Beispiel einen direkten API-Call an die Meta Conversions API oder die Google Ads API aus, unabhängig davon ob der Nutzer noch online ist, Cookies akzeptiert hat oder einen Adblocker verwendet.
S2S liefert die höchste Datenqualität für Conversion-Events. Die Umsetzung erfordert Entwicklerarbeit: Backend-Zugriff, API-Integration und ein sauberes User-ID-Mapping zwischen Website und Backend. Für viele Unternehmen ist das ein externer Entwicklerauftrag.
Hybrid Tracking
Hybrid Tracking meint die Kombination von Clientside Tracking mit Serverside Tracking, wobei der serverseitige Anteil entweder C2S oder S2S sein kann. Clientside und serverseitig laufen dabei gleichzeitig und ergänzen einander.
Das häufigste Beispiel ist das empfohlene Meta-Setup: Meta Pixel (clientseitig) und Meta Conversions API (serverseitig) parallel. Das Pixel liefert Browserdaten für View-Through Attribution und Cross-Device Tracking; die CAPI liefert zuverlässige Conversion-Signale, die das Pixel allein nicht erfassen würde.
Wichtig beim Hybrid-Ansatz: Deduplication muss konfiguriert sein. Ohne sie zählt dieselbe Conversion doppelt, was Kampagnendaten verzerrt. Meta und Google bieten dafür Event-ID-basierte Mechanismen an.
Google Tag Gateway
Das Google Tag Gateway (2024) ist eine leichtgewichtige Alternative zum vollständigen Serverside-Setup. Über eine eigene Subdomain werden Anfragen an Google-Server weitergeleitet, ohne dass ein eigener Serverside Tag Manager benötigt wird. Die Einrichtung erfolgt direkt in Google Tag Manager oder GA4; lediglich ein DNS-Eintrag ist nötig.
Das Gateway eignet sich für Setups, die ausschließlich Google-Produkte nutzen und schnell von der Blocker-Resistenz einer eigenen Domain profitieren wollen. Es ersetzt den SGTM nicht: Datenverarbeitung, Filterung, Datenanreicherung oder die Anbindung von Drittanbietern (Meta, Microsoft) sind damit nicht möglich. Datenschutztechnisch ändert sich wenig gegenüber dem Clientside-Setup, da die Daten weiterhin direkt zu Google gehen.
Einen vollständigen Vergleich liefert unser Artikel zum Google Tag Gateway .
Datenschutzerklärung beim Serverside Tracking
Serverside Tracking ändert die datenschutzrechtlichen Informationspflichten nicht grundsätzlich, aber in den Details: nicht ob sie bestehen, sondern was drin stehen muss.
Wer den Serverside Google Tag Manager einsetzt, muss in der Datenschutzerklärung die Subdomain als technischen Transportweg erwähnen und den Hosting-Anbieter als Auftragsverarbeiter nach Art. 28 DSGVO benennen. Bei Hosting in der Google Cloud bleibt Google Ireland Ltd. der relevante Vertragspartner; bei externem Hosting (traffic3, JENTIS, Stape) tritt der jeweilige Anbieter hinzu. Einen Mustertext für den GTM-Abschnitt finden Sie in unserer Muster-Datenschutzerklärung für den Google Tag Manager .
Serverside Tracking Setup prüfen oder aufbauen
Serverside Tracking hat viele Implementierungsvarianten: was in Ihrem Setup Sinn ergibt, hängt von Budget, Datenschutzanforderungen und Datenempfängern ab. Wir prüfen Ihr bestehendes Setup und sagen Ihnen ehrlich, wo der Hebel liegt.
- Einschätzung Ihres aktuellen Tracking-Setups
- Welche Lösung sinnvoll ist (SGTM, JENTIS, individuelle Lösung)
- Ungefährer Implementierungsaufwand und Kostenrahmen
Häufige Fragen
Die häufigsten Fragen aus der Praxis, direkt beantwortet:
Fast immer ja. Consent-Verweigerung ist nur eine von drei Verlustquellen:
- Ad-Blocker: auf Desktop-Zielgruppen nach unserer Erfahrung oft 20–35 %
- ITP in Safari: betrifft alle iOS-Nutzer unabhängig vom Consent; clientseitig gesetzte Cookies werden nach 7 Tagen gelöscht
- Consent-Verweigerung: die sichtbarste, aber oft nicht die größte Lücke
Ein Nutzer, der eingewilligt hat, aber Safari nutzt, wird nach 7 Tagen als neuer Nutzer gezählt. Die tatsächliche Datenlücke liegt bei vielen Setups deutlich über 30 %, selbst bei guter Consent-Rate.
Das ist häufiger als man denkt. Es liegt meistens nicht an der Implementierung selbst, sondern an falschen Erwartungen oder einer zu einfachen Variante. Standard-SGTM in der Google Cloud bringt 2–5 % mehr Daten, nicht 30 %.
Wer mehr will, braucht mindestens eines davon:
- Eine echte Proxy-Subdomain, damit die Domain nicht in Blocklisten steht
- Server-to-Server Tracking für kritische Conversion-Events
- Eine spezialisierte Lösung wie JENTIS mit aktiver Tracker-Resistenz
Fällt der Tagging-Server aus, haben eingehende Tracking-Requests kein Ziel. Das bedeutet zumindest teilweise Datenverluste für die Dauer des Ausfalls. Anders als beim Clientside Tracking, das direkt im Browser läuft, hängt Serverside Tracking von einer eigenen Infrastruktur ab.
Professionelles Hosting mit Monitoring, automatischem Failover und definierten SLAs ist daher kein Nice-to-have. Managed-Hosting-Anbieter wie traffic3, JENTIS oder Stape übernehmen Betrieb und Incident-Management; wer selbst hostet, muss das intern sicherstellen.
Nicht, wenn die Migration sauber geplant ist. Der Standardansatz ist Parallelbetrieb: Clientside Tags und das neue Serverside-Setup laufen gleichzeitig, bis die Datenqualität auf der neuen Schicht verifiziert ist.
Diese Parallelphase dauert typischerweise einige Wochen und ermöglicht einen direkten Datenvergleich zwischen beiden Systemen. Erst wenn die Serverside-Daten vollständig und korrekt sind, werden die alten Tags abgeschaltet.
Umgehen nicht. Wer Daten an GA4 oder Google Ads schickt, schickt sie zu Google, unabhängig vom technischen Weg. Was Serverside ändert: IP-Adresse und andere personenbezogene Daten können vor der Weitergabe gefiltert werden. Das ist Datensparsamkeit, keine Anonymität gegenüber Google.
Wer Google als Datenempfänger grundsätzlich reduzieren will, kann Serverside Tracking nutzen, um Daten parallel direkt in eine eigene Datenbank oder ein Data Warehouse zu schreiben, ohne Umweg über Google-Infrastruktur. Das ist technisch aufwändiger, aber möglich.
Mit praktisch allen. Der häufig gehörte Einwand „unser System unterstützt das nicht" ist fast immer ein Missverständnis. Die Subdomain-Einrichtung (DNS CNAME-Eintrag) ist vollständig plattformunabhängig.
Client-to-Server Tracking funktioniert mit WordPress, Shopify, Shopware, Magento, TYPO3, Contentful, Webflow und jedem anderen System, das einen Google Tag Manager oder gtag.js laden kann. Lediglich Server-to-Server Tracking erfordert Backend-Zugriff; aber auch das ist in allen gängigen Shop-Systemen über Webhooks oder Order-Events realisierbar.
Weil es Geld, Know-how und eine bewusste Entscheidung kostet. Clientside Tracking ist kostenlos, sofort verfügbar und durch jahrelange Gewohnheit tief verankert. Serverside Tracking erfordert Server-Infrastruktur, Implementierungsaufwand und jemanden, der das System versteht und wartet. Die Technologie ist vorhanden; die Hürde ist organisatorisch.
Wer jetzt umstellt, hat gegenüber Mitbewerbern, die weiter auf defizitäres Clientside-Tracking setzen, einen messbaren Vorsprung in der Kampagnenoptimierung. Noch. Sobald es zum Standard wird, verschwindet dieser Vorteil.
Ja. Das ist wichtig zu wissen. Bessere Datenvollständigkeit bedeutet mehr gemessene Conversions, nicht notwendigerweise mehr echte Conversions. Der richtige Maßstab nach einer Migration ist nicht die absolute Conversion-Zahl, sondern Umsatz, Anfragen oder andere externe Kennzahlen, die unabhängig vom Tracking-System existieren.
Langfristig verbessert vollständigeres Tracking die Kampagnenoptimierung. Aber der erste Anstieg in den Zahlen ist oft ein Mess-Artefakt, kein echter Performance-Gewinn.
Die Software schon. Der Serverside Google Tag Manager ist kostenlos verfügbar, läuft aber im Gegensatz zum clientseitigen GTM nicht auf Google-Infrastruktur. Google stellt nur den Code; betreiben muss man ihn selbst, auf eigenen oder gemieteten Servern.
Diese Server kosten Geld, entweder direkt über einen Cloud-Anbieter (Google Cloud, AWS, Hetzner) oder über einen Managed-Hosting-Dienst wie traffic3, JENTIS oder Stape. Die Software ist kostenlos, der Betrieb nicht.
Weiterführende Artikel
Weitere Artikel rund um Serverside Tracking und Webanalyse:
Kosten von Serverside Tracking
Was SGTM und spezialisierte Lösungen im Vergleich kosten, aufgeschlüsselt nach Traffic-Volumen und Implementierungsaufwand.
WeiterlesenGoogle Analytics und Datenschutz
Warum GA4 ohne begleitende Maßnahmen datenschutzrechtlich problematisch ist, und was Serverside Tracking dabei löst.
Weiterlesen