Einen TC-String lesen: was in den 213 Kopfbits steht

Ein TC-String speichert Transparenz- und Einwilligungssignale in kompakter Form. Die Dekodierung zeigt gespeicherte Werte wie Zweckbits, Anbieterentscheidungen und die verwendete Version der Anbieterliste. Daraus folgt noch kein Nachweis für einen korrekten Banner, eine wirksame Einwilligung oder die tatsächliche Beachtung durch einen Anbieter.

Das Format ist kodiert, nicht verschlüsselt. Zum Lesen ist kein geheimer Schlüssel nötig. Auch ein signiertes Prüfprotokoll stellt der String nicht dar. Eine belastbare Prüfung verbindet deshalb die Signale mit dem tatsächlichen Dialog, der passenden Global Vendor List (GVL) und beobachteten Anfragen.

Der feste Anfang: 213 Bit einschließlich der Zwecke

Jedes Segment verwendet das Base64url-Alphabet; jedes Zeichen bildet sechs Bit ab. Punkte trennen die Segmente. Die ersten sechs Bit enthalten die Formatversion: Der Wert 2 ergibt 000010 und damit das Zeichen C. Ein C am Anfang kennzeichnet dieses Versionsfeld, bestätigt aber nicht die Gültigkeit des restlichen Strings.

Das Kernsegment beginnt mit den folgenden Feldern in genau dieser Reihenfolge. Die Bitpositionen zählen ab null: Position 0 bezeichnet das erste Bit. Der 213-Bit-Anfang enthält die Zweckbits bereits. Anbieterdaten beginnen an Position 213, also beim 214. Bit.

Der feste Anfang endet nach den ersten drei Bit des 36. Base64url-Zeichens. Die übrigen drei Bit gehören bereits zu den Anbieterdaten. 35 Zeichen reichen daher nicht; 36 vollständige Zeichen enthalten schon mehr als den festen Anfang.

Zeitpunkte und Versionen getrennt auswerten

Die Zeitfelder bleiben 36-Bit-Werte in Zehntelsekunden seit der Unix-Epoche. Nach aktueller Spezifikation enthalten Created und LastUpdated jedoch denselben, auf den UTC-Tag begrenzten Änderungszeitstempel. Die Multiplikation mit 100 liefert JavaScript-Millisekunden. Aus der Zahleneinheit folgt keine auf Zehntelsekunden genaue Erfassung der Einwilligung.

Ein altes Änderungsdatum ist Anlass, Erneuerung und Erinnerung zu prüfen. Ein aktuelles Datum belegt umgekehrt keine frische Einwilligung; auch ein Vergleich mit dreizehn Monaten rekonstruiert keine Einwilligungshistorie. Die technische Spezifikation verweist auf Erinnerungen spätestens nach dreizehn Monaten. Der String ersetzt die zugehörigen Nachweise nicht.

Formatversion 2, Framework-Versionen wie TCF 2.3 oder 2.4, Richtlinienversion und GVL-Version sind verschiedene Kennungen. Der Richtlinienwert 4 wurde mit TCF 2.2 eingeführt. Ein Wert ab 4 beweist nicht die Umsetzung sämtlicher aktueller Anforderungen. VendorListVersion bezeichnet die verwendete GVL-Fassung, nicht die tatsächliche Anzeige aller darin enthaltenen Anbieter im Dialog.

Anbieterabschnitte: Länge ist kein Zustimmungsmaß

Ein Anbieterabschnitt beginnt mit einer 16-Bit-Höchstnummer und einem Bit für das Kodierungsverfahren. Beim Bitfeld folgt ein Bit je Anbieternummer bis zu dieser Grenze. Die Bereichskodierung ergänzt zunächst eine 12-Bit-Anzahl. Jeder Eintrag enthält ein Bereichskennzeichen und eine 16-Bit-Start- oder Einzelnummer; nur bei einem Bereich folgen weitere 16 Bit für dessen Ende.

Bei Höchstnummer 800 benötigt ein Bitfeld einschließlich Abschnittskopf 817 Bit. Fünfzig einzelne Nummern benötigen als Bereiche 879 Bit: 17 + 12 + 50 × 17. Ein zusammenhängender Bereich benötigt nur 62 Bit: 17 + 12 + 33. Bei Wahl der kürzeren Darstellung gewinnt im ersten Beispiel das Bitfeld, im zweiten die Bereichskodierung. Eine Zustimmung zu allem garantiert daher nicht allgemein einen kurzen String.

Anbietereinwilligungen und Signale zum berechtigten Interesse stehen in getrennten Abschnitten. Einschränkungen des Publishers und zusätzliche Segmente beeinflussen die Gesamtlänge ebenfalls. Ein langer String belegt weder umfassende Zustimmung noch einen Defekt oder besonders viele ausgewählte Anbieter.

Aktuelle Regeln zusätzlich zum Bitformat

TCF 2.2 entfernte berechtigtes Interesse als zulässige Grundlage für die Zwecke 3–6. Für Zweck 1 war bereits Einwilligung als Grundlage vorgesehen; das länderspezifische Kennzeichen PurposeOneTreatment behandelt eine andere Frage. Besondere Zwecke besitzen einen eigenen Nummernraum und gehören nicht in die gewöhnlichen Zweckbits.

Bei den derzeit definierten Zwecken 1–11 stellen die reservierten Positionen 12–24 keine weiteren Auswahlmöglichkeiten dar. Unerwartet gesetzte Bits erfordern einen Abgleich mit der maßgeblichen Spezifikation und GVL. Ein solcher Befund zeigt eine Unstimmigkeit, nicht die Herkunft der Implementierung. Zwecksignale allein erlauben außerdem nicht jedem Anbieter die Verarbeitung: Anbietersignale, Offenlegung, deklarierte Zwecke und Publisher-Einschränkungen gehören zur Auswertung.

TCF 2.3 machte das Segment DisclosedVendors für ab dem 1. März 2026 erzeugte Strings verpflichtend. Für ältere Strings ohne dieses Segment gilt die Übergangsausnahme; ein fehlendes Segment ist deshalb nicht bei jedem historischen String gleich zu bewerten. Segmenttyp 1 bezeichnet offengelegte Anbieter, der optionale Typ 3 die Zwecke des Publishers. Der frühere Typ 2 für erlaubte Anbieter entfiel mit TCF 2.2.

TCF 2.4 ergänzte anschließend überarbeitete Informationen zu Features. Die offizielle Umsetzungsfrist für Webumgebungen endete am 23. Oktober 2026; für mobile Apps und CTV endet die Frist am 23. Februar 2027. Daraus wird keine sechs Bit breite Formatversion 2.4. Ein Bitdecoder kann die erforderlichen Texte und deren Darstellung im Dialog nicht prüfen.