Was ist das IAB TCF?

Das IAB TCF ist ein technisches Standardformat, gemeinsam entwickelt von IAB Europe und IAB Tech Lab, damit Websites und Apps einheitlich anzeigen, welche Einwilligung ein Nutzer gegeben hat, und sie an die Werbepartner weitergeben, die an der Auslieferung einer Anzeige beteiligt sind. Es ist kein Gesetz und keine offizielle Zertifizierung einer Aufsichtsbehörde. Es ist eine Branchenvereinbarung der Werbeindustrie darüber, wie diese Information zwischen allen Beteiligten einer Werbeauktion codiert und geteilt wird.

Es lohnt sich, das TCF von einer CMP (Consent-Management-Plattform) zu trennen. Die CMP ist die Software auf der Website, das Banner, das der Nutzer sieht und mit dem er Kategorien der Datenverarbeitung akzeptiert oder ablehnt. Das TCF ist der Standard, der festlegt, wie diese CMP das Einwilligungssignal erzeugen und strukturieren muss, damit es für jeden Werbeanbieter im Ökosystem lesbar ist. Eine Website kann eine CMP installiert haben, ohne das TCF einzuhalten, und tatsächlich bieten viele CMPs am Markt beide Betriebsarten gleichzeitig an.

Die offizielle TCF-Spezifikation existiert nur auf Englisch. IAB Europe veröffentlicht keine übersetzte Fassung auf Spanisch oder Deutsch, jede direkte technische Nachfrage zum Standard führt deshalb letztlich zur englischsprachigen Dokumentation.

Das zentrale Element des TCF ist der TC String (Transparency & Consent String), eine codierte Zeichenfolge, die für einen bestimmten Nutzer festhält, welchen Verarbeitungszwecken und welchen konkreten Anbietern er zugestimmt oder berechtigten Widerspruch eingelegt hat. Diese Zeichenfolge ist nicht auf einen Blick lesbar: Sie folgt einem komprimierten Binärformat, das erst mit speziellen Werkzeugen decodiert wird.

Damit der TC String im gesamten Ökosystem Sinn ergibt, führt das TCF die Global Vendor List (GVL), ein öffentliches Verzeichnis aller registrierten Werbeanbieter mit je einer festen numerischen Kennung. Wenn die CMP den TC String erzeugt, markiert sie die Kennungen der GVL, die den vom Nutzer akzeptierten Anbietern entsprechen.

Der Weg des Strings verläuft in drei Schritten. Erstens erzeugt die CMP ihn im Browser oder in der App, sobald der Nutzer mit dem Einwilligungsbanner interagiert. Zweitens speichert der Publisher, die Website oder App, ihn üblicherweise in einem Cookie oder im Local Storage und stellt ihn über das technische Framework des TCF bereit, damit jedes Skript der Seite ihn lesen kann. Drittens fragt jeder Ad-Tech-Anbieter, der an der programmatischen Auktion teilnimmt, ob SSP, DSP oder Exchange, diesen String ab, bevor er entscheidet, ob er für eine personalisierte Anzeige an diesen konkreten Nutzer bieten darf, und für welche Zwecke.

Findet ein Anbieter seine Kennung nicht unter den akzeptierten im TC String, verlangt die Spezifikation, diesen Nutzer für genau diesen Anbieter so zu behandeln, als hätte er keine Einwilligung gegeben, selbst wenn er andere Anbieter im selben String akzeptiert hat.

Der TC String entscheidet über etwas sehr Konkretes: ob ein Anbieter programmatischer Werbung diesen Nutzer mit personalisierten Anzeigen ansprechen, sein Verhalten messen oder seine Daten mit Dritten teilen darf. Ohne gültiges Signal verlangt die Spezifikation, ihn wie einen Nutzer ohne Einwilligung zu behandeln, was das verfügbare Nachfrage-Inventar für diesen Publisher direkt verringert.

Das ist mit Version 2.3 anspruchsvoller geworden. IAB Europe veröffentlichte das TCF v2.3 am 19. Juni 2025, mit einer Übergangsfrist, die am 28. Februar 2026 endete. Seit dem 1. März 2026 gilt jeder TC String, der ohne das verpflichtende disclosedVendors-Segment erzeugt wurde, als ungültig und wird von konformen Anbietern entsprechend behandelt. Konforme Strings, die vor diesem Datum erzeugt wurden, bleiben gültig, bis der Nutzer seine Auswahl ändert.

Der Unterschied ist wichtig, weil das disclosedVendors-Segment nicht beschreibt, wie der Einwilligungsprozess funktioniert, sondern einen maschinenlesbaren technischen Nachweis liefert, welche konkreten Anbieter die CMP dem Nutzer im Moment der Einwilligungsabfrage tatsächlich gezeigt hat. Früher reichte es, den Prozess zu erklären. Jetzt muss der TC String selbst ihn belegen.

• Prüfen, ob die installierte CMP bereits die Version 2.3 des TCF meldet und bei jedem neuen TC String, den sie ausstellt, das disclosedVendors-Segment erzeugt, ohne Ausnahme nach Gerätetyp.
• Eine Stichprobe von TC Strings, die nach dem 1. März 2026 erzeugt wurden, decodieren und nachsehen, ob das disclosedVendors-Segment vorhanden ist und die tatsächlich im Banner angezeigten Anbieter enthält.
• Die in der CMP hinterlegte Anbieterliste mit der aktuellen Global Vendor List abgleichen, denn IAB Europe aktualisiert sie in gewisser Regelmäßigkeit, und ein entfernter oder umbenannter Anbieter kann das Signal brechen, ohne dass eine sichtbare Warnung erscheint.
• Mit jedem Werbepartner, SSP, DSP oder Exchange, bestätigen, dass dessen Integration den aktuellen TC String liest und nicht eine ältere Version des Frameworks, die das neue Segment gar nicht kennt.
• Vom CMP-Anbieter eine schriftliche Bestätigung einholen, dass seine konkrete Implementierung die Version 2.3 des TCF erfüllt, und diese Bestätigung als Nachweis der Einhaltung aufbewahren.
• Die Einhaltung regelmäßig überprüfen, denn IAB Europe veröffentlicht weiterhin Aktualisierungen der Spezifikation, und eine heute konforme CMP kann es mit der nächsten Revision nicht mehr sein.

• Annehmen, dass am 1. März 2026 die Einwilligung aller Nutzer neu eingeholt werden muss. Gültige TC Strings, die vor diesem Datum erzeugt wurden, bleiben gültig, bis der Nutzer seine Auswahl ändert.
• Die CMP mit dem TCF verwechseln und annehmen, dass die Installation irgendeines Einwilligungsbanners den Standard bereits erfüllt, ohne zu prüfen, welche Framework-Version tatsächlich implementiert ist.
• Nicht prüfen, ob die Werbepartner in der Kette den TC String tatsächlich lesen und beachten, und den Nutzer weiter so behandeln, als hätte er keine Einwilligung gegeben, obwohl er sie erteilt hat.
• Die Erklärung des Einwilligungsprozesses so behandeln, als wäre sie gleichwertig mit dem technischen Nachweis, den das disclosedVendors-Segment verlangt, obwohl es sich um zwei verschiedene Dinge handelt.
• Mit einer veralteten Global Vendor List arbeiten und aktive Anbieter im TC String unangemeldet lassen, was das Signal für genau diese Anbieter ungültig macht.