Server Side Tracking: so richten Sie es mit Google Tag Manager ein

Server-Side-Tracking bedeutet, dass Sie Ihre Tags nicht mehr alle im Browser Ihrer Besucher laufen lassen, sondern dass der Browser einen einzigen Datenstrom an einen Server schickt, den Sie selbst verwalten. Dieser Server, ein Server-Container in Google Tag Manager, verarbeitet die Daten und leitet sie an GA4, Google Ads, Meta oder andere Plattformen weiter. Das Ergebnis: weniger Skripte auf Ihrer Website, mehr Kontrolle darüber, was Sie teilen, und haltbarere First-Party-Cookies. In diesem Artikel lesen Sie, wie es funktioniert, wann es sich lohnt und wie Sie es Schritt für Schritt einrichten.

Was ist Server-Side-Tagging?

Beim klassischen, clientseitigen Tagging lädt jedes Tool sein eigenes Skript in den Browser: den Google-Tag, das Meta-Pixel, das LinkedIn Insight Tag. Jedes Skript schickt selbst Daten an seinen eigenen Server. Sie haben wenig Einblick, was genau den Browser verlässt.

Beim Server-Side-Tagging ändert sich dieser Weg. Der Browser schickt Messanfragen an Ihren Tagging-Server. Google beschreibt das in seiner Dokumentation zum Server-Side-Tagging als Container, der “auf einem Server läuft, den Sie kontrollieren”, in Ihrem eigenen Google-Cloud-Projekt oder einer anderen Umgebung. In diesem Container wandeln sogenannte Clients die eingehenden Anfragen in Events um, danach leiten Tags diese Events an die Plattformen weiter, die Sie wählen. Bis Sie etwas weiterleiten, haben nur Sie Zugriff auf diese Daten.

Clientseitig und serverseitig im Vergleich

Server-Side-Tagging oder Server-Side-Tracking?

In der Praxis verwenden Marketer beide Begriffe synonym. Genau genommen ist Server-Side-Tagging die Technik (Tags in einem Server-Container) und Server-Side-Tracking das Ergebnis (Messen über einen Server statt direkt aus dem Browser). Wer nach “server side tracking” sucht, meint meist dasselbe Setup. Für die spezifische Google-Ads-Seite, mit Enhanced Conversions und Offline-Conversions, lesen Sie unseren Beitrag zu Server-Side-Tracking für Google Ads.

Warum entscheiden sich Unternehmen für Server-Side-Tagging?

Kontrolle darüber, was Sie teilen

Jeder Tag im Browser sendet standardmäßig alles, was er erfassen kann: URLs, Referrer, manchmal sogar Formularfelder in einem Querystring. In einem Server-Container sehen Sie jede eingehende Anfrage und entscheiden pro Plattform, welche Felder weitergehen. Eine IP-Adresse kürzen, eine E-Mail-Adresse aus einer URL entfernen oder ein Feld nur an Google Ads und nicht an Meta senden: Das regeln Sie an einer Stelle.

Haltbarere First-Party-Cookies

Läuft Ihr Tagging-Server auf einer Subdomain Ihrer eigenen Website (zum Beispiel messung.ihredomain.de), setzt dieser Server Cookies in einem First-Party-Kontext. Google nennt das in seiner Anleitung zu einer eigenen Domain eine Best Practice, die Ihnen “die Sicherheits- und Haltbarkeitsvorteile serverseitig gesetzter Cookies” bringt. Auf der Standarddomain Ihres Cloud-Anbieters läuft der Server in einem Third-Party-Kontext und kann nur JavaScript-Cookies setzen. Warum das zählt, lesen Sie in unserem Beitrag über First Party Data.

Weniger Skripte im Browser

Jedes zusätzliche Pixel kostet Ladezeit. Indem Sie Tools wie Meta und LinkedIn über den Server bedienen statt über ein eigenes Skript, verschwindet ein Teil dieses JavaScripts aus dem Browser. Rechnen Sie aber nicht mit Wundern: Der Google-Tag oder Web-Container bleibt nötig, um die Daten zu erfassen.

Ein Ort, um Daten anzureichern

Ein Server-Container kann Events um Daten ergänzen, die der Browser nicht kennt, etwa eine Marge pro Produkt oder einen Lead-Status. So senden Sie Google Ads einen Conversion-Wert, der näher am Umsatz liegt.

Server-Side-Tagging und Consent (DSGVO)

Im EWR gilt: Ein Cookie für Analysezwecke ist nicht unbedingt erforderlich und braucht daher eine Einwilligung, und der Widerruf muss so einfach sein wie die Erteilung. In Deutschland ergibt sich das aus § 25 TDDDG, in Belgien vertritt die GBA diese Linie, in den Niederlanden die Autoriteit Persoonsgegevens. Daran ändert sich nichts, nur weil die Daten über Ihren Server laufen.

Was sich sehr wohl ändert: Sie können den Consent-Status an den Server-Container mitsenden und dort pro Tag respektieren. Google arbeitet mit vier Consent-Typen: ad_storage, analytics_storage, ad_user_data und ad_personalization. In der Basic-Variante laden Google-Tags erst nach einer Auswahl im Banner, in der Advanced-Variante laden sie sofort mit dem Standardstatus “denied” und senden Messungen ohne Cookies. Wie Sie das für Google Ads einrichten, beschreibt unser Beitrag zu Consent Mode v2 für Google Ads.

Server-Side-Tagging in 7 Schritten einrichten

1. Erstellen Sie ein Inventar Ihrer Tags und Ihres Consents

Listen Sie auf, welche Tags heute laufen, welche Events sie messen und unter welche Consent-Kategorie sie fallen. Das ist auch der Moment zum Aufräumen: Doppelte GA4-Tags und vergessene Pixel ziehen nicht mit um. Ohne diesen Schritt kopieren Sie bestehende Fehler in eine teurere Umgebung.

2. Legen Sie einen Server-Container in Google Tag Manager an

Wählen Sie in Google Tag Manager einen neuen Container vom Typ “Server”. Der Container bringt standardmäßig einen GA4-Client und GA4-Tags mit, sodass Sie sofort GA4-Traffic empfangen können.

3. Wählen Sie Ihr Hosting

Sie können den Tagging-Server automatisch in Google Cloud (Cloud Run) anlegen lassen oder selbst bereitstellen. Google empfiehlt, in der Produktion mindestens zwei Instanzen zu betreiben, damit Sie bei einer Störung keine Daten verlieren, und nennt dort einen Richtwert für die monatlichen Serverkosten, die direkt mit Google abgerechnet werden. Außerdem brauchen Sie einen separaten Preview-Server, um testen zu können. Wer keine eigene Cloud-Verwaltung möchte, wählt einen verwalteten Host wie Stape: weniger Wartung, aber ein zusätzlicher Dienstleister in Ihrem Verarbeitungsverzeichnis.

4. Verbinden Sie eine eigene Subdomain

Richten Sie eine Subdomain wie messung.ihredomain.de ein und lassen Sie sie auf Ihren Tagging-Server zeigen, oder liefern Sie den Container über einen Pfad auf Ihrer eigenen Domain aus. Erst dann profitieren Sie von serverseitig gesetzten Cookies in einem First-Party-Kontext. Vergessen Sie diesen Schritt, läuft alles in einem Third-Party-Kontext und Ihnen entgeht ein großer Teil des Vorteils.

5. Leiten Sie Ihren Web-Container an den Server

In Ihrem Web-Container (oder im Google-Tag) hinterlegen Sie die Server-URL, damit GA4-Hits an Ihren Tagging-Server gehen statt direkt an Google. Arbeiten Sie mit einer Data Layer, bleibt diese die Quelle Ihrer Events und Parameter: Der Server bekommt, was der Web-Container weitergibt.

6. Richten Sie Clients und Tags im Server-Container ein

Fügen Sie pro Plattform den passenden Tag hinzu: GA4, Google-Ads-Conversions, die Meta Conversions API, gegebenenfalls LinkedIn. Senden Sie dasselbe Event sowohl über den Browser als auch über den Server an Meta, geben Sie eine gemeinsame Event-ID mit, damit Meta deduplizieren kann. Lassen Sie jeden Tag nur dann auslösen, wenn der Consent-Status es erlaubt.

7. Testen, live schalten und überwachen

Testen Sie jede Änderung in der Vorschau, sowohl im Web-Container als auch im Server-Container. Im Google Tag Assistant sehen Sie, welche Tags mit welchen Daten auslösen, in der Vorschau des Server-Containers sehen Sie pro eingehender Anfrage, welcher Client sie aufgenommen hat und welche Tags sie weitergeleitet haben. Prüfen Sie danach in GA4, Google Ads und im Meta Events Manager, ob die Events mit den richtigen Werten ankommen. Nach dem Livegang überwachen Sie, ob die Server erreichbar bleiben und ob Ihre Event-Zahlen stabil bleiben.

Häufige Fehler beim Server-Side-Tagging

• Keine eigene Subdomain. Der Server läuft auf der Standarddomain des Cloud-Anbieters, wodurch die Cookies Third-Party bleiben.
• Doppelt zählen. Die alten Browser-Tags bleiben neben den neuen serverseitigen Tags aktiv, oder Meta erhält Browser- und Server-Events ohne gemeinsame Event-ID.
• Consent auf Serverseite vergessen. Der Banner funktioniert im Browser, aber der Server leitet alles weiter, unabhängig von der Auswahl.
• Eine einzige Instanz in der Produktion. Bei einer Störung gehen Ihre Messdaten verloren, bis es jemand bemerkt.
• Eine unaufgeräumte Basis mitnehmen. Server-Side-Tagging repariert keine schlechten Events und keine fehlende Data Layer. Lesen Sie auch die Klassiker in unserem Beitrag zu häufigen Fehlern im Google-Analytics-Tracking.

Wie prüfen Sie, ob Ihr serverseitiges Setup funktioniert?

1. Öffnen Sie die Vorschau Ihres Web-Containers und prüfen Sie im Tag Assistant, ob die GA4-Hits an Ihre eigene Subdomain gehen.
2. Öffnen Sie die Vorschau Ihres Server-Containers und sehen Sie pro Anfrage nach, welcher Client sie aufgenommen hat und welche Tags ausgelöst haben, mit welchem Statuscode.
3. Prüfen Sie in GA4 DebugView, ob die Events mit den richtigen Parametern ankommen.
4. Nutzen Sie die Test-Events im Meta Events Manager und die Conversion-Diagnose in Google Ads.
5. Vergleichen Sie nach einer Woche die Event-Zahlen mit Ihrem alten Setup und mit Ihrem CRM.

Sind Sie unsicher, ob Ihr aktuelles Setup stimmt, bevor Sie loslegen? Ein Tracking-Audit erfasst zuerst die bestehenden Tags, den Consent und die Datenabweichungen.

Wann lohnt sich Server-Side-Tagging, und wann nicht?

Es lohnt sich vor allem, wenn Sie ernsthaftes Budget in Google Ads oder Meta stecken und diese Plattformen bessere Signale brauchen, wenn Sie mehrere Plattformen aus denselben Events bedienen oder wenn Sie streng festlegen wollen, welche Daten Sie teilen. Für eine kleine B2B-Website mit einer Handvoll Anfragen pro Monat und einer einzigen GA4-Property reicht oft ein sauberes clientseitiges Setup mit korrektem Conversion-Tracking. Fangen Sie dann dort an.

In unseren Setups beginnen wir selten mit dem Server. Bei Suivo lag der Gewinn in einem robusten Formular-Listener und einer sauberen Data Layer, bei Kaizo in einer klaren Conversion, der gebuchten Demo, die GA4, Google Ads und Meta auf dieselbe Weise sehen. Server-Side-Tagging baut auf so einer Basis auf, es ersetzt sie nicht.

Häufig gestellte Fragen

Ist Server-Side-Tagging DSGVO-konform?

Nicht automatisch. Es gibt Ihnen aber bessere Mittel, DSGVO-konform zu arbeiten: Sie sehen alle ausgehenden Daten, können Felder filtern und pro Tag den Consent-Status respektieren. Die Pflicht, für Analyse- und Werbe-Cookies eine Einwilligung einzuholen, gilt weiterhin.

Brauche ich noch einen normalen Google-Tag-Manager-Container?

Ja, in nahezu jedem Setup. Der Web-Container oder der Google-Tag erfasst die Events im Browser und schickt sie an Ihren Server. Der Server-Container verarbeitet und verteilt sie. Mehr zu den Grundlagen lesen Sie in unserem Beitrag über Google Tag Manager.

Umgeht Server-Side-Tagging Adblocker?

Teilweise, und das ist nicht das Ziel. Über eine eigene Subdomain werden Anfragen seltener blockiert als bekannte Third-Party-Domains, aber Besucher, die keine Einwilligung geben, dürfen Sie auch serverseitig nicht mit Cookies messen.

Was kostet Server-Side-Tagging?

Die Kosten bestehen aus dem Hosting (Google Cloud oder ein verwalteter Host) und der Zeit für Einrichtung, Tests und Wartung. Wie viel Arbeit das ist, hängt von der Zahl der Plattformen, Ihrem Consent-Setup und dem Zustand Ihres aktuellen Trackings ab. Wir arbeiten deshalb auf Anfrage, nach einer kurzen Analyse.

Was ist der Unterschied zu Server-Side-Tracking für Google Ads?

Server-Side-Tagging ist die breite Infrastruktur für alle Ihre Plattformen. Für Google Ads kommen spezifische Techniken hinzu, etwa Enhanced Conversions und Offline-Conversions aus Ihrem CRM. Diese behandeln wir in unseren Beiträgen zu Server-Side-Tracking für Google Ads und zum Einrichten von Enhanced Conversions.

Server-Side-Tagging einrichten lassen?

Wir richten Server-Side-Tagging als Teil eines vollständigen Mess-Setups ein: Inventar, Server-Container, eigene Subdomain, Consent und eine Testrunde pro Plattform. Sehen Sie sich an, wie unsere Tracking-Agentur arbeitet, oder starten Sie mit einem Tracking-Audit, wenn Sie zuerst wissen wollen, wo Ihre Messung heute Lücken hat. Lieber direkt sprechen? Nehmen Sie Kontakt auf.