{"id":10547,"date":"2026-09-01T12:30:00","date_gmt":"2026-09-01T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10547"},"modified":"2026-08-31T15:19:05","modified_gmt":"2026-08-31T13:19:05","slug":"das-segment-das-bisher-fehlen-durfte","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/data-privacy-de\/das-segment-das-bisher-fehlen-durfte\/","title":{"rendered":"Das Segment, das bisher fehlen durfte"},"content":{"rendered":"

Ein TC-String besteht aus Segmenten, die durch Punkte getrennt sind. Das erste ist das Kernsegment und tr\u00e4gt die Zwecke, die Rechtsgrundlagen und die Anbieter, f\u00fcr 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.<\/p>\n

Der Unterschied klingt nach Buchhaltung und ist es auch. Genau deshalb ist er wirksam: Ohne dieses Segment l\u00e4sst sich nicht nachweisen, dass ein Anbieter, der eine Einwilligung erhalten hat, dem Menschen \u00fcberhaupt gezeigt wurde.<\/p>\n

\n\"Oben
Dieselbe Menge Anbieter, zwei Kodierungen. Welche in den String kommt, entscheidet allein, welche k\u00fcrzer ausf\u00e4llt.<\/figcaption><\/figure>\n

Was in dem Segment steht<\/h2>\n

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\u00fcr das Kernsegment. Danach folgen sechzehn Bit f\u00fcr die h\u00f6chste enthaltene Anbieterkennung und ein einziges Bit, das \u00fcber die Kodierung der eigentlichen Menge entscheidet.<\/p>\n

Aufbau des Segments \"offengelegte Anbieter\"\n\n  SegmentType        3 Bit    Wert 1\n  MaxVendorId       16 Bit    höchste enthaltene Anbieterkennung\n  IsRangeEncoding    1 Bit    0 = Bitfeld, 1 = Bereiche\n\n  bei 0   Bitfeld      MaxVendorId Bit, eines je Anbieter,\n                       1 = gezeigt, 0 = nicht gezeigt\n\n  bei 1   NumEntries  12 Bit\n          je Eintrag   IsARange              1 Bit\n                       StartOrOnlyVendorId  16 Bit\n                       EndVendorId          16 Bit, nur bei IsARange = 1\n\n  Segmenttypen   0 = Kern   1 = offengelegte Anbieter   3 = Publisher TC<\/code><\/pre>\n
Beide Formen beschreiben dieselbe Menge. Die Spezifikation verlangt lediglich, diejenige zu w\u00e4hlen, die f\u00fcr die gegebene Menge die k\u00fcrzere Ausgabe erzeugt. Eine zusammenh\u00e4ngende Auswahl aus wenigen Bl\u00f6cken f\u00e4hrt mit Bereichen deutlich besser; eine \u00fcber die ganze Liste verstreute Auswahl kippt die Rechnung zugunsten des Bitfelds, weil jeder Einzelwert dort siebzehn Bit kostet und im Bitfeld nur eines.<\/p>\n
Wogegen das Segment gerichtet ist<\/h2>\n
Die L\u00fccke, die es schlie\u00dft, hat einen Namen: Anbieter, die im Signal auftauchen, ohne je in der Oberfl\u00e4che gestanden zu haben. Ein Einwilligungsbanner konnte eine Handvoll Namen zeigen, w\u00e4hrend der erzeugte String f\u00fcr eine erheblich gr\u00f6\u00dfere Zahl von Anbietern eine Einwilligung auswies. F\u00fcr den Empf\u00e4nger des Strings war beides ununterscheidbar, denn die Information dar\u00fcber, was gezeigt wurde, war schlicht nicht enthalten.<\/p>\n
Genau das ist der Vorwurf, der in europ\u00e4ischen Verfahren gegen das Rahmenwerk erhoben wurde, und die Antwort darauf ist ungew\u00f6hnlich 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\u00fcfung das sieht.<\/p>\n
Was seit Ende Februar geschieht<\/h2>\n
TCF 2.3 erschien am 19. Juni 2025, der \u00dcbergang lief bis Ende Februar 2026. Google verlangt die Fassung 2.3 f\u00fcr alle neu erzeugten TC-Strings seit dem 28. Februar 2026, die verbindliche Frist des Rahmenwerks selbst lag auf dem 1. M\u00e4rz. Anfang M\u00e4rz wurde die Pr\u00fcfung scharf geschaltet; im Fehlerbericht erscheint seither nach \u00fcbereinstimmenden Berichten ein eigener Code f\u00fcr Anfragen, in denen das Segment fehlt, besch\u00e4digt ist oder Google darin nicht enthalten ist.<\/p>\n
Die Folge ist nicht ein Warnhinweis in einer Oberfl\u00e4che, sondern eine Entscheidung an der Anzeigenauslieferung: Die Anfrage bekommt eingeschr\u00e4nkte Werbung oder wird verworfen. Das trifft den Umsatz einer Seite unmittelbar und stillschweigend, denn eine verworfene Anfrage hinterl\u00e4sst keine Meldung im Einwilligungswerkzeug.<\/p>\n
Wo der Fehler tats\u00e4chlich sitzt<\/h2>\n
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\u00f6sung, und ob die Fassung 2.3 erzeugt wird, h\u00e4ngt an deren Version und Einrichtung. Ein Auftritt kann sein Banner unver\u00e4ndert lassen, jede Frist einhalten, jede Einstellung richtig setzen – und trotzdem ung\u00fcltige Strings ausliefern, weil die eingebundene L\u00f6sung noch 2.2 schreibt.<\/p>\n
Umgekehrt gilt: Eine aktuelle L\u00f6sung erzeugt das Segment von allein. Der Aufwand liegt in der Feststellung, welcher Fall vorliegt, und die ist an einem einzigen String abzulesen.<\/p>\n
Wie sich das an einem String ablesen l\u00e4sst<\/h2>\n
Der schnellste Weg f\u00fchrt \u00fcber 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.<\/p>\n
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\u00fcgt f\u00fcr den ersten Verdacht schon das Z\u00e4hlen 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\u00f6sung.<\/p>\n
\n
Quellen<\/h2>\n