Was ist ein IAB-TCF-Consent-String?

Ein TCF-(Transparency-&-Consent-Framework)-String ist ein kompakter base64url-Datensatz, den eine Consent-Management-Plattform schreibt, um die Ad-Tech-Consent-Entscheidungen eines Nutzers zu speichern — welche Purposes, Special Features und Vendors er erlaubt hat. Ad-Tags und OpenRTB-Anfragen tragen ihn, damit nachgelagerte Vendors wissen, was sie tun dürfen.

Warum zeigt der Decoder Vendor- und Purpose-Nummern statt Namen?

Vendor- und Purpose-Namen leben in der IAB Global Vendor List, die über ein Netzwerk geladen wird. Dieses Tool dekodiert nur den String, den du einfügst, und macht keine Netzwerkaufrufe, also zeigt es die numerischen ids genau so, wie sie kodiert sind. Schlage eine id in der aktuellen Global Vendor List nach, um den Vendor-Namen zu erhalten.

Wo finde ich den einzufügenden TC-String?

Er ist im euconsent-v2-Cookie gespeichert, wird vom __tcfapi('getTCData', ...)-Aufruf der CMP zurückgegeben und in einer OpenRTB-Bid-Request als user.ext.consent übergeben. Kopiere einen dieser base64url-Werte und füge ihn in den Decoder ein.

Was ist der Unterschied zwischen Service-specific- und Global-Scope?

Das isServiceSpecific-Bit hält fest, ob der Consent für eine Site oder einen Service gespeichert wurde (true) oder im gemeinsamen globalen consensu.org-Scope (false). Der Decoder legt dieses Bit offen, sodass du erkennst, wie portabel das Signal über Properties hinweg ist.

Ändert oder signiert das Dekodieren eines TC-Strings ihn neu?

Nein. Das Dekodieren ist read-only — es interpretiert die vorhandenen Bits, ohne neu zu kodieren, neu zu signieren oder den String zu verändern. Dein ursprünglicher TC-String bleibt unverändert und wird nur lokal in deinem Browser gelesen.

Kann es Publisher-Restrictions und Extra-Segmente lesen?

Ja. Es dekodiert das Core-Segment vollständig und listet Publisher-Purpose-Restrictions mit ihrem Restriction-Typ und den betroffenen Vendors. Felder, die ein String nicht enthält — etwa fehlende optionale Segmente — zeigen sich schlicht als leer.

TCF Consent String Decoder

Dekodiere einen IAB-TCF-v2.2-Consent-String in deinem Browser, um die CMP-Metadaten, die Purpose- und Vendor-Gitter sowie Publisher-Restrictions zu sehen.

Der TCF Consent String Decoder läuft vollständig in deinem Browser. Der Consent-String, den du einfügst, wird auf deinem Gerät dekodiert, nie zu ArrayKit hochgeladen, und keine Global Vendor List oder kein entfernter Endpunkt wird kontaktiert.

TCF Consent String Encoder öffnen

Über TCF Consent String Decoder

Der TCF Consent String Decoder entpackt einen IAB-Transparency-&-Consent-(TC)-String, sodass Ad-Ops- und Privacy-Engineers genau sehen, was eine CMP festgehalten hat. Füge den base64url-String ein, und das Tool dekodiert das Core-Segment lokal: die CMP-id und -version, den Screen und die Sprache, auf denen die Wahl erfasst wurde, die created- und last-updated-Timestamps, die Global-Vendor-List-Version und die TCF-Policy-Version. Anschließend expandiert es jedes Bitfeld in lesbare id-Listen — Purpose-Consents, Purpose-Legitimate-Interests, Special-Feature-Opt-ins, Vendor-Consents, Vendor-Legitimate-Interests und alle Publisher-Restrictions. Nutze es, um einen scheiternden Consent-Handshake zu debuggen, zu auditieren, was ein Tag tatsächlich gespeichert hat, oder einen Wert zu bestätigen, bevor er deinen Ad-Server erreicht. Der String wird in deinem Browser dekodiert und verlässt dein Gerät nie.

Funktionen

Dekodiert IAB-TCF-v2.2-Core-Segment-Metadaten: CMP-id, -version, -Screen und Consent-Sprache
Expandiert Purpose-Consents und Purpose-Legitimate-Interests in lesbare id-Listen
Zeigt Special-Feature-Opt-ins neben den Vendor-Consent- und Legitimate-Interest-Gittern
Legt Publisher-Purpose-Restrictions mit ihrem Restriction-Typ und den betroffenen Vendors offen
Zeigt created- und last-updated-Timestamps plus die Global-Vendor-List-Version
Markiert Service-specific- vs. Global-Scope, non-standard Texte und OOB-Support
Kopiere jede id-Liste als kommagetrennten String für einen Bug-Report oder ein Ticket
Läuft vollständig in deinem Browser — der Consent-String wird nie hochgeladen

So verwendest du TCF Consent String Decoder

Kopiere den TC-String aus einem CMP-Cookie, einem __tcfapi-Callback oder einem OpenRTB-user.ext.consent-Feld
Füge ihn in den Decoder ein oder klicke Sample, um einen Beispiel-TC-String zu laden
Lies die CMP-Metadaten und scanne dann die Purpose-, Special-Feature- und Vendor-Gitter
Kopiere jede id-Liste, um den genauen Consent-Zustand mit deinem Team zu teilen

Beispiel

Eingabe

COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA

Ausgabe

CMP 27 · policy v2 · language EN · GVL 15
purposeConsents: 1, 2, 3
vendorConsents: 2, 6, 8

Ein Core-only-TC-String, dekodiert zu seinen CMP-Metadaten und Consent-Gittern.

Häufige Fehler & Fehlerbehebung

Der Decoder meldet, dass der String kein gültiger TC-String ist. — Füge den ganzen base64url-TC-String ohne umgebende Anführungszeichen oder Zeilenumbrüche ein. Ein abgeschnittenes Core-Segment oder eine URL-kodierte Kopie (%3D statt =) scheitert beim Dekodieren.
Die Purpose- oder Vendor-Listen sehen kürzer aus als erwartet. — Ein TC-String speichert nur ids, die die CMP explizit gesetzt hat. Ids, die fehlen, wurden nicht zugestimmt. Bestätige, dass du den vollständigen String eingefügt hast und nicht nur das Segment vor dem ersten Punkt.
Die Timestamps sehen um mehrere Stunden verschoben aus. — TCF-Timestamps werden mit Tages-Genauigkeit in UTC gespeichert. Der Decoder zeigt sie in UTC, also rechne in deine lokale Zeitzone um, bevor du sie gegen ein lokales Log vergleichst.
Du hast Vendor-Namen erwartet, siehst aber nur Zahlen. — Vendor- und Purpose-Namen stammen aus der IAB Global Vendor List, die dieses Tool nicht abruft. Gleiche die numerische id gegen die in den Metadaten gezeigte Global-Vendor-List-Version ab.

Häufig gestellte Fragen

Was ist ein IAB-TCF-Consent-String?: Ein TCF-(Transparency-&-Consent-Framework)-String ist ein kompakter base64url-Datensatz, den eine Consent-Management-Plattform schreibt, um die Ad-Tech-Consent-Entscheidungen eines Nutzers zu speichern — welche Purposes, Special Features und Vendors er erlaubt hat. Ad-Tags und OpenRTB-Anfragen tragen ihn, damit nachgelagerte Vendors wissen, was sie tun dürfen.
Warum zeigt der Decoder Vendor- und Purpose-Nummern statt Namen?: Vendor- und Purpose-Namen leben in der IAB Global Vendor List, die über ein Netzwerk geladen wird. Dieses Tool dekodiert nur den String, den du einfügst, und macht keine Netzwerkaufrufe, also zeigt es die numerischen ids genau so, wie sie kodiert sind. Schlage eine id in der aktuellen Global Vendor List nach, um den Vendor-Namen zu erhalten.
Wo finde ich den einzufügenden TC-String?: Er ist im euconsent-v2-Cookie gespeichert, wird vom __tcfapi('getTCData', ...)-Aufruf der CMP zurückgegeben und in einer OpenRTB-Bid-Request als user.ext.consent übergeben. Kopiere einen dieser base64url-Werte und füge ihn in den Decoder ein.
Was ist der Unterschied zwischen Service-specific- und Global-Scope?: Das isServiceSpecific-Bit hält fest, ob der Consent für eine Site oder einen Service gespeichert wurde (true) oder im gemeinsamen globalen consensu.org-Scope (false). Der Decoder legt dieses Bit offen, sodass du erkennst, wie portabel das Signal über Properties hinweg ist.
Ändert oder signiert das Dekodieren eines TC-Strings ihn neu?: Nein. Das Dekodieren ist read-only — es interpretiert die vorhandenen Bits, ohne neu zu kodieren, neu zu signieren oder den String zu verändern. Dein ursprünglicher TC-String bleibt unverändert und wird nur lokal in deinem Browser gelesen.
Kann es Publisher-Restrictions und Extra-Segmente lesen?: Ja. Es dekodiert das Core-Segment vollständig und listet Publisher-Purpose-Restrictions mit ihrem Restriction-Typ und den betroffenen Vendors. Felder, die ein String nicht enthält — etwa fehlende optionale Segmente — zeigen sich schlicht als leer.