Server-Side-Tagging: verlagert, nicht verschwunden

Die Liste der Drittanbieter-Requests wird kurz, das Cookie-Inventar überschaubar, und im Netzwerk-Tab steht statt einer Handvoll fremder Domains nur noch eine einzige: eine Subdomain der eigenen Website. Auf dem Papier sieht das nach einem sauber aufgeräumten Setup aus.

Tatsächlich hat sich vor allem der Weg geändert, den die Daten nehmen. Server-Side-Tagging verlegt die Weitergabe an Google, Meta und andere Dienste vom Browser auf einen Server, den du selbst betreibst. Der Vorgang, an dem die Einwilligung hängt, bleibt dabei genau dort, wo er war.

Im klassischen Aufbau lädt deine Seite Skripte von googletagmanager.com, google-analytics.com, connect.facebook.net und weiteren Hosts. Jedes dieser Skripte spricht anschließend direkt mit dem Server seines Anbieters.

Beim Server-Side-Tagging kommt eine Zwischenstation dazu: ein zweiter Container, der nicht im Browser läuft, sondern auf einer Serverinstanz – bei Google Tag Manager typischerweise in einer Cloud-Umgebung, erreichbar unter einer eigenen Adresse wie metrics.example.com oder unter einem Pfad der Hauptdomain. Der Browser schickt seine Ereignisse nur noch dorthin. Der Server entscheidet dann, was er an welche Plattform weitergibt.

Wichtig für das Verständnis: Der Container im Browser verschwindet dabei in den meisten Setups nicht. Er sammelt weiter Ereignisse, liest weiter Werte aus der Seite und schickt sie weiter fort – nur an eine andere Adresse.

Wer Server-Side-Tagging als Datenschutzmaßnahme beschrieben bekommt, sollte diese Liste kennen. Sie enthält die Vorgänge, die § 25 TDDDG adressiert – und keiner davon wandert auf den Server:

§ 25 Absatz 1 TDDDG knüpft die Einwilligung an das Speichern von Informationen in der Endeinrichtung und den Zugriff auf dort bereits gespeicherte Informationen. Beides passiert im Browser, unabhängig davon, an welche Adresse das Ergebnis geschickt wird. Ein eigener Zwischenserver ändert an diesem Vorgang nichts – er ist der Empfänger, nicht der Ort des Zugriffs.

Die Leitlinien 2/2023 des Europäischen Datenschutzausschusses zum technischen Anwendungsbereich von Art. 5 Abs. 3 der ePrivacy-Richtlinie, Endfassung von Oktober 2024, beschreiben diese Technologieoffenheit ausführlich und behandeln unter anderem Fälle, in denen keine Datei gespeichert wird. Für IP-Adressen zieht der Ausschuss eine feine Linie: Erfasst ist der Zugriff dann, wenn die Information aus der Endeinrichtung des Nutzers stammt. Wie das auf ein konkretes Setup anzuwenden ist, klärst du mit deiner Datenschutzberatung – technisch beobachtbar ist zunächst nur, dass der Request stattfindet.

In den Google-Setups reist der Consent-Zustand deshalb als Parameter mit: Bei aktivem Consent Mode hängen die Tags Werte wie gcs und gcd an ihre Requests, und der Server-Container liest sie aus, um zu entscheiden, was er weitergibt. Diese Prüfung ist echt und wirksam – sie findet aber statt, nachdem die Daten das Endgerät verlassen haben.

Hier liegt der Punkt, an dem Server-Side-Tagging technisch tatsächlich etwas verändert. Ein Cookie, das per JavaScript über document.cookie geschrieben wird, ist etwas anderes als ein Cookie, das ein Server im Set-Cookie-Kopf der Antwort mitschickt. Der Google-Tag-Manager-Server-Container nutzt dafür ein eigenes Cookie namens FPID, gesetzt vom Server und mit dem HttpOnly-Flag versehen: kein Skript im Browser kann es lesen. Für Zwecke, die Skriptzugriff brauchen – etwa Wiedererkennung über zwei Domains hinweg – legt Google zusätzlich ein FPLC-Cookie an, einen kurzlebigen Abgleichwert von wenigen Stunden.

Bei der Lebensdauer wird oft mit einer veralteten Faustregel argumentiert. Die Behauptung, Safari kappe JavaScript-Cookies grundsätzlich auf sieben Tage, war bis 2022 richtig; seither ist die Obergrenze für das Ablaufdatum weg. Stattdessen behandelt WebKit skriptbeschreibbaren Speicher einheitlich: Er wird gelöscht, wenn eine Website über sieben Tage aktiver Browsernutzung hinweg keine Interaktion sieht.

Server-gesetzte Cookies fallen nicht unter diese Regel – mit einer Ausnahme, die den Vorteil an eine Bedingung knüpft. Seit Safari 16.4 vom April 2023 prüft der Browser, ob die Adresse, die das Cookie setzt, zur besuchten Website gehört. Löst der Tagging-Server auf eine IP-Adresse auf, deren erste Hälfte nicht zur IP-Adresse der Website passt, wertet Safari das als verdeckten Drittanbieter und begrenzt das Cookie auf sieben Tage – ganz gleich, welches Ablaufdatum im Set-Cookie-Kopf steht. Die Haltbarkeit hängt damit an einem Detail der Infrastruktur, nicht am Server-Side-Tagging als solchem.

Für die Prüfung ist das Setup unbequem, aber nicht undurchsichtig. Erkennbar bleibt es, weil der Browser weiterhin Requests schickt und die Pfade dieser Requests von der Software vorgegeben sind, nicht von der Domain:

Parallel dazu hat Google einen zweiten Weg ausgebaut, der ohne eigenen Container auskommt. Beim Google Tag Gateway für Werbetreibende wird der Google-Tag über die eigene Infrastruktur ausgeliefert – über einen CDN, einen Load Balancer oder den eigenen Webserver, angeboten unter anderem mit Cloudflare, Akamai, Fastly und Google Cloud. Die Variante auf Google Cloud ist seit Juni 2026 allgemein verfügbar, nach einer Beta-Phase ab Januar.

Aus Prüfsicht verschärft das denselben Effekt: Skript und Messrequests laufen unter einem Pfad der eigenen Domain, es gibt keine fremde Domain mehr, an der ein Filter oder eine Blockliste ansetzen könnte. Was gemessen und weitergegeben wird, ändert sich dadurch nicht. Es ist eine Frage der Auslieferung, keine der Datenverarbeitung.

Das Prüfmodell bleibt dasselbe: einmal vor jeder Interaktion mit dem Banner schauen, einmal nach dem Ablehnen, einmal nach dem Annehmen. Der Blick verschiebt sich nur von der Frage „welche fremden Domains werden kontaktiert“ zu „was schickt der Browser an meine eigene Adresse, und was macht die damit“.

Der erste Teil ist weiterhin messbar: Requests vor der Einwilligung, geschriebene Kennungen, gesetzte Cookies – alles sichtbar im Browser. Der zweite Teil ist nicht mehr messbar, sondern eine Frage der Dokumentation. Welche Plattformen der Server-Container bedient, welche Felder er weiterreicht und welche er verwirft, steht in seiner Konfiguration und in den Verträgen dahinter, nicht im Netzwerk-Tab. Wer Server-Side-Tagging einsetzt, übernimmt damit ein Stück Nachweisarbeit, das vorher der Anbieter geleistet hat.