Hvordan lese en TCF-samtykkestreng: En feltguide for utviklere

Hva TC-strengen egentlig er

IAB Transparency & Consent Framework produserer ett kompakt token — TC-strengen — som følger med hver annonseforespørsel og forteller leverandører nøyaktig hva en bruker har og ikke har samtykket til. Den er Base64-URL-kodet og pakket på bitnivå, så den ser ut som vrøvl (CPxy...AAA) men koder en presis, reviderbar post.

Segmentene

En full TC-streng er flere punktseparerte segmenter. Det første er kjernestrengen; de andre er valgfrie:

Bitfeltene er kjernen i det: bit N satt til 1 betyr samtykke for formål N eller leverandør N. Formål 1 er “lagre/få tilgang til informasjon på en enhet,” formål 3 og 4 dekker personaliserte annonser, og så videre.

Dekode en i praksis

Du dekoder sjelden bits for hånd. Bruk IAB-leverte biblioteker eller en offentlig dekoder:

I JavaScript returnerer kallet __tcfapi('getTCData', 2, cb) det allerede parsede objektet — tcData.purpose.consents og tcData.vendor.consents er kart over id → boolean. Det er din grunnsannhet ved kjøretid.

Feilene som dreper inntekter

Når personalisert etterspørsel stille forsvinner, er TC-strengen vanligvis grunnen:

En feilsøkingsarbeidsflyt

Reproduser brukerens samtykke, hent den live TC-strengen fra __tcfapi eller annonseforespørselen, kjør den gjennom en validator, og sammenlign de dekodede formålene/leverandørene mot hva partnerne dine krever. Ni av ti ganger er gapet en enkelt leverandørbit eller et manglende formål 1.

Hvor FlexyConsent passer inn

FlexyConsent genererer spesifikasjonsgyldige TC-strenger med en registrert CMP-ID, holder dem ferske, eksponerer den dekodede tilstanden for feilsøking, og rapporterer hvilke formål og leverandører som faktisk gis på tvers av trafikken din — så du kan se, ikke gjette, hvor samtykke (og inntekt) lekker.

Viktige poenger

← Blogg Les alt →