Das Disclosed-Vendors-Segment in TCF 2.3: Was es enthält und wie es sich aus einem TC-String lesen lässt

Das Disclosed-Vendors-Segment eines TC-Strings meldet, welche Anbieter nach Angaben der Consent Management Platform (CMP) in der Oberfläche offengelegt wurden. Seit der Umstellung auf TCF 2.3 ist dieses zuvor optionale Segment für neu erzeugte Strings verpflichtend. Offenlegung ist dabei weder gleichbedeutend mit Einwilligung noch ein unabhängiger Beweis für die korrekte Darstellung des Banners.

Der Core steht immer zuerst. Danach kennzeichnen Segmenttypen die weiteren Teile; Disclosed Vendors muss deshalb nicht das zweite Segment sein. Ein vorhandenes PublisherTC-Segment kann vor oder nach Disclosed Vendors stehen. Der Artikel behandelt diese mit 2.3 verpflichtend gewordene Struktur; die aktuelle Spezifikation enthält inzwischen auch spätere Änderungen.

Welche Mehrdeutigkeit damit behoben wird

Die Änderung betrifft besonders Anbieter mit besonderen Zwecken und Zwecken auf Grundlage berechtigten Interesses. Zuvor konnte ein Nullbit im Vendor-LI-Bereich sowohl fehlende Offenlegung als auch einen ausgeübten Widerspruch bedeuten. Die separate Offenlegungsinformation unterscheidet diese Fälle. Daraus entsteht keine pauschale Erlaubnis für sämtliche Zwecke eines Anbieters.

Das Segment ist eine Aussage der CMP über die Offenlegung. Eine fehlerhafte CMP kann auch einen falschen Wert setzen. Die Prüfung von Oberfläche, Anbieterinformationen, gespeicherten Entscheidungen und weitergegebenen Signalen bleibt deshalb erforderlich. Ein Pflichtfeld verhindert falsche Offenlegungsbehauptungen nicht automatisch.

Aufbau: Bitfeld oder Bereichsliste

Zusatzsegmente beginnen mit drei Typbits. Disclosed Vendors hat den Typ 1, also binär 001; PublisherTC hat Typ 3. Der Core besitzt dagegen kein eigenes dreibittiges Typfeld am Anfang: Dort steht die sechs Bit lange Kodierungsversion, derzeit 2. Diese Zahl ist nicht die Framework-Versionsnummer „2.3“.

SegmentType          3 Bit  001 = DisclosedVendors
MaxVendorId (M)      16 Bit
IsRangeEncoding      1 Bit   0 = BitField, 1 = Range

BitField: M Bit, IDs 1..M
Range:    NumEntries (12 Bit), danach Einträge:
          IsARange             1 Bit
          StartOrOnlyVendorId 16 Bit
          EndVendorId         16 Bit (nur bei einem Bereich)

BitField: 20 + M Bit
Range:    32 + 17*S + 33*R Bit

MaxVendorId beschreibt die obere im Segment kodierte ID-Grenze, nicht die Anzahl offengelegter Anbieter. Das erste Bit des Bitfelds gehört zu ID 1. Ein gesetztes Bit bedeutet „als offengelegt signalisiert“, kein gesetztes Bit bedeutet keine solche Offenlegungsmeldung. Bei der Bereichsliste sind die Endpunkte eingeschlossen; Einzelkennungen benötigen kein Endfeld.

In der Formel bezeichnet S die Anzahl einzelner IDs und R die Anzahl echter Bereiche. Die Werte enthalten den Segmentkopf, aber noch keine Auffüllbits und keine Textkodierung. Die Spezifikation empfiehlt die kleinere Darstellung; „verstreut“ bedeutet trotzdem nicht automatisch „Bitfeld“. Für die Menge {1, 1200} sind es 1.220 Bit als Bitfeld, aber nur 66 Bit als zwei Einzel-Einträge. Dichte Mengen können dagegen im Bitfeld günstiger sein.

Stichtag und Google-Fehler 1.4

TCF 2.3 wurde am 19. Juni 2025 veröffentlicht. Die Übergangsfrist endete Ende Februar 2026; die aktuelle Google-Integrationsdokumentation nennt den 1. März 2026 als Pflichttermin für neu erzeugte Strings. Ältere gespeicherte Strings werden dadurch nicht pauschal rückwirkend ungültig. Die jeweiligen Übergangs- und übrigen Gültigkeitsregeln bleiben maßgeblich.

Google beschreibt Code 1.4 für ein fehlendes oder nicht verarbeitbares Disclosed-Vendors-Segment beziehungsweise fehlende Offenlegung von Google. Google Advertising Products trägt Anbieter-ID 755. Ein gesetztes Offenlegungsbit ersetzt weder weitere erforderliche Signale noch die tatsächliche Offenlegung. Ein fehlendes Google-Bit darf deshalb nicht einfach nachträglich auf 1 gesetzt werden.

Nach Googles Mitteilung können betroffene Anfragen eingeschränkte Werbung erhalten oder entfallen. Eine feste Umsatzwirkung folgt daraus nicht. Die aktuellen Hilfeseiten verweisen auf das Policy Center als Ort der TCF-Fehlerberichte; eine pauschal „stille“ Störung ohne Diagnosemöglichkeit ist das nicht.

Den tatsächlichen String lesen

Keine Punkte bedeuten bei einem vollständigen String, dass kein Zusatzsegment enthalten ist. Punkte allein beweisen umgekehrt kein korrektes Disclosed-Vendors-Segment. Entscheidend sind Typ, Dekodierbarkeit und Inhalt. Ein unbekannter oder veralteter Zusatztyp darf nicht einfach als PublisherTC interpretiert werden.

Das folgende lokale JavaScript-Modul nutzt @iabtechlabtcf/core, getestet mit Version 1.5.22. Nach Installation dieser Paketversion in einem lokalen Testprojekt kann die Funktion mit dem vollständig aus der tatsächlichen Integration gelesenen TC-String aufgerufen werden. Die Funktion liest Daten und verändert weder CMP-Speicher noch Entscheidungen.

import { TCString } from "@iabtechlabtcf/core";

export function inspectDisclosure(tcString) {
  if (typeof tcString !== "string" ||
      !/^[A-Za-z0-9_-]+(?:\.[A-Za-z0-9_-]+)*$/.test(tcString)) {
    throw new Error("Invalid segment syntax");
  }
  const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
  const segments = tcString.split(".");
  if (alphabet.indexOf(segments[0][0]) !== 2) {
    throw new Error("Expected encoding version 2");
  }
  const types = segments.slice(1).map(s => alphabet.indexOf(s[0]) >> 3);
  if (types.some(type => type !== 1 && type !== 3) ||
      new Set(types).size !== types.length) {
    throw new Error("Unsupported or duplicate segment type");
  }
  const model = TCString.decode(tcString);
  const present = types.includes(1);
  return {
    segmentPresent: present,
    disclosedVendorIds: present ? [...model.vendorsDisclosed.values()].sort((a, b) => a - b) : null,
    googleDisclosed: present ? model.vendorsDisclosed.has(755) : null,
    encodingVersion: model.version,
    policyVersion: model.policyVersion
  };
}

segmentPresent unterscheidet fehlende Offenlegung von einem vorhandenen Segment ohne die betreffende ID. null bedeutet hier fehlendes Segment, nicht eine bestätigte Ablehnung. disclosedVendorIds enthält die als offengelegt kodierten IDs; die Namen ergeben sich aus der zum String passenden Global Vendor List.

Der Code prüft einige Strukturfehler und dekodiert den Inhalt. Das Ergebnis ist keine vollständige TCF-, Rechtsgrundlagen- oder UI-Prüfung. Auch ein veralteter Policy-Wert kann dekodierbar sein. Zur Prüfung gehören frische und bereits gespeicherte Entscheidungen, die tatsächlich geladene CMP-Version und der beim Empfänger ankommende String.