Was der TC String tatsächlich ist

Das IAB Transparency & Consent Framework erzeugt ein einziges kompaktes Token — den TC String — das mit jeder Werbeanfrage mitreist und Anbietern genau mitteilt, was ein Nutzer zugestimmt und was er nicht zugestimmt hat. Er ist Base64-URL-kodiert und auf Bit-Ebene gepackt, sodass er wie Kauderwelsch aussieht (CPxy...AAA), aber einen präzisen, prüfbaren Datensatz kodiert.

Die Segmente

Ein vollständiger TC String besteht aus mehreren durch Punkte getrennten Segmenten. Das erste ist der Core String; andere sind optional:

• Core — CMP-ID, CMP-Version, die Einwilligungs-Zeitstempel, die Richtlinienversion und entscheidend die Bitfelder der Zweck-Einwilligungen und Anbieter-Einwilligungen.
• Offengelegte Anbieter — welche Anbieter dem Nutzer gezeigt wurden.
• Publisher TC — Einwilligungen, die spezifisch für Sie, den Publisher, gelten.

Die Bitfelder sind das Herzstück: Bit N auf 1 gesetzt bedeutet Einwilligung für Zweck N oder Anbieter N. Zweck 1 ist “Informationen auf einem Gerät speichern/abrufen”, Zweck 3 und 4 decken personalisierte Werbung ab und so weiter.

Einen in der Praxis dekodieren

Sie dekodieren Bits selten von Hand. Verwenden Sie die vom IAB bereitgestellten Bibliotheken oder einen öffentlichen Decoder:

• Am . trennen und das Core-Segment per Base64-URL dekodieren.
• Lesen Sie die Header-Felder mit fester Breite (Version, created, lastUpdated, cmpId, cmpVersion).
• Durchlaufen Sie die Zweck- und Anbieter-Bitfelder, um genau zu sehen, welche erteilt sind.

In JavaScript gibt der Aufruf __tcfapi('getTCData', 2, cb) das bereits geparste Objekt zurück — tcData.purpose.consents und tcData.vendor.consents sind Maps von id → boolean. Das ist Ihre verlässliche Grundlage zur Laufzeit.

Die Fehler, die Umsatz kosten

Wenn personalisierte Nachfrage stillschweigend verschwindet, ist meist der TC String der Grund:

• Fehlender String — die Werbeanfrage trägt keinen gdprApplies/TC String, sodass konforme SSPs auf nicht-personalisiert zurückfallen.
• Anbieter nicht eingewilligt — das Anbieter-ID-Bit Ihres Demand-Partners ist 0, sodass er nicht mit Personalisierung bieten kann.
• Abgelaufener oder veralteter String — ein alter Zeitstempel führt dazu, dass nachgelagerte Plattformen ihm misstrauen.
• Falsche CMP-ID — eine nicht registrierte oder Test-CMP-ID macht den gesamten String ungültig.

Ein Debugging-Workflow

Reproduzieren Sie die Einwilligung des Nutzers, holen Sie sich den Live-TC-String aus __tcfapi oder der Werbeanfrage, lassen Sie ihn durch einen Validator laufen und vergleichen Sie die dekodierten Zwecke/Anbieter mit dem, was Ihre Partner verlangen. In neun von zehn Fällen ist die Lücke ein einzelnes Anbieter-Bit oder ein fehlender Zweck 1.

Wo FlexyConsent passt

FlexyConsent generiert spec-valide TC Strings mit einer registrierten CMP-ID, hält sie frisch, legt den dekodierten Zustand zum Debuggen offen und meldet, welche Zwecke und Anbieter über Ihren Traffic hinweg tatsächlich erteilt werden — sodass Sie sehen statt raten können, wo Einwilligung (und Umsatz) versickert.

Wichtigste Erkenntnisse

• Der TC String ist ein bit-gepackter, prüfbarer Datensatz jeder Einwilligungswahl.
• Zweck- und Anbieter-Bitfelder entscheiden, ob Partner personalisierte Werbung ausliefern können.
• Die meisten Umsatzeinbrüche lassen sich auf einen fehlenden String, einen nicht eingewilligten Anbieter oder eine veraltete/ungültige CMP-ID zurückführen.
• Dekodieren Sie den Live-String mit __tcfapi und validieren Sie ihn beim Debuggen gegen die Partneranforderungen.