Consent Mode v2 ist seit dem 06.03.2024 nicht mehr optional. Seit diesem Datum muss der Traffic aus der EU und dem EWR in die Werbeprodukte von Google zwei neue Signale übermitteln — ad_user_data und ad_personalization — zusammen mit den ursprünglichen Signalen ad_storage und analytics_storage. Diese Änderung wurde nicht durch die GDPR, sondern durch den Digital Markets Act (Verordnung (EU) 2022/1925) vorangetrieben, insbesondere durch Art. 5(2) DMA, der es benannten Gatekeepern untersagt, personenbezogene Daten über verschiedene Dienste hinweg ohne ausdrückliche Einwilligung zu kombinieren oder zu nutzen.
Für einen URL-Shortener, der die Redirect-Datenebene auf komplexe Weise kreuzt, ist das eine Herausforderung. Ein Kurzlink ist das, was der Nutzer angeklickt hat; der Consent-Status auf der Landingpage entscheidet darüber, ob der Klick attribuiert werden darf. Diese beiden Ereignisse finden auf unterschiedlichen Domains, in unterschiedlichen Cookie-Speichern und oft in verschiedenen Sessions statt. In der Lücke dazwischen liegt heute der Großteil des Attributionsverlusts.
Dieser Beitrag ist die Analyse eines Compliance-Beraters darüber, was sich geändert hat, was die vier Signale tatsächlich für einen Redirect-Dienst bedeuten, wo Server-Side-Recovery nach den aktuellen Leitlinien des EDPB legal ist und wo nicht. Der Großteil der technischen Arbeit für GA4-Server-Side-Tracking via Redirects ist unter der GDPR unbedenklich; ein Teil davon ist unter dem DMA jedoch nicht zulässig.
Der DMA in einem Absatz#
Der Digital Markets Act ist seit dem 07.03.2024 anwendbar. Er benennt „Gatekeeper“ — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — und erlegt ihnen Ex-ante-Verpflichtungen auf. Art. 5(2) DMA ist der entscheidende Punkt für das Tracking: Ein Gatekeeper darf personenbezogene Daten von Endnutzern von Drittanbieter-Diensten nicht für Online-Werbung verarbeiten und auch keine personenbezogenen Daten über seine Dienste hinweg kombinieren, es sei denn, es liegt eine Einwilligung vor.
Consent Mode v2 ist der Compliance-Mechanismus von Google für Art. 5(2). Die zwei neuen Signale — ad_user_data und ad_personalization — ermöglichen es dem Gatekeeper zu prüfen, ob der Publisher eine Einwilligung gemäß Art. 5(2)-Standard eingeholt hat, bevor Klick-Telemetriedaten für Werbung oder Personalisierung verwendet werden. Ohne diese auf granted gesetzten Signale fallen die Werbeprodukte von Google auf aggregierte oder modellierte Conversions ohne nutzerbezogene Attribution zurück.
Der DMA ersetzt die GDPR nicht. Er ergänzt sie. Ein Controller benötigt weiterhin eine Rechtsgrundlage nach Art. 6 GDPR; Consent Mode v2 fügt eine zweite Hürde hinzu, die sich für über Gatekeeper geleitete Werbedaten schließt, selbst wenn die GDPR-Hürde genommen wurde.
Die vier Signale einfach erklärt#
Consent Mode v2 liefert vier boolesche Signale. Jedes kann auf granted (erteilt) oder denied (abgelehnt) stehen. Standardwerte können pro Region festgelegt werden.
ad_storage — das ursprüngliche v1-Signal. Steuert, ob Cookies oder andere Speicher für Werbung geschrieben werden dürfen. Wenn auf denied gesetzt, werden Google-Tags ohne Identifier ausgelöst; die Conversion-Messung wird auf cookielose, modellierte Aggregate reduziert. Der Redirect entscheidet, welche UTM-Parameter und Click-Identifier auf der Seite landen, und diese werden zu den Schlüsseln, an die sich der Consent heftet. Die Tag-Plattform Consent-Dokumentation ist die kanonische Referenz dafür, was jedes Signal im weiteren Verlauf bewirkt.
ad_user_data — neu in v2. Steuert, ob Nutzerdaten überhaupt zu Werbezwecken an Google gesendet werden dürfen. Dies ist das Signal für Art. 5(2) DMA. Wenn auf denied gesetzt, darf der Tag keine Nutzerdaten — einschließlich gehashter Identifier, IP-Adresse oder User-Agent — an Google Ads übertragen. Server-Side-Tagging umgeht dies nicht; das Signal wird mit dem Event übertragen.
ad_personalization — ebenfalls neu. Steuert, ob übertragene Daten für personalisierte Werbung, einschließlich Remarketing, verwendet werden dürfen. Eine häufige Konfiguration ist ad_user_data=granted zusammen mit ad_personalization=denied, was die Attribution erlaubt, aber Remarketing blockiert.
analytics_storage — steuert, ob Speicher für Analysen geschrieben werden darf. Der GA4-Tag berücksichtigt dies; wenn auf denied gesetzt, läuft GA4 cookielos und nutzt Consent-Mode-Modellierung, um die Attribution auf aggregierter Ebene zu rekonstruieren. Die Modellierung erfordert ein gewisses Mindestvolumen an Traffic und eine 7-tägige Lernphase.
Keines der vier Signale wird beim Shortener entschieden. Der Shortener löst den Klick aus; die Landingpage liest die Signale; der Tag auf der Landingpage entscheidet, was damit geschieht. Die Aufgabe des Shorteners ist es, einen sauberen Status zu liefern — erhaltene UTM-Parameter, erhaltene Click-Identifier, schneller Redirect —, damit das Banner geladen werden kann, bevor der Tag ausgelöst wird.
Was auf der Redirect-Datenebene schiefgeht#
Drei Fehlerszenarien treten bei jedem Shortener auf, der den Redirect-Pfad ernst nimmt.
Der Click-Identifier bleibt erhalten, das Consent-Signal jedoch nicht. Ein Klick auf eine Meta-Anzeige landet auf s.elido.me/abc123?fbclid=… und leitet weiter zu https://customer.example/landing?fbclid=…. Die fbclid bleibt erhalten. Die Seite lädt, das Banner erscheint, der Nutzer lehnt ab. Meta CAPI hat bereits einen Klick empfangen, der mit dieser fbclid verknüpft ist — aber der Nutzer hat nun die werbliche Nutzung abgelehnt. Der Shortener hat nichts falsch gemacht; der Controller muss ein CAPI-Deduplizierungsproblem auf seinem Endpoint lösen.
Der Shortener hängt Identifier an, die die Landingpage nicht versteht. Einige Shortener (Bitly's bitly_session, Rebrandly's _branch_match_id) hängen anbieterspezifische Parameter an, die bei abgelehntem Consent entfernt oder speziell behandelt werden müssen. Elido leitet standardmäßig nur UTM-Parameter und den eigenen Click-Identifier des Kunden weiter.
Der Consent-Status der Landingpage ist aus der Perspektive des Redirects nicht erkennbar. Der Shortener kann kein Banner sehen, das noch nicht geladen wurde. Server-seitige Fallback-Entscheidungen können nicht von einem Consent-Status abhängig gemacht werden, der noch gar nicht existiert. Die einzige ehrliche Voreinstellung: Lösen Sie zum Zeitpunkt des Redirects kein server-seitiges Event zu Werbezwecken aus; lassen Sie das Banner laden und dann die Seite oder deren Proxy mit dem angehängten Consent-Status feuern.
Anbieter, die Measurement Protocol- oder CAPI-Events direkt vom Edge auslösen, wetten darauf, dass der Nutzer seine Einwilligung geben wird. Unter Art. 5(2) DMA steht ihnen diese Wette nicht zu. Die EDPB-Leitlinien 02/2023 zum technischen Anwendungsbereich von Artikel 5(3) ePrivacy haben den verwandten Punkt zur Injektion von Identifiern vor dem Consent klargestellt: Es handelt sich um eine Verarbeitung, sie benötigt eine Grundlage, und das Fehlen eines Banners ist keine Grundlage.
Legale Server-Side-Maßnahmen#
Die unten aufgeführten Maßnahmen sind diejenigen, die sowohl unter der GDPR als auch unter dem DMA Bestand haben. Sie haben einen gemeinsamen Kern: Der Consent-Status muss festgestellt werden, bevor Daten an einen Gatekeeper übertragen oder für Werbung verwendet werden.
Measurement Protocol mit angehängtem Consent-Status. Das Measurement Protocol von GA4 akzeptiert die gleichen consent-Parameter wie der gtag-Client. Das Muster: Die Landingpage klärt den Consent über das Banner, sendet den Status an den First-Party-Server des Kunden, und der First-Party-Server leitet eine mp/collect-Anfrage an GA4 weiter, wobei consent.ad_user_data und consent.ad_personalization entsprechend gesetzt sind. Server-seitig, aber dem Consent-Vorgang nachgelagert. Der Forwarder von Elido (beschrieben in GA4-Server-Side-Tracking via Redirects) wendet den Consent-Status auf die ausgehende Payload an.
Conversion API mit Consent-Strings. Meta CAPI akzeptiert data_processing_options und opt_out; LinkedIn's Conversions API akzeptiert enlli; TikTok's Events API akzeptiert limited_data_use. Alle diese Signale übermitteln den Consent-Status an die Plattform. Das Muster ist identisch: Landingpage lädt, sendet an First-Party-Server, First-Party-Server feuert mit angehängtem Consent-Status.
Aggregiertes Server-Side-Reporting. Wenn der Consent-Status die Nutzung für Werbung oder Analysen ablehnt, ist ein server-seitiges Reporting, das echt aggregiert ist und keine nutzerbezogenen Identifier enthält, unter Art. 5(2) DMA und unter Art. 6 GDPR auf Basis eines berechtigten Interesses im Allgemeinen zulässig. Die EDPB-Leitlinien 04/2023 zur Anonymisierung betonen erneut, dass pseudonymisierte Daten keine anonymen Daten sind und dass eine geringe k-Anonymität weiterhin eine Re-Identifizierung ermöglicht. Die konservative Praxis besteht darin, Zahlen auf Workspace-Ebene mit einem Schwellenwert von ≥10 zu veröffentlichen.
First-Party-Identifier-Auflösung auf der Landingpage. Der resilienteste Ansatz besteht darin, den Nutzer über ein Signal nach Art. 6(1)(b) GDPR zu identifizieren — er hat sich angemeldet, ein Formular ausgefüllt oder auf einen bestätigten E-Mail-Link geklickt — und die Attribution rückwirkend vorzunehmen. Dies ist völlig unabhängig von ad_storage oder ad_user_data. Der Beitrag Click-Attribution nach Safari ITP beschreibt dieses Muster; es ist auch für die Welt nach dem DMA die richtige Antwort.
Nicht legale Server-Side-Maßnahmen#
Drei Muster tauchen immer wieder in Verkaufsgesprächen von Tool-Anbietern auf, sollten aber vermieden werden.
Auslösen von CAPI-Events am Edge, bevor der Consent auf der Landingpage feststeht. Dies ist das oben beschriebene Fehlerszenario. Es gibt keinen Consent-Status, den man anhängen könnte; das Auslösen des Events impliziert, dass der Controller die Einwilligung eingeholt hat, was jedoch nicht der Fall ist. Einige Anbieter bezeichnen dies als „deterministische Attribution“; unter Art. 5(2) DMA ist es eine Datenkombination, die der Nutzer nicht autorisiert hat.
Hashen der IP und Behandlung des Hashs als anonym. Der EDPB hat bereits in der Stellungnahme 4/2007 zum Begriff der personenbezogenen Daten klargestellt und in den Leitlinien 04/2023 bekräftigt, dass gehashte Identifier personenbezogene Daten bleiben, wenn der Hash für jeden mit Zugang zur Grundgesamtheit umkehrbar ist. IP-Hashes sind in großem Maßstab leicht umkehrbar; der Hash ändert nichts am rechtlichen Charakter der Verarbeitung.
Server-seitiger Identifier-Sync mit Gatekeepern. Die Weiterleitung des Click-Events an Google oder Meta mit einer gehashten E-Mail-Adresse oder Telefonnummer, wobei man sich darauf verlässt, dass der Gatekeeper diese mit seinem eigenen Identifier-Graphen abgleicht, ist genau der Vorgang, den Art. 5(2) DMA einschränkt. Der Abgleich ist eine dienstübergreifende Datenkombination durch den Gatekeeper. Die Einwilligung hierfür muss ausdrücklich und auf Nutzerebene erfolgen. Das Vorhandensein des Hashs macht den Vorgang nicht rechtmäßig; das Fehlen der Einwilligung macht ihn unrechtmäßig.
Aktueller Kontext von EuGH und EDPB#
Zwei aktuelle Schritte der Regulierungsbehörden schärfen das Bild.
Das Urteil des EuGH in der Rechtssache C-621/22 (Royal Lichtervelde, 2024) bestätigte die Joint-Controller-Analyse aus den Fällen Wirtschaftsakademie (C-210/16) und Fashion ID (C-40/17). Wenn ein Publisher einen Drittanbieter-Tag integriert und dieser Tag Nutzerdaten an den Drittanbieter überträgt, sind der Publisher und der Drittanbieter gemeinsam Verantwortliche (Joint Controllers) für diese Verarbeitung. Art. 26 GDPR erfordert eine transparente Vereinbarung zwischen ihnen. Für einen Consent Mode v2 Kunden muss die Art. 26 Vereinbarung mit Google bestehen und der Consent-Status muss ehrlich übermittelt werden. Das Fälschen von ad_user_data=granted zur Wiederherstellung der Attribution stellt ein Joint-Controllership-Haftungsrisiko für beide Seiten dar.
Die EDPB-Leitlinien 03/2024 über Consent-Signale im Werbekontext (Konsultationsentwurf, Abschluss für Q3 2026 erwartet) befassen sich explizit mit Consent Mode v2. Der Entwurf stellt fest, dass das Signal ad_user_data gemäß Art. 7(4) GDPR von einer freiwillig erteilten Einwilligung abhängig ist und dass Banner, die ad_storage mit ad_user_data bündeln, ohne granulare Kontrollen zu bieten, den Test der Freiwilligkeit nach Art. 7 nicht bestehen. Die meisten aktuellen Banner bündeln diese. Die Neugestaltung liegt beim Kunden; der Shortener liefert den sauberen Status, er gestaltet nicht das Banner.
Für das breitere Bild der Datentransfers — Einwilligung erteilt, Daten verlassen dennoch die EU — deckt der Beitrag Schrems II und Tracking-Pixel den Aspekt des TIA (Transfer Impact Assessment) ab. Der DMA löst dieses Problem nicht; er fügt eine weitere Einschränkung hinzu.
Was Elido auf der Redirect-Ebene tut (und was nicht)#
Elido ist der Auftragsverarbeiter; der Controller entscheidet über die Consent-Strategie und betreibt das Banner. Die Redirect-Datenebene erledigt das Nötigste:
- Erhält UTM-Parameter und den kunden-eigenen Click-Identifier. Anbieterspezifische Werbe-Identifier (
fbclid,gclid,msclkid,ttclid) werden standardmäßig weitergeleitet, da sie die Attributionsfläche des Controllers bilden; ein Opt-out pro Workspace ist verfügbar. - Löst zum Zeitpunkt des Redirects keine server-seitigen Werbe-Events aus. Das interne Click-Event, das in ClickHouse geschrieben wird, enthält die IP-Adresse gekürzt auf /24 oder /48 sowie nur geparste Gerätefelder gemäß der GDPR-Datenminimierung. Es wird nicht mit Dritten geteilt.
- Unterstützt consent-basiertes server-seitiges Conversion-Forwarding an GA4, Meta CAPI, LinkedIn, TikTok und Reddit, gesteuert durch den von der Landingpage gelieferten Consent-Status. Der Forwarder befindet sich unter
/features/conversion-tracking; die Einrichtung ist im Leitfaden zur Conversion-Tracking-Dokumentation beschrieben. - Erfordert eine
consent-Payload von der Landingpage, wenn das consent-basierte Forwarding aktiviert ist; fehlt die Payload, wird das Event verworfen und nicht stillschweigend mit Standardwerten gefeuert.
Das Analytics-Dashboard unter /features/analytics zeigt die Aufschlüsselung des Consent-Status pro Kampagne — erteilt, abgelehnt, nicht gesetzt —, damit das Marketing-Team sehen kann, wie viel Attribution durch Ablehnungen verloren geht.
Was Elido nicht tut: das Banner implementieren, den Consent vorab entscheiden oder einen erteilten Consent für Nutzer vortäuschen, die ihn nicht tatsächlich gegeben haben. Diese Entscheidungen liegen beim Controller, wo sowohl die GDPR als auch der DMA sie verorten.
Die Beschaffungsfrage#
Für einen Controller, der einen Shortener unter Art. 5(2) DMA prüft, ergeben sich drei Fragen:
Leitet der Shortener Klickdaten zum Zeitpunkt des Redirects an einen Drittanbieter für Werbung oder Analysen weiter, unabhängig vom Consent-Status der Landingpage? Wenn ja, ist dies ein Risiko gemäß Art. 5(2) DMA, das beendet werden sollte.
Unterstützt der Shortener die Weiterleitung des Consent-Status an seine server-seitigen Conversion-Endpoints? Wenn nein, benötigt der Controller einen separaten Server-Side-Tagging-Proxy (GTM-Server-Container, Stape, Snowplow) zwischen der Landingpage und den Gatekeeper-APIs.
Teilt die Analytics-Ebene des Shorteners aggregierte Daten mit Dritten? Einige marketing-orientierte Anbieter veröffentlichen „Branchen-Benchmarks“, die sich als Klickdaten von Kunden herausstellen, deren Sub-Graphen anhand der Traffic-Struktur identifizierbar sind — wie sieht hier die Joint-Controller-Analyse nach Wirtschaftsakademie und Fashion ID aus?
Ein Shortener, der hier ausweicht, vergrößert die DMA-Risikofläche, die der Controller im Falle eines Audits verteidigen muss.
Fazit#
Consent Mode v2 ist keine Marketing-Initiative. Es ist ein Compliance-Mechanismus für Art. 5(2) DMA, der über die Tag-Plattform von Google bereitgestellt wird. Die vier Signale geben ehrlich an, welche Einwilligung eingeholt wurde; Server-Side-Maßnahmen funktionieren, wenn der Consent-Status mit dem Event mitgeliefert wird; der Attributionsverlust in einer Welt ohne Einwilligung ist real, aber geringer als es scheint, sobald eine First-Party-Identifier-Auflösung implementiert ist. Der Shortener liefert einen sauberen Status über den Redirect und bietet ein consent-basiertes Forwarding, das der Controller mit seinem Banner verknüpft.
Die für Q3 2026 erwarteten Leitlinien des EDPB werden die Messlatte höher legen. Wer nur für die aktuelle Messlatte plant, denkt zu kurz; die Planung für das, was Art. 5(2) beabsichtigt — ausdrückliche, granulare und freiwillig erteilte Einwilligung für die dienstübergreifende Datenkombination — ist die Position, die die nächste Durchsetzungswelle überstehen wird.
Weiterführende Lektüre#
- GDPR für URL-Shortener: Was Ihr DPO wirklich sehen will — der Eckpfeiler für das Compliance-Cluster.
- Click-Attribution nach Safari ITP — die parallele Geschichte zum Attributionsverlust auf Browser-Seite.
- Cookielose Attribution erklärt — First-Party-Identifier-Muster, die auch bei abgelehntem Consent funktionieren.
- GA4-Server-Side-Tracking via Redirects — die Struktur des Measurement Protocol, auf der das Consent-Forwarding aufsetzt.
- Schrems II und Tracking-Pixel — was mit den eingewilligten Daten geschieht, nachdem sie den Atlantik überquert haben.
- Produktseite:
/features/analyticsfür die Ansicht der Consent-Status-Aufschlüsselung. - Anleitung: Leitfaden zur Conversion-Tracking-Dokumentation für die Einrichtung des consent-basierten Forwarders.