Server-seitiges Tracking: Wenn der Schein der ersten Partei die Wirklichkeit der dritten Partei verdeckt

Das serverseitige Tracking hat sich zur wichtigsten Reaktion der Werbebranche auf Datenschutzmaßnahmen auf Browserebene entwickelt: ITP, ETP und die Abkehr von Drittanbieter-Cookies. Das Prinzip ist einfach: Leiten Sie die Pixel der Anbieter über Ihre eigene Domain weiter, und der Browser behandelt sie als Erstanbieter-Pixel. Was selten offen angesprochen wird, ist, dass diese Architektur nach der DSGVO eine unrechtmäßige Verarbeitung personenbezogener Daten darstellen kann, unabhängig davon, welcher DNS-Eintragstyp zu ihrer Umsetzung verwendet wird.

Die drei Implementierungsmuster – und ihre rechtlich unterschiedlichen Profile

1. CNAME-Cloaking

CNAME-Cloaking beinhaltet die Erstellung eines DNS-Eintrags CNAME Eintrag, der eine Subdomain Ihrer eigenen Domain (z. B. metrics.example.com) auf die Infrastruktur eines Anbieters (z. B. data.vendor-cdn.com). Der Browser sieht nur die Subdomain, die die eTLD+1 mit dem Publisher teilt – und erhält daher First-Party-Cookies. In der Praxis wird die HTTP-Anfrage letztendlich von den Servern des Anbieters aufgelöst und verarbeitet.

Die technische Konsequenz: Cookies, die vom Anbieter über diesen CNAME-Endpunkt gesetzt werden, erben den First-Party-Gültigkeitsbereich. Entscheidend ist, dass die CNAME-Cloaking-Abwehr von ITP (eingeführt in Safari 14) die Lebensdauer von über CNAME gesetzten Cookies nun auf 7 Tage begrenzt und Firefox 90+ bekannte CNAME-Tracker über seine von Disconnect.me gepflegte Enhanced Tracking Protection-Liste blockiert. Chrome wendet derzeit keine solche Einschränkung an – wodurch CNAME-Cloaking gerade in dem Browser mit dem größten Marktanteil am effektivsten ist.

Aus Sicht der DSGVO bricht hier die Grenze zwischen Verantwortlichem und Auftragsverarbeiter zusammen. Die Server des Anbieters erhalten die vollständige HTTP-Anfrage einschließlich Cookie, Referer, User-Agentund IP-Adress-Headern – doch die betroffene Person hat keinen Hinweis darauf, dass ein Dritter beteiligt ist. Erwägungsgrund 60 der DSGVO verlangt, dass Datenschutzhinweise die tatsächlichen Empfänger personenbezogener Daten benennen. Ein Datenschutzhinweis, der lediglich „Analytics“ aufführt, ohne den konkreten Anbieter zu benennen, der Daten über CNAME erhält, ist mit ziemlicher Sicherheit nicht konform. Die Leitlinien 05/2020 des EDPB zur Einwilligung bestätigen, dass sich die Transparenz auf konkrete Dritte erstrecken muss, nicht auf allgemeine Kategorien.

2. Server-seitige Container von GTM

Der serverseitige Modus (sGTM) des Google Tag Managers setzt einen Node.js-basierten Container ein – typischerweise auf Google Cloud Run, aber auf jede Infrastruktur übertragbar – in einer First-Party-Subdomain. Clientseitige Tags senden eine einzelne Anfrage an diesen Container-Endpunkt (z. B. collect.example.com/g/collect), und der Container leitet die Daten dann serverweise an Google Analytics 4, Meta CAPI, die TikTok Events API und andere weiter.

Die technische Architektur ist hier besser zu rechtfertigen als reines CNAME-Cloaking: Der Betreiber kontrolliert den Server-Container und kann Daten grundsätzlich vor der Weiterleitung filtern oder redigieren. Die X-Forwarded-For Header-Handhabung wird entscheidend – wenn der sGTM-Container die ursprüngliche Client-IP an GA4 oder Meta weiterleitet, sind Behauptungen zur IP-Anonymisierung hinfällig, da die vollständige IP zum Endpunkt des Anbieters gelangt. Betreiber sollten über Protokollierung auf Netzwerkebene überprüfen, ob ihre sGTM-Konfiguration IP-Adressen vor der Weiterleitung entfernt oder ob das Standardverhalten request.extractMacAddress() Verhalten Gerätekennungen preisgibt.

Gemäß Art. 26 DSGVO gilt die gemeinsame Verantwortlichkeit, wenn sowohl der Betreiber als auch Google gemeinsam die Zwecke und Mittel der Verarbeitung festlegen – was der Fall ist, wenn Verhaltensdaten aus dem Container in die Werbeinfrastruktur von Google eingespeist werden. Das Urteil des EuGH in der Rechtssache Fashion ID (C-40/17) stellte fest, dass die Einbettung von Funktionen Dritter, die eine Datenübertragung bewirken, den Einbettenden zu einem gemeinsam Verantwortlichen für diese Erhebungsphase macht, selbst wenn er keinen Zugriff auf die erhobenen Daten selbst hat. sGTM hebt diese Beziehung nicht auf; es verlagert lediglich den Erhebungsort.

3. Missbrauch von First-Party-Daten-Endpunkten

Ein subtileres Muster betrifft legitime First-Party-Endpunkte – API-Schnittstellen für Bestellbestätigungen, Login-Endpunkte, Handler für Newsletter-Abonnements –, die so instrumentiert werden, dass sie Verhaltens- und Transaktionsdaten an Anbieterplattformen weiterleiten. Ein POST an api.example.com/checkout/complete könnte ein serverseitiges Ereignis an die Meta Conversions API auslösen, angereichert mit einer gehashten E-Mail-Adresse, dem Bestellwert und einem Geräte-Fingerabdruck, der aus User-Agent und Accept-Language Headers.

Dadurch wird das Einwilligungsmanagement vollständig umgangen, da kein clientseitiges JavaScript ausgelöst wird. Der Nutzer hat zwar die für den Checkout notwendigen „funktionalen Cookies“ akzeptiert – doch die Auslegung der Datenschutzbehörde (siehe die Orientierungshilfe der DSK zum Tracking, 2022) stellt klar, dass die serverseitige Weiterleitung von Transaktionsdaten an Werbeplattformen zur Conversion-Attribution nicht funktional notwendig ist und eine ausdrückliche Einwilligung gemäß Art. 6 Abs. 1 lit. a DSGVO erfordert. Die Rechtsgrundlage ändert sich nicht aufgrund der technischen Ebene, auf der die Verarbeitung stattfindet.

Behauptungen zur Pseudonymisierung halten einer genauen Prüfung nicht stand

Anbieter argumentieren häufig, dass gehasht E-Mails (SHA-256 von [email protected]) eine ausreichende Pseudonymisierung darstellen, um das Risiko zu senken. Dieses Argument scheitert an der Definition in Art. 4 Abs. 5 DSGVO: Pseudonymisierte Daten bleiben personenbezogene Daten, wenn eine Re-Identifizierung mit zusätzlichen Informationen möglich ist, die sich im Besitz einer beliebigen Partei befinden. Der Abgleichprozess von Metas „Custom Audiences“ ist genau dieser Schritt der Re-Identifizierung – der Hash wird mit Metas bekannter Hash-Datenbank abgeglichen. Die EDPB-Leitlinien 04/2019 zu Artikel 25 gehen ausdrücklich darauf ein: Eine Pseudonymisierung verringert das Risiko nur dann, wenn der Schlüssel beim Verantwortlichen verbleibt; hier ist der „Schlüssel“ Metas vorberechnete Hash-Tabelle.

Fehler bei der Weitergabe von Einwilligungsstrings

TCF 2.2-Einwilligungsstrings sind clientseitige Artefakte, die localStorage oder in Cookies unter dem Schlüssel euconsent-v2. Serverseitige Tracking-Architekturen unterbrechen systematisch die Weitergabe von Consent Strings, sofern sie nicht ausdrücklich darauf ausgelegt sind, diese weiterzuleiten. Ein sGTM-Container, der ein clientseitiges Ereignis empfängt, muss den Consent String aus der Nutzlast der eingehenden Anfrage lesen und ausgehende Anrufe an Anbieter auf der Grundlage der TC-String-Analyse bedingt blockieren – ein Verhalten, das eine benutzerdefinierte Implementierung erfordert, keine Standardkonfiguration. Betreiber, die sich für die Anbieterverteilung auf sGTM verlassen, ohne die Durchsetzung des TC-Strings zu überprüfen, lösen wahrscheinlich Anbieter-Tags aus, die gegen die TCF-Richtlinien von IAB Europe und, was noch wichtiger ist, gegen die aufgezeichneten Einwilligungsentscheidungen des Nutzers verstoßen.

Umsetzbare Empfehlungen

• CNAME-Einträge prüfen: Führen Sie dig CNAME metrics.yourdomain.com für jede Analytics-/Marketing-Subdomain aus. Ordnen Sie jedes CNAME-Ziel seinem endgültigen Verantwortlichen zu. Dokumentieren Sie dies in Ihren Aufzeichnungen über Verarbeitungstätigkeiten (RoPA) gemäß Art. 30 DSGVO.
• Überprüfen Sie den ausgehenden sGTM-Datenverkehr: Aktivieren Sie die Anforderungsprotokollierung von Google Cloud Run und analysieren Sie ausgehende HTTP-Aufrufe aus Ihrem Container. Stellen Sie sicher, dass Client-IP-Adressen in anbietergebundenen Anfragen anonymisiert erscheinen (z. B. auf /24 gekürzt), indem Sie X-Forwarded-For und True-Client-IP Header.
• Setzen Sie den TC-String in sGTM durch: Implementieren Sie eine benutzerdefinierte Variable in Ihrem sGTM-Container, die euconsent-v2 aus der Nutzlast des eingehenden Client-Ereignisses analysiert und jeden Tag-Trigger anhand des entsprechenden Zustimmungsbits des Anbieters (Zweck 1, Zweck 7 usw.) steuert.
• Aktualisieren Sie die Datenschutzhinweise: Gemäß den EDPB-Leitlinien 05/2020 müssen Sie bestimmte Anbieter nennen, die Daten über serverseitige Weiterleitung erhalten. „Drittanbieter von Analysediensten“ erfüllt nicht die Anforderung von Art. 13 Abs. 1 Buchstabe e DSGVO, Empfänger zu identifizieren.
• Überprüfen Sie die Rechtsgrundlage für serverseitige Conversions-API-Aufrufe: Wenn Ihr Checkout- oder CRM-System Transaktionsdaten an Werbeplattformen weiterleitet, dokumentieren Sie die Rechtsgrundlage ausdrücklich. Ein berechtigtes Interesse gemäß Art. 6 Abs. 1 Buchstabe f wird die Abwägungsprüfung für die Werbeattribution angesichts der Sensibilität von Daten zum Kaufverhalten wahrscheinlich nicht bestehen.
• Kenntnis der DPA-Landschaft: Die französische CNIL hat in ihren Cookie-Leitlinien für 2022 bereits Sanktionen gegen CNAME-Cloaking-Implementierungen verhängt. Die irische DPC und die deutsche LfDI Baden-Württemberg haben beide offizielle Stellungnahmen veröffentlicht, in denen sie die serverseitige Erhebung ohne Einwilligung als gleichwertig mit clientseitigen Verstößen behandeln.

Die rechtliche Kernaussage lautet: Die DSGVO regelt Datenflüsse, nicht Mechanismen der Datenerhebung. Die Verlagerung von Pixeln auf die Serverseite verlagert nicht die rechtliche Verantwortung – sie verlagert lediglich die technische Sichtbarkeit. Die Datenschutzbehörden verfügen zunehmend über technisches Fachwissen, und das Argument, dass sich die serverseitige Verarbeitung in ihrem rechtlichen Charakter von der clientseitigen Verarbeitung unterscheidet, findet weder im Wortlaut der Verordnung noch in den aktuellen Leitlinien der Aufsichtsbehörden eine Grundlage.

Dieser Artikel wurde mit KI-Unterstützung erstellt und gegen verifizierte DSGVO-Rechtsprechung (GDPRhub) geprüft. Für Rechtsberatung wenden Sie sich an einen qualifizierten Datenschutzexperten.