Kā nolasīt TCF piekrišanas virkni: praktiska rokasgrāmata izstrādātājiem

Kas patiesībā ir TC string

IAB Transparency & Consent Framework rada vienu kompaktu marķieri — TC string — kas ceļo ar katru reklāmas pieprasījumu un pārdevējiem precīzi pasaka, ar ko lietotājs ir un ar ko nav piekritis. Tā ir Base64-URL kodēta un iesaiņota bitu līmenī, tāpēc tā izskatās kā galimatiass (CPxy...AAA), bet kodē precīzu, auditējamu ierakstu.

Segmenti

Pilna TC string ir vairāki ar punktiem atdalīti segmenti. Pirmais ir core string; pārējie ir neobligāti:

Bitu lauki ir tā sirds: bits N, iestatīts uz 1, nozīmē piekrišanu nolūkam N vai pārdevējam N. Nolūks 1 ir “informācijas glabāšana/piekļuve ierīcē,” nolūki 3 un 4 aptver personalizētas reklāmas, un tā tālāk.

Vienas dekodēšana praksē

Jūs reti dekodējat bitus ar roku. Izmantojiet IAB nodrošinātās bibliotēkas vai publisku dekodētāju:

JavaScript izsaukums __tcfapi('getTCData', 2, cb) atgriež jau parsēto objektu — tcData.purpose.consents un tcData.vendor.consents ir id → Būla vērtība kartes. Tā ir jūsu pamatpatiesība izpildlaikā.

Kļūdas, kas nogalina ieņēmumus

Kad personalizētais pieprasījums klusi pazūd, TC string parasti ir iemesls:

Atkļūdošanas darbplūsma

Reproducējiet lietotāja piekrišanu, satveriet aktīvo TC string no __tcfapi vai reklāmas pieprasījuma, izlaidiet to caur validatoru un salīdziniet dekodētos nolūkus/pārdevējus ar to, ko jūsu partneri pieprasa. Deviņas reizes no desmit nepilnība ir viens pārdevēja bits vai trūkstošs nolūks 1.

Kur iederas FlexyConsent

FlexyConsent ģenerē specifikācijai derīgas TC string ar reģistrētu CMP ID, uztur tās svaigas, atklāj dekodēto stāvokli atkļūdošanai un ziņo, kuri nolūki un pārdevēji faktiski tiek piešķirti visā jūsu satiksmē — lai jūs varētu redzēt, nevis minēt, kur piekrišana (un ieņēmumi) noplūst.

Galvenās atziņas

← Blogs Lasīt visu →