LW IT Solutions
« Blog Overview /Data Privacy / Das Segment, das bisher fehlen durfte
This post in other languages:

Das Segment, das bisher fehlen durfte

Das Segment, das bisher fehlen durfte
Inhalt
  1. Was in dem Segment steht
  2. Wogegen das Segment gerichtet ist
  3. Was seit Ende Februar geschieht
  4. Wo der Fehler tatsächlich sitzt
  5. Wie sich das an einem String ablesen lässt
  6. Quellen

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.

Oben ein punktgetrennter TC-String aus drei Stücken, das mittlere hervorgehoben; darunter links ein dichtes Zellenfeld mit 1200 Zellen, in dem die offengelegten Anbieter blau leuchten, rechts dieselbe Menge als Liste von Bereichseinträgen, darunter zwei Balken, die die Bitlänge beider Kodierungen vergleichen
Dieselbe Menge Anbieter, zwei Kodierungen. Welche in den String kommt, entscheidet allein, welche kürzer ausfällt.

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.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

ALL ARTICLES & CATEGORIES

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Diese Rubrik per RSS verfolgen

Data Privacy

Diese Rubrik per RSS verfolgen

Digital Analytics

Alle 33 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Marketing

Alle 17 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

IT & Networks

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

Smart Home

Diese Rubrik per RSS verfolgen

Web Entwicklung

Diese Rubrik per RSS verfolgen

Wordpress Hacks

Diese Rubrik per RSS verfolgen