Server-Side Tracking: was ist das?

Das Grundprinzip

Beim Server-Side Tagging schickt der Browser Daten nicht direkt an Google oder Meta, sondern an einen eigenen Server. Dort läuft ein Server-Container des Tag Managers, erreichbar unter einer Subdomain deiner Website, zum Beispiel einer Adresse wie daten.deine-seite.de. Der Server nimmt die Daten entgegen und leitet sie an die Anbieter weiter.

Bei Client-Side Tagging dagegen laden alle Tags im Browser und senden von dort. Jeder Anbieter bekommt seine Daten direkt vom Besucher, und du hast auf dem Weg dorthin keinen Zugriff. Server-Side verlagert diesen Teil auf einen Server, den du kontrollierst. Der Server wird zur Zwischenstation, an der du entscheiden kannst, was weitergeht.

Vorteile

• Mehr Kontrolle: Der Server kann Daten vor der Weitergabe kürzen oder Felder entfernen.
• Weniger Blockaden, weil Aufrufe an deine eigene Subdomain gehen.
• Weniger Skripte im Browser.
• Weg für die Meta Conversions API.

Entscheidend ist der erste Punkt: Du entscheidest, was der Server weitergibt. Ein Beispiel: Der Browser schickt eine Seitenadresse mit allen Parametern. Der Server kann Parameter entfernen, die du nicht an Google weitergeben willst, bevor die Anfrage den Server verlässt. Das hilft bei der Datenminimierung, ist aber nur so gut wie die Konfiguration. Ein Server, der alles ungefiltert durchreicht, bringt dir an dieser Stelle nichts.

Der zweite Punkt, weniger Blockaden, hat Grenzen. Aufrufe an deine eigene Domain werden seltener blockiert als Aufrufe an bekannte Tracking-Adressen, aber das Skript, das die Daten im Browser einsammelt, bleibt vorhanden und kann weiterhin eingeschränkt werden. Es ist eine Verbesserung der Datenbasis, kein vollständiger Schutz vor Verlusten.

Passend dazu: Server-Side oder Client-Side Tagging?

Wie es technisch aussieht

Neben dem bekannten Web-Container richtest du im Tag Manager einen Server-Container ein und hostest ihn, zum Beispiel bei einem Cloud-Anbieter. Im Browser sendet ein Tag Ereignisse aus dem dataLayer an deine Subdomain. Im Server-Container nehmen sogenannte Clients die Anfragen an und übersetzen sie in ein Ereignis. Tags im Server-Container leiten dieses Ereignis dann an GA4, Google Ads oder Meta weiter.

Der Web-Container bleibt also bestehen. Er sammelt weiter die Ereignisse im Browser, schickt sie aber nicht mehr an jeden Anbieter einzeln, sondern an den Server. Bestehende Tags müssen deshalb angepasst oder neu aufgebaut werden. Das ist die eigentliche Arbeit: nicht den Server hochzufahren, sondern jedes Ereignis, das bisher direkt gesendet wurde, sauber durch den neuen Weg zu führen.

Ein Beispiel aus der Praxis

Ein kleiner Shop läuft bisher mit GA4, Google Ads und Meta Pixel direkt im Browser. Beim Umstieg schickt der Web-Container die Kauf-Ereignisse an den Server-Container. Dort wandelt ein Tag das Ereignis für GA4 um, ein zweites für Google Ads und ein drittes für die Meta Conversions API. Der Pixel im Browser kann parallel weiterlaufen, dann braucht es dieselbe Ereignis-ID auf beiden Wegen, damit Meta nichts doppelt zählt.

Für einen Handwerksbetrieb mit Kontaktformular wäre derselbe Umbau Aufwand ohne spürbaren Nutzen. Es gibt wenige Ereignisse, und ein verlorenes fällt weniger ins Gewicht.

Kosten

Der Server-Container braucht dauerhaft laufendes Hosting. Die Kosten richten sich nach der Zahl der Anfragen und dem Anbieter. Dazu kommen Einrichtung und laufende Pflege, denn jede Änderung am Tracking betrifft jetzt zwei Container. Konkrete Beträge und Kostenblöcke findest du in unserem Artikel zu den Kosten von Server-Side Tracking.

Einwilligung bleibt nötig

Server-Side Tracking ist kein Freibrief. Für Werbe- und Analyse-Zwecke brauchst du weiterhin die Einwilligung der Besucher, und der Server darf nur senden, was dadurch gedeckt ist. Der Server bietet technische Möglichkeiten zur Datenminimierung, ändert aber nichts an den rechtlichen Anforderungen.

Das hat auch eine praktische Seite: Der Einwilligungsstatus muss vom Browser zum Server gelangen und dort ausgewertet werden. Ein Server, der Ereignisse unabhängig vom Banner weiterleitet, umgeht die Entscheidung des Besuchers. Das ist der klassische Fehler. Dieser Artikel ist keine Rechtsberatung.

So prüfst du, ob es funktioniert

Der Server-Container hat wie der Web-Container eine Vorschau. Du siehst dort, welche Anfragen ankommen, welcher Client sie annimmt und welche Tags sie weiterleiten. Prüfe zuerst, ob jedes Ereignis genau einmal am Server ankommt. Prüfe dann in GA4, Google Ads oder dem Events Manager von Meta, ob die Ereignisse dort mit den richtigen Werten erscheinen.

Teste anschließend ohne Einwilligung: Der Server darf dann nicht an Anbieter weiterleiten, für die keine Zustimmung vorliegt. Typische Fehler sind doppelte Ereignisse, weil Browser und Server parallel senden, fehlende Werte, weil ein Parameter beim Umbau nicht übernommen wurde, und eine Subdomain, die nicht erreichbar ist.

Wann es sich lohnt

Beginne mit einem sauberen Web-Setup inklusive Consent Mode, bevor du den Server-Container ergänzt. Ein Server macht ein unsauberes Tracking nicht besser, sondern nur teurer. Wenn Ereignisse dort sauber definiert sind, der Consent Mode zuverlässig läuft und du siehst, dass dir durch Blocker nennenswert Conversions fehlen, kann der Umstieg sinnvoll sein. Für kleine Websites mit wenig Werbebudget ist er selten nötig.

Trackum bietet Server-Side Tracking bald an; Interesse kannst du vormerken lassen.