Das Segment, das bisher fehlen durfte
Inhalt
Ein TC-String besteht aus Segmenten, die durch Punkte getrennt sind. Das erste ist das Kernsegment und trägt die Zwecke, die Rechtsgrundlagen und die Anbieter, für die eine Einwilligung vorliegt. Das dritte ist freiwillig. Das zweite – die offengelegten Anbieter – durfte bis TCF 2.2 fehlen und muss seit 2.3 vorhanden sein.
Der Unterschied klingt nach Buchhaltung und ist es auch. Genau deshalb ist er wirksam: Ohne dieses Segment lässt sich nicht nachweisen, dass ein Anbieter, der eine Einwilligung erhalten hat, dem Menschen überhaupt gezeigt wurde.

Was in dem Segment steht
Jedes Segment nach dem Kernsegment beginnt mit drei Bit Segmenttyp. Der Wert 1 bedeutet offengelegte Anbieter, der Wert 3 das Publisher-Segment, der Wert 0 steht für das Kernsegment. Danach folgen sechzehn Bit für die höchste enthaltene Anbieterkennung und ein einziges Bit, das über die Kodierung der eigentlichen Menge entscheidet.
Aufbau des Segments "offengelegte Anbieter"
SegmentType 3 Bit Wert 1
MaxVendorId 16 Bit höchste enthaltene Anbieterkennung
IsRangeEncoding 1 Bit 0 = Bitfeld, 1 = Bereiche
bei 0 Bitfeld MaxVendorId Bit, eines je Anbieter,
1 = gezeigt, 0 = nicht gezeigt
bei 1 NumEntries 12 Bit
je Eintrag IsARange 1 Bit
StartOrOnlyVendorId 16 Bit
EndVendorId 16 Bit, nur bei IsARange = 1
Segmenttypen 0 = Kern 1 = offengelegte Anbieter 3 = Publisher TC
Beide Formen beschreiben dieselbe Menge. Die Spezifikation verlangt lediglich, diejenige zu wählen, die für die gegebene Menge die kürzere Ausgabe erzeugt. Eine zusammenhängende Auswahl aus wenigen Blöcken fährt mit Bereichen deutlich besser; eine über die ganze Liste verstreute Auswahl kippt die Rechnung zugunsten des Bitfelds, weil jeder Einzelwert dort siebzehn Bit kostet und im Bitfeld nur eines.
Wogegen das Segment gerichtet ist
Die Lücke, die es schließt, hat einen Namen: Anbieter, die im Signal auftauchen, ohne je in der Oberfläche gestanden zu haben. Ein Einwilligungsbanner konnte eine Handvoll Namen zeigen, während der erzeugte String für eine erheblich größere Zahl von Anbietern eine Einwilligung auswies. Für den Empfänger des Strings war beides ununterscheidbar, denn die Information darüber, was gezeigt wurde, war schlicht nicht enthalten.
Genau das ist der Vorwurf, der in europäischen Verfahren gegen das Rahmenwerk erhoben wurde, und die Antwort darauf ist ungewöhnlich unmittelbar. Statt einer Verhaltensregel steht jetzt ein Pflichtfeld im Datenformat. Wer nicht offenlegt, kann es nicht mehr behaupten, weil das Feld leer bliebe und die Prüfung das sieht.
Was seit Ende Februar geschieht
TCF 2.3 erschien am 19. Juni 2025, der Übergang lief bis Ende Februar 2026. Google verlangt die Fassung 2.3 für alle neu erzeugten TC-Strings seit dem 28. Februar 2026, die verbindliche Frist des Rahmenwerks selbst lag auf dem 1. März. Anfang März wurde die Prüfung scharf geschaltet; im Fehlerbericht erscheint seither nach übereinstimmenden Berichten ein eigener Code für Anfragen, in denen das Segment fehlt, beschädigt ist oder Google darin nicht enthalten ist.
Die Folge ist nicht ein Warnhinweis in einer Oberfläche, sondern eine Entscheidung an der Anzeigenauslieferung: Die Anfrage bekommt eingeschränkte Werbung oder wird verworfen. Das trifft den Umsatz einer Seite unmittelbar und stillschweigend, denn eine verworfene Anfrage hinterlässt keine Meldung im Einwilligungswerkzeug.
Wo der Fehler tatsächlich sitzt
Bemerkenswert an dieser Umstellung ist, wie wenig sie mit dem Auftritt zu tun hat, auf dem sie sich auswirkt. Geschrieben wird der String von der Einwilligungslösung, und ob die Fassung 2.3 erzeugt wird, hängt an deren Version und Einrichtung. Ein Auftritt kann sein Banner unverändert lassen, jede Frist einhalten, jede Einstellung richtig setzen – und trotzdem ungültige Strings ausliefern, weil die eingebundene Lösung noch 2.2 schreibt.
Umgekehrt gilt: Eine aktuelle Lösung erzeugt das Segment von allein. Der Aufwand liegt in der Feststellung, welcher Fall vorliegt, und die ist an einem einzigen String abzulesen.
Wie sich das an einem String ablesen lässt
Der schnellste Weg führt über die Punkte. Ein String ohne Punkt besteht nur aus dem Kernsegment und kann die Offenlegung folglich nicht enthalten. Ein String mit mindestens einem Punkt hat weitere Segmente, und die drei ersten Bit jedes davon nennen seinen Typ. Steht dort nirgends der Wert 1, fehlt die Offenlegung ebenfalls – dann ist das vorhandene Zusatzsegment das Publisher-Segment.
Wo eine Dekodierung zur Hand ist, ist die Sache in einer Minute erledigt: den String aus dem Banner oder aus dem Netzwerkfenster nehmen, zerlegen, Segmenttypen ablesen. Wo keine zur Hand ist, genügt für den ersten Verdacht schon das Zählen der Punkte. Bleibt es bei null, ist der Befund eindeutig, und die Frage richtet sich nicht an den Auftritt, sondern an den Anbieter der Einwilligungslösung.