DSGVO, TCF und Consent Strings: Was eine DSP in Europa beachten muss

Jede programmatisch eingekaufte Anzeige in Europa beginnt mit einer Frage, die die meisten Einkäufer nie zu Gesicht bekommen: Hat diese Person zugestimmt, dass ihre Daten für Werbung genutzt werden, und von wem? Die Antwort reist im Bid Request mit, als kurzer codierter Text, der sogenannte Consent String. Kann eine DSP ihn nicht auslesen, rät sie nur.

Raten ist teuer. Eine DSP, die ohne gültige Rechtsgrundlage auf personenbezogene Daten bietet, setzt sich selbst, ihre Kunden und ihre Supply-Partner regulatorischen Risiken nach der DSGVO aus. Eine DSP, die in die andere Richtung übertreibt und in Europa einfach nicht mehr bietet, verzichtet auf einige der wertvollsten Inventare der Welt. Die richtige Antwort liegt dazwischen, und sie ist vor allem eine technische Aufgabe.

Dieser Leitfaden erklärt, wie die DSGVO auf den programmatischen Einkauf anwendbar ist, was das IAB Europe Transparency and Consent Framework (TCF) ist, was in einem TCF Consent String steckt, wie dieser String in einem OpenRTB Bid Request zur DSP gelangt und welche Prüfungen eine DSP vor jedem Gebot durchführen muss. Es handelt sich um praxisorientierte Hinweise, nicht um eine Rechtsberatung.

Warum die DSGVO für programmatische Einkäufer relevant ist

Die Datenschutz-Grundverordnung trat am 25. Mai 2018 in Kraft. Sie gilt immer dann, wenn ein Unternehmen personenbezogene Daten von Personen in der Europäischen Union verarbeitet, und im programmatischen Umfeld gilt fast alles als personenbezogene Daten: Cookie-IDs, mobile Werbe-IDs, IP-Adressen und genaue Standortdaten sind allesamt Kennungen, mit denen sich eine Person oder ein Gerät identifizieren lässt.

Daneben steht ein zweites Gesetz. Die ePrivacy-Richtlinie regelt das Speichern und Auslesen von Informationen auf dem Endgerät eines Nutzers, und genau das geschieht bei einem Cookie oder dem Abruf einer Geräte-ID. In der Praxis bedeutet das: Eine DSP benötigt in der Regel eine Einwilligung, bevor sie ihr eigenes Cookie im Browser eines europäischen Nutzers auslesen oder setzen darf, noch bevor sie irgendetwas anderes mit den Daten macht.

Für Einkäufer ergeben sich daraus bei jeder europäischen Impression drei praktische Fragen:

• Ist die DSGVO auf diesen Request überhaupt anwendbar?
• Hat der Nutzer den konkreten Verwendungszwecken zugestimmt, die die DSP verfolgt, etwa der Profilbildung oder der Erfolgsmessung?
• Hat der Nutzer zugestimmt, dass genau dieses Unternehmen, also die DSP selbst, seine Daten verarbeitet?

Was ist das IAB Europe Transparency and Consent Framework?

Das Transparency and Consent Framework ist ein freiwilliger Standard, der von IAB Europe betrieben wird. Es bietet Publishern, Technologieanbietern und Consent-Tools eine gemeinsame Möglichkeit zu beschreiben, wofür Daten genutzt werden, wer sie nutzt und was der Nutzer dazu entschieden hat. IAB Europe unterscheidet drei Gruppen von Teilnehmern:

• Publisher: die Betreiber der Websites und Apps, auf denen Daten erhoben werden.
• Vendors: Drittanbieter wie Ad-Server, Messdienstleister, Agenturen, SSPs und DSPs.
• Consent Management Platforms (CMPs): die Tools, die das Consent-Banner anzeigen, die Entscheidungen des Nutzers erfassen und daraus einen Consent String erzeugen.

Vendors registrieren sich auf der Global Vendor List (GVL), einer öffentlichen Liste, die von IAB Europe gepflegt wird. Jeder registrierte Vendor erhält eine numerische ID und gibt an, für welche Zwecke und auf welcher Rechtsgrundlage er Daten verarbeitet. Mit Stand November 2026 umfasst die offizielle Liste mehr als 1.200 registrierte Vendors. Trifft ein Nutzer eine Auswahl in einem Consent-Banner, speichert die CMP diese bezogen auf die jeweiligen Vendor-IDs.

TCF v2.2 wurde am 16. Mai 2023 eingeführt. Im April 2025 veröffentlichte IAB Europe TCF v2.3, das den Disclosed-Vendors-Abschnitt des Consent Strings verpflichtend macht, um eine Unklarheit beim berechtigten Interesse zu beseitigen. Die Teilnehmer hatten bis zum 28. Februar 2026 Zeit, v2.3 umzusetzen. Jede DSP, die heute europäisches Inventar einkauft, sollte daher mit v2.3-Strings rechnen.

Die TCF-Zwecke, die eine DSP kennen sollte

Das TCF stellt dem Nutzer nicht eine einzige Ja-Nein-Frage. Es unterteilt die Datennutzung in Standardzwecke (Purposes), jeweils mit fester Nummer und Bezeichnung. Eine DSP gibt an, welche davon sie benötigt, und der Consent String hält die Antwort des Nutzers für jeden einzelnen fest. Dies sind die elf Zwecke der offiziellen Global Vendor List:

Darüber hinaus definiert das TCF besondere Zwecke (Special Purposes), die keine Einwilligung erfordern, etwa die Gewährleistung der Sicherheit und Betrugsprävention sowie die Auslieferung und Darstellung von Werbung. Außerdem gibt es besondere Merkmale (Special Features), für die ein separates Opt-in nötig ist. Das wichtigste davon ist die Nutzung genauer Standortdaten.

Jeder Zweck stützt sich auf eine Rechtsgrundlage: entweder Einwilligung oder berechtigtes Interesse. Seit TCF v2.2 können die Zwecke 3 bis 6, also die Profiling-Zwecke, nur noch auf Einwilligung gestützt werden. Für eine DSP, die Audience Targeting oder Retargeting betreibt, ist das die wichtigste Regel überhaupt: keine Einwilligung für die Zwecke 3 und 4, kein personalisiertes Gebot.

Was steckt in einem TCF Consent String?

Der TCF Consent String, auch TC String genannt, ist ein kompakter codierter Text, den die CMP erzeugt, nachdem der Nutzer eine Auswahl getroffen hat. Decodiert enthält der Kernbereich des Strings:

• Metadaten: die TCF-Version, den Zeitpunkt der Erstellung und der letzten Aktualisierung, die ID der CMP, die Sprache des Consent-Dialogs und die verwendete Version der Global Vendor List.
• Einwilligungen für Zwecke: ein Ja oder Nein für jeden Zweck, zu dem der Nutzer befragt wurde.
• Berechtigte Interessen für Zwecke: ob dem Nutzer für jeden infrage kommenden Zweck eine Verarbeitung auf Basis berechtigten Interesses angezeigt wurde und er dieser nicht widersprochen hat.
• Opt-ins für besondere Merkmale: zum Beispiel, ob genaue Standortdaten genutzt werden dürfen.
• Vendor-Einwilligungen und berechtigte Interessen der Vendors: ein Ja oder Nein für jede Vendor-ID auf der Liste.
• Publisher Restrictions: Regeln, die der Publisher für bestimmte Vendors festgelegt hat, etwa die Pflicht zur Einwilligung, wo sich ein Vendor sonst auf berechtigtes Interesse stützen würde, oder die vollständige Sperrung eines Zwecks.

Unter TCF v2.3 enthält der String außerdem ein Disclosed-Vendors-Segment, das die Vendors auflistet, die dem Nutzer im Consent-Hinweis tatsächlich angezeigt wurden. So kann ein Vendor unterscheiden zwischen „Der Nutzer hat mir widersprochen“ und „Der Nutzer wurde nie über mich informiert“.

Der entscheidende Punkt für Einkäufer: Ein Consent String ist zweidimensional. Eine DSP braucht sowohl die Freigabe des Zwecks als auch die Freigabe ihrer eigenen Vendor-ID. Ein Nutzer kann personalisierter Werbung grundsätzlich zustimmen, aber eine bestimmte DSP ablehnen, und der String hält beide Antworten fest.

Wie der Consent String zur DSP gelangt

Der Consent String durchläuft die Lieferkette gemeinsam mit dem Ad Request. Der übliche Weg sieht so aus:

1. Der Nutzer besucht eine Website oder öffnet eine App, und die CMP zeigt einen Consent-Hinweis an.
2. Der Nutzer trifft eine Auswahl, und die CMP speichert sie als TC String, meist in einem First-Party-Cookie oder im App-Speicher.
3. Wenn ein Werbeplatz geladen wird, liest der Ad Stack des Publishers den String aus und übergibt ihn an die SSP.
4. Die SSP fügt ihn in den OpenRTB Bid Request ein, den sie an jede angebundene DSP sendet.
5. Die DSP decodiert den String, prüft ihre eigenen Berechtigungen und entscheidet, wie oder ob sie bietet.

Im OpenRTB Bid Request transportieren zwei Felder das Signal. OpenRTB 2.6 verfügt über ein natives Feld regs.gdpr, das auf 1 gesetzt wird, wenn die DSGVO anwendbar ist, und auf 0, wenn nicht, sowie über ein natives Feld user.consent, das den TC String selbst enthält. Ältere OpenRTB-2.5-Integrationen übermitteln dieselben Werte in Extensions, als regs.ext.gdpr und user.ext.consent. Eine DSP, die mit vielen Supply-Partnern verbunden ist, sollte daher beide Stellen auslesen. Unser Leitfaden zum Aufbau eines Bid Requests zeigt, wo sich diese Objekte im vollständigen Request befinden.

Manche Partner senden zusätzlich einen Global Privacy Platform (GPP) String in regs.gpp und regs.gpp_sid. GPP ist ein Container des IAB Tech Lab, der den TCF-String neben weiteren regionalen Signalen enthalten kann. Eine DSP sollte daher den TCF-Abschnitt extrahieren und dieselbe Logik anwenden.

Der String endet nicht bei der DSP. Ad Tags und Tracking-Pixel können ihn über Standard-Makros erhalten, etwa ${GDPR} für das Anwendbarkeits-Flag und ${GDPR_CONSENT_XXX} für den String, wobei XXX die Vendor-ID des aufgerufenen Unternehmens ist.

Die Prüfungen, die eine DSP vor jedem Gebot durchführen muss

All das geschieht innerhalb des Bidding-Zeitfensters, das in der Regel zwischen einigen Dutzend und einigen Hundert Millisekunden liegt, wie in unserem Leitfaden zur Funktionsweise von Real-Time Bidding beschrieben. Die Consent-Logik muss schnell, vorhersehbar und für jeden Request identisch sein. Eine solide DSP führt diese Prüfungen in folgender Reihenfolge durch:

1. Ist die DSGVO anwendbar? Lesen Sie das gdpr-Flag aus. Steht es auf 1, gelten die Einwilligungsregeln. Fehlt es bei Traffic aus einem EU-Land, behandeln Sie den Request so, als sei die DSGVO anwendbar.
2. Ist der String vorhanden und gültig? Ein fehlender, leerer oder fehlerhafter String bedeutet: keine Einwilligung. Verwenden Sie keine personenbezogenen Daten.
3. Ist die Vendor-ID der DSP freigegeben? Prüfen Sie die Abschnitte zu Vendor-Einwilligungen und berechtigten Interessen der Vendors für Ihre eigene ID.
4. Sind die benötigten Zwecke freigegeben? Prüfen Sie Zweck 1, bevor Sie das Cookie oder die Geräte-ID des Nutzers auslesen, die Zwecke 3 und 4, bevor Sie Zielgruppensegmente nutzen, und Zweck 7 vor jeder Messung.
5. Ändern Publisher Restrictions etwas? Wenden Sie alle Einschränkungen, die der Publisher für Ihre Vendor-ID festgelegt hat, an, bevor Sie auf Basis der Vendor- und Zweck-Antworten handeln.
6. Wird ein besonderes Merkmal benötigt? Nutzen Sie genaue Standortdaten nur, wenn das entsprechende Opt-in für dieses besondere Merkmal gesetzt ist.

Das Ergebnis sollte nicht einfach „Gebot“ oder „kein Gebot“ lauten. Eine gut gebaute DSP wählt pro Request einen dieser Modi:

Es lohnt sich, den kontextuellen Modus sorgfältig umzusetzen. Viele europäische Nutzer lehnen personalisierte Werbung ab, und Einkäufer, die dennoch auf Kontext und Format bieten können, erreichen dieses Inventar weiterhin. Unser Artikel über Cookieless Advertising beschreibt die Targeting-Optionen, die auch ohne Daten auf Nutzerebene funktionieren.

Typische Consent-Fehler in DSPs

Die meisten Consent-Probleme entstehen durch kleine technische Abkürzungen, nicht durch rechtliche Missverständnisse. Die häufigsten:

• Zwecke prüfen, aber nicht den Vendor. Der Nutzer hat personalisierter Werbung zugestimmt, aber nicht Ihrem Unternehmen. Die Nutzung der Daten ist trotzdem nicht erlaubt.
• Nutzer-IDs ohne Zweck 1 synchronisieren. Cookie Syncs und ID-Abfragen gelten als Zugriff auf das Endgerät. Sie erfordern vorab Zweck 1 und die Vendor-Einwilligung.
• Einen fehlenden String als Einwilligung werten. Ist die DSGVO anwendbar und kommt kein String an, lautet die sichere Voreinstellung: keine personenbezogenen Daten.
• Nur eine Stelle im OpenRTB-Request auslesen. Manche Partner senden regs.gdpr, manche regs.ext.gdpr, manche GPP. Lesen Sie alle aus.
• Eine veraltete Vendor List verwenden. Aktualisieren Sie Ihre Kopie der Global Vendor List in festen Abständen.
• Den String nicht weitergeben. Erhalten Creatives und Tracker den String nicht über Makros, können sie keine eigene Entscheidung treffen, und das Risiko trägt der Einkäufer.
• Die Entscheidung nicht protokollieren. Fragt eine Aufsichtsbehörde oder ein Partner, warum die Daten eines Nutzers verwendet wurden, benötigen Sie den Consent-Status, der zum Zeitpunkt der Impression galt.

Dieselbe Disziplin gilt für Daten, die Sie in die Plattform einbringen. Wenn Sie eine DMP mit Ihrer DSP verbinden, sollten Zielgruppensegmente nur bei Requests aktiviert werden, bei denen der Consent String Profiling für Ihre Vendor-ID erlaubt.

Wie Aufsichtsbehörden und Gerichte die Lage bewerten

Das TCF ist ein Standard der Selbstregulierung, kein Gesetz, und Aufsichtsbehörden haben es genau unter die Lupe genommen. Im März 2024 entschied der Gerichtshof der Europäischen Union in einem Verfahren mit Beteiligung von IAB Europe, dass ein TC String personenbezogene Daten darstellen kann, wenn er mit einer Kennung wie einer IP-Adresse verknüpft werden kann. Der String selbst verdient daher dieselbe Sorgfalt wie andere Nutzerdaten.

Für DSP-Betreiber ist die praktische Lehre einfach: Das TCF bietet Ihnen eine gemeinsame Sprache, keinen rechtlichen Schutzschild. Klären Sie Ihre Rolle in jedem Datenfluss mit qualifizierter Rechtsberatung, dokumentieren Sie Ihre Consent-Logik und stellen Sie sicher, dass sich die Plattform wie dokumentiert verhält.

Was sich ändert, wenn Ihnen die DSP gehört

Wenn Sie über die Plattform eines anderen Anbieters einkaufen, bestimmt dessen Consent-Logik, wie sich Ihre Kampagnen in Europa verhalten, und oft können Sie nicht nachvollziehen, warum die europäische Reichweite niedriger ausfällt als erwartet.

Gehört Ihnen die Plattform, wird Consent zu etwas, das Sie konfigurieren und prüfen können:

• Sie entscheiden, wie streng die Voreinstellung bei fehlender Einwilligung ist und ob bei Requests ohne Profiling-Einwilligung kontextuell geboten wird.
• Sie können die europäische Reichweite nach Consent-Status auswerten, sodass Ihre Kunden verstehen, warum eine Audience-Kampagne in Frankreich anders skaliert als in Brasilien.
• Sie legen fest, wie lange Consent-Nachweise und Logs aufbewahrt werden und wer darauf zugreifen darf.
• Sie wählen aus, welche Supply-Partner Sie anbinden, je nachdem, wie sauber diese gdpr-Flags und Consent Strings übermitteln.

Die DSP von AdTech Europe umfasst ein Modul für Consent Management und TCF, das sich in das IAB Transparency and Consent Framework integriert und Consent-Signale über alle DSGVO-Regionen hinweg verwaltet, sodass Targeting und Messung sowohl den Berechtigungen der Werbetreibenden als auch denen der Publisher folgen.

Bereit für Consent-konformen Einkauf auf Ihrer eigenen DSP?

AdTech Europe liefert Demand-Side-Platform-Technologie an Agenturen, Ad Networks, Media-Buying-Teams und Adtech-Unternehmer, die ihren Einkaufs-Stack besitzen möchten, statt ihn zu mieten. Die Plattform läuft unter Ihrer eigenen Marke und Domain, liest Consent-Signale aus angebundenem Supply aus und lässt die Gebotsregeln in Ihren Händen.

Mit Stand November 2026 können Sie die DSP für $500 pro Monat (bei monatlichen Tarifen fällt eine einmalige Einrichtungsgebühr in Höhe einer Monatsgebühr an) oder für $5,000 pro Jahr mieten, sie für $25,000 einmalig oder in 12 Raten lizenzieren oder den vollständigen Quellcode für $50,000 erwerben. Aktuelle Preise in allen unterstützten Währungen finden Sie auf der Preisseite, und die Seite zur White Label DSP stellt die Variante unter Ihrer eigenen Marke vor. Um ein europäisches Setup rund um Ihre Kunden und Ihren Supply zu planen, vereinbaren Sie ein Strategiegespräch zu Programmatic mit unserem Team.

FAQs

Was ist ein TCF Consent String?

Ein TCF Consent String oder TC String ist ein codierter Text, den eine Consent Management Platform erzeugt, nachdem ein Nutzer eine Datenschutzentscheidung getroffen hat. Er hält fest, welche Zwecke und welche Vendors der Nutzer erlaubt hat, und wird mit Ad Requests übertragen, damit jedes Unternehmen in der Kette ihn prüfen kann.

Wo befindet sich der Consent String in einem OpenRTB Bid Request?

In OpenRTB 2.6 steht er im Feld user.consent, wobei das Feld regs.gdpr auf 1 gesetzt ist, wenn die DSGVO anwendbar ist. Ältere OpenRTB-2.5-Integrationen verwenden user.ext.consent und regs.ext.gdpr. Manche Partner senden ihn zusätzlich innerhalb eines GPP-Strings in regs.gpp.

Was sollte eine DSP tun, wenn kein Consent String vorliegt?

Ist die DSGVO anwendbar und kommt kein gültiger String an, sollte die DSP keine personenbezogenen Daten nutzen. Das bedeutet: keine Nutzer-IDs, keine Zielgruppensegmente und keine Cookie Syncs. Je nach Rechtsberatung kann sie den Request überspringen oder ausschließlich auf nicht personenbezogene Signale bieten.

Welche TCF-Zwecke benötigt eine DSP für Retargeting?

Retargeting nutzt Profile und benötigt daher eine Einwilligung für Zweck 3, Profile für personalisierte Werbung erstellen, und Zweck 4, Profile zur Auswahl personalisierter Werbung verwenden. Außerdem ist Zweck 1 erforderlich, um das Cookie oder die Geräte-ID des Nutzers auszulesen, sowie eine Einwilligung für die eigene Vendor-ID der DSP.

Was ist die aktuelle Version des TCF?

Die aktuelle Version ist TCF v2.3, die IAB Europe im April 2025 veröffentlicht hat. Sie macht den Disclosed-Vendors-Abschnitt des Consent Strings verpflichtend. Die Teilnehmer hatten bis zum 28. Februar 2026 Zeit, sie umzusetzen.

Ist das TCF gesetzlich vorgeschrieben?

Nein. Das TCF ist ein freiwilliger Branchenstandard, der von IAB Europe betrieben wird. Die DSGVO und die ePrivacy-Richtlinie sind die Gesetze. Das TCF ist ein gemeinsames Verfahren, mit dem Unternehmen Einwilligungen einholen, weitergeben und respektieren, um diese Gesetze in Auktionsgeschwindigkeit einzuhalten.

Kann eine DSP auch ohne Einwilligung in personalisierte Werbung bieten?

Oft ja. Ist die Vendor-ID der DSP freigegeben, die Profiling-Zwecke aber abgelehnt, kann sie mit begrenzten Daten wie Website, App, Anzeigenformat und ungefährem Standort bieten. Dieses kontextuelle Bidding erhält die europäische Reichweite und respektiert zugleich die Entscheidung des Nutzers.