Die Kurzfassung

TCF v2.3 ist eine Weiterentwicklung von v2.2, keine Neuarchitektur. Das TC String-Format ist kompatibel, bestehende Zwecke und Features bleiben erhalten und die meisten UI-Anforderungen gegenüber Publishern bleiben unverändert. Die wesentlichen Änderungen konzentrieren sich auf vier Bereiche:

• Klarere Regeln dazu, wie CMPs Anbieterinformationen und Speicherfristen darstellen müssen.
• Neue Anforderungen an granulare Kontrollen in der zweiten Ebene, wie sie Aufsichtsbehörden seit der belgischen DPA-Entscheidung von 2022 fordern.
• Verschärfte Policy-Durchsetzung in Bezug auf Dark Patterns, gleichwertige Hervorhebung und vorangekreuzte Optionen.
• Anpassungen am Schema der Global Vendor List (GVL) und am Offenlegungsfluss für Anbieter.

Warum es v2.3 gibt

Jede TCF-Version ist ein Aushandlungsprozess zwischen drei Zielgruppen: Publishern, die weiter monetarisieren müssen, Anbietern, die eine stabile technische Schnittstelle benötigen, und Aufsichtsbehörden, die immer neue ganz konkrete Compliance-Lücken finden. v2.3 ist eine direkte Reaktion auf drei Druckfaktoren:

1. Durchsetzungsmaßnahmen gegen den übermäßigen Einsatz von "berechtigtem Interesse" unter v2.2. Mehrere europäische DPAs vertraten die Auffassung, dass zu viele Anbieter LI für Zwecke beanspruchten, für die tatsächlich nur Einwilligung rechtmäßig war. v2.3 verschärft die Offenlegung der von Anbietern deklarierten Rechtsgrundlagen und rückt sie in der Einwilligungs-UI weiter nach vorne.
2. Anhaltende Beschwerden über Dark Patterns. Die aktualisierten Policies machen die Regel zur gleichwertigen Hervorhebung expliziter und schließen Schlupflöcher rund um vorangekreuzte Schalter in der zweiten Ebene.
3. Operatives Feedback großer CMPs und Publisher. v2.2 führte mehrere Pflichtangaben ein, die sich auf Mobile und CTV nur schwer sauber umsetzen ließen. v2.3 strafft den Pflichtumfang der Offenlegungen und erlaubt, mehr davon in einer gestuften Ansicht unterzubringen.

TC String-Kompatibilität

Der TC String selbst bleibt abwärtskompatibel. Eine v2.3-CMP erzeugt Strings, die v2.2-Anbieter lesen können, und ein v2.3-Anbieter kann während des Übergangszeitraums v2.2-Strings verarbeiten. Der Versionsindikator im Core-Segment des Strings kennzeichnet, mit welcher Policy-Version die CMP behauptet, konform zu sein, während der Verweis auf die GVL-Version unabhängig davon fortgeschrieben wird.

Praktische Bedeutung: Sie müssen nicht alle Anbieter gleichzeitig aktualisieren und Sie müssen am Tag der Einführung von v2.3 nicht bei jedem Nutzer ein neues Einwilligungsereignis erzwingen. Ein gestaffelter Rollout ist ausdrücklich vorgesehen.

Wichtige technische Änderungen

1. Anbieter-Offenlegung und Speicherfristen

v2.3 verlangt von CMPs, die deklarierte Speicherfrist der Daten jedes Anbieters in der gestuften UI anzuzeigen, nicht nur in einer separaten Anbieterliste. Der Speicherwert war schon immer Teil der GVL, aber v2.2 schrieb nicht vor, dass Nutzer ihn zusammen mit den Zwecken sehen müssen. v2.3 schließt diese Lücke, weil Aufsichtsbehörden argumentierten, Nutzer könnten ohne Kenntnis der Dauer der Datenspeicherung keine informierte Entscheidung treffen.

2. Strengere Kontrollen in der zweiten Ebene

In der zweiten Ebene – der Ansicht „Einstellungen verwalten“ – legt v2.3 ausdrücklich fest, dass Schalter für nicht-essenzielle Zwecke und Anbieter standardmäßig auf aus stehen müssen. Vorgekreuzte Kästchen oder vorab aktivierte Slider stellen einen Verstoß gegen die Policies dar, selbst wenn der Nutzer nie ausdrücklich auf „Akzeptieren“ klickt. CMPs, die bislang ein „Soft-Opt-in“-Muster genutzt haben, müssen die zweite Ebene neu rendern.

3. Durchsetzung der gleichwertigen Hervorhebung

Die Regel zur gleichwertigen Hervorhebung existiert seit v2.1, aber v2.3 definiert sie mit weniger Interpretationsspielraum: Die Schaltfläche „Alle ablehnen“ muss auf derselben Ebene, mit demselben visuellen Gewicht, derselben Farbkontrastklasse und demselben Interaktionsabstand wie „Alle akzeptieren“ platziert sein. Das Ablehnen hinter einem Link, einer kleineren Schaltfläche oder einem zweiten Bildschirm zu verstecken, ist nun ein expliziter Compliance-Verstoß und keine Ermessensfrage mehr.

4. Signalisierung des berechtigten Interesses

Anbieter, die unter v2.3 berechtigtes Interesse als Rechtsgrundlage deklarieren, müssen nun auch angeben, für welche Zwecke sie eine Abwägung vorgenommen und für welche sie eine Legitimate Interests Assessment abgeschlossen haben. CMPs sind verpflichtet, diese Angabe in die Benutzeroberfläche zu übernehmen, damit Nutzer mit vollständigen Informationen Widerspruch einlegen können. Praktisch bedeutet dies, dass der „Widerspruchs“-Flow nun den LIA-Status je Anbieter anzeigt und nicht mehr nur einen generischen Schalter.

5. GVL-Schema-Updates

Das Schema der Global Vendor List erhält zusätzliche Felder für die Granularität der Speicherfrist, den LIA-Status und einen maschinenlesbaren Link auf den Abschnitt der Datenschutzerklärung des Anbieters, der sich auf die deklarierten Zwecke bezieht. CMPs, die die GVL cachen, müssen ihren Schema-Parser aktualisieren, um die neuen Felder zu verstehen, bevor sie auf eine v2.3-GVL zeigen.

Policy-Änderungen mit Auswirkungen auf die UX

Das TCF ist sowohl eine technische Spezifikation als auch ein Satz von Policies. Einige der Policy-Änderungen in v2.3 betreffen unmittelbar die Einwilligungs-UI:

• Kein „Ohne Akzeptieren fortfahren“ mehr als Ablehnungsäquivalent, es sei denn, es ist optisch identisch zur Akzeptieren-Schaltfläche und erzeugt denselben TC String wie eine vollständige Ablehnung.
• Sprachparität – der Einwilligungshinweis muss in jeder Sprache verfügbar sein, in der auch die Website selbst verfügbar ist, nicht nur in der Browsersprache des Nutzers. CMPs müssen eine Überschreibung der Locale unterstützen.
• Dauerhafter Zugriff – Nutzer müssen von jeder Seite der Website aus das Präferenzzentrum erreichen können, nicht nur von der Landingpage, und der Zugriffslink muss so bezeichnet sein, dass ein nicht fachkundiger Nutzer ihn als einwilligungsbezogen erkennt.

Was Publisher tun müssen

1. Bestätigen Sie die v2.3-Unterstützung Ihres CMP-Anbieters. Fragen Sie nach dem genauen Datum, an dem deren v2.3-zertifizierter Build verfügbar sein wird, und nach dem Versionsstring, den er meldet.
2. Aktualisieren Sie Ihre Logik zum Caching der GVL. Wenn Sie eine eigene GVL-Spiegelung hosten, aktualisieren Sie den Schema-Parser, bevor die v2.3-GVL ausgerollt wird, sonst schlägt Ihre CMP bei der Validierung neuer Anbieter fehl.
3. Schreiben Sie Ihre UI der zweiten Ebene neu, sodass alle Schalter standardmäßig auf „aus“ stehen, die gleichwertige Hervorhebung visuell sichergestellt ist und die Speicherfristen direkt neben den Zwecken angezeigt werden.
4. Führen Sie Ihr Compliance-Audit erneut durch. Die einfachsten regulatorischen Treffer sind Dark-Pattern-Verstöße, die v2.3 nun ausdrücklich benennt. Beheben Sie diese, bevor Sie in die nächste Prüfung gehen.
5. Planen Sie eine Re-Prompt-Strategie. Zwar ist der TC String abwärtskompatibel, doch die Policies ermutigen Publisher, die Einwilligung erneut einzuholen, wenn sich Umfang oder Offenlegung der Verarbeitung wesentlich ändern. Entscheiden Sie, ob Ihr v2.3-Rollout für Ihr Publikum als „wesentlich“ einzustufen ist.

Was Anbieter tun müssen

1. Führen Sie für jeden Zweck, für den Sie LI deklarieren, eine Legitimate Interests Assessment durch und melden Sie das Ergebnis an die GVL.
2. Aktualisieren Sie Ihren GVL-Eintrag um die v2.3-Schemafelder: Granularität der Speicherfrist, LIA-Deklaration und den Deep-Link zur Datenschutzerklärung.
3. Validieren Sie Ihren TC String-Parser anhand der v2.3-Referenzstrings von IAB Europe.
4. Stimmen Sie sich mit Ihren CMP-Partnern ab und vereinbaren Sie ein gemeinsames Umschalt-Datum, damit die erste Buyer-Request mit einem v2.3-String nicht bei einem reinen v2.2-Anbieter landet.

Häufige Migrationsfallen

• v2.3 als Gelegenheit für ein UI-Redesign betrachten. Es ist verlockend, Marken-Updates mit dem v2.3-Rollout zu bündeln, aber das verkompliziert die Compliance-Tests. Veröffentlichen Sie zunächst ein reines v2.3-Compliance-Release und iterieren Sie danach am Design.
• Die Anforderung zur Anzeige der Speicherfrist übersehen. Teams aktualisieren oft die Anbieterliste, vergessen aber, dass die Speicherfrist nun auch in der gestuften Ansicht je Zweck angezeigt werden muss.
• Davon ausgehen, dass der TC String ausreicht. Ein konformer String, der von einer nicht konformen UI erzeugt wird, ist weiterhin nicht konform. Aufsichtsbeh��rden haben wiederholt Betreiber sanktioniert, deren Strings formal in Ordnung waren, deren Banner aber die Ablehnen-Schaltfläche versteckten.
• CTV und Mobile aus dem Geltungsbereich lassen. v2.3 gilt für jede Oberfläche, auf der TCF-Signale erzeugt werden. Publisher, die ein Web-Update ausrollen und ihre CTV- oder Mobile-Apps ignorieren, schaffen eine hybride, nicht konforme Umgebung.

Fazit

TCF v2.3 ist kein disruptiver Bruch mit v2.2, aber eine spürbare Verschärfung der Regeln, die das europäische programmatische Ökosystem zusammenhalten. Die Richtung ist klar: mehr Transparenz, weniger Dark Patterns, granularere Nutzerkontrollen und weniger Toleranz für Randfälle, die früher durchgerutscht sind. CMPs und Publisher, die v2.3 wie einen schnellen Patch behandeln, werden rasch wieder bei der Aufsichtsbehörde landen. Wer die Migration nutzt, um die UX der zweiten Ebene aufzuräumen, Abkürzungen beim berechtigten Interesse abzuschaffen und einen echten, gleichwertig hervorgehobenen Einwilligungsfluss aufzubauen, geht mit Inventar aus dem Prozess hervor, das in der v2.3-Ära tatsächlich handelbar ist – und mit einer Einwilligungsbasis, die auch das übersteht, was v2.4 als Nächstes mit sich bringt.