Ghid de migrare IAB TCF v2.2 la v2.3: ce s-a schimbat și cum ar trebui CMP-urile să facă upgrade
IAB Europe Transparency and Consent Framework (TCF) este cel mai utilizat semnal de consimțământ din publicitatea programatică europeană. Versiunile acestui cadru nu sunt niciodată simple actualizări cosmetice — fiecare reflectă feedback de la autoritățile de reglementare, acțiuni de executare și lecții învățate din modul în care funcționează efectiv publisherii și vendorii. Trecerea de la TCF v2.2 la v2.3 nu face excepție.
Acest ghid parcurge ce schimbă de fapt v2.3, de ce există aceste modificări și cum să migrezi un CMP de producție fără a pierde inventarul consimțit sau a încălca Policies în timpul ferestrei de tranziție.
Versiunea scurtă
TCF v2.3 este o evoluție a v2.2, nu o rearhitecturare. Formatul TC String este compatibil, scopurile și caracteristicile existente sunt păstrate, iar majoritatea cerințelor de UI vizibile pentru publisheri rămân neschimbate. Modificările semnificative se concentrează în patru zone:
- Reguli mai clare despre modul în care CMP-urile trebuie să prezinte informațiile despre vendor și perioadele de retenție.
- Cerințe noi pentru controale granulare în al doilea strat pe care autoritățile de reglementare le solicită de la decizia DPA belgiană din 2022.
- Aplicare mai strictă a politicii în jurul dark patterns, vizibilității egale și opțiunilor pre-bifate.
- Ajustări la schema Global Vendor List (GVL) și la fluxul de dezvăluire a vendorilor.
De ce există v2.3
Fiecare versiune TCF este o negociere între trei audiențe: publisherii care trebuie să continue să monetizeze, vendorii care au nevoie de o interfață tehnică stabilă și autoritățile de reglementare care continuă să găsească lacune specifice de conformitate. v2.3 este un răspuns direct la trei presiuni:
- Acțiuni de executare împotriva abuzului de „interes legitim” sub v2.2. Mai multe DPA europene au considerat că prea mulți vendori pretindeau LI pentru scopuri în care, de fapt, doar consimțământul era legal. v2.3 înăsprește dezvăluirile privind baza legală declarată de vendor și le afișează mai devreme în UI-ul de consimțământ.
- Plângeri continue despre dark patterns. Politicile actualizate fac regula vizibilității egale mai explicită și închid lacunele legate de togglurile pre-bifate din al doilea strat.
- Feedback operațional de la CMP-uri și publisheri mari. v2.2 a introdus mai multe dezvăluiri obligatorii care erau dificil de implementat curat pe mobile și CTV. v2.3 simplifică setul de dezvăluiri obligatorii și permite ca o parte mai mare să trăiască într-o vizualizare stratificată.
Compatibilitatea TC String
TC String în sine rămâne compatibilă retroactiv. Un CMP v2.3 produce șiruri pe care vendorii v2.2 le pot citi, iar un vendor v2.3 poate consuma șiruri v2.2 în perioada de tranziție. Indicatorul de versiune din segmentul principal al șirului identifică cu ce versiune de politică susține CMP-ul că este în conformitate, iar indicatorul de versiune GVL avansează independent.
Ce înseamnă asta practic: nu trebuie să actualizezi fiecare vendor în același timp și nu trebuie să forțezi un eveniment nou de consimțământ pentru fiecare utilizator în ziua în care implementezi v2.3. O lansare pe etape este susținută în mod explicit.
Schimbări tehnice-cheie
1. Dezvăluirea vendorului și retenția
v2.3 cere ca CMP-urile să afișeze perioada de retenție a datelor declarată de fiecare vendor în UI-ul stratificat, nu doar într-o listă separată de vendori. Valoarea retenției a făcut mereu parte din GVL, dar v2.2 nu impunea ca utilizatorii să o vadă alături de scopuri. v2.3 închide acest decalaj deoarece autoritățile de reglementare au argumentat că utilizatorii nu pot face o alegere informată fără a ști cât timp vor persista datele lor.
2. Controale mai stricte în al doilea strat
Pe al doilea strat — vizualizarea „gestionează preferințele” — v2.3 este explicit că togglurile pentru scopurile și vendorii neesențiali trebuie să fie implicit oprite. Casetele pre-bifate sau glisoarele pre-activate reprezintă o încălcare a politicii chiar dacă utilizatorul nu dă niciodată clic explicit pe „acceptă”. CMP-urile care se bazau anterior pe un model „soft opt-in” vor trebui să re-rendeze al doilea strat.
3. Aplicarea vizibilității egale
Regula vizibilității egale există din v2.1, dar v2.3 o definește cu mai puțin spațiu de interpretare: controlul „respinge tot” trebuie să fie pe același strat, cu aceeași greutate vizuală, aceeași clasă de contrast de culoare și aceeași distanță de interacțiune ca „acceptă tot”. Ascunderea respingerii în spatele unui link, a unui buton mai mic sau a unui ecran secundar este acum un eșec explicit de conformitate, nu o chestiune de apreciere.
4. Semnalizarea interesului legitim
Vendorii care declară interesul legitim ca bază legală sub v2.3 trebuie acum să declare și ce scopuri au evaluat și pentru care au finalizat un Legitimate Interests Assessment. CMP-urile sunt obligate să transmită această declarație către interfața utilizatorului, astfel încât utilizatorii să poată obiecta cu informații complete. În practică, asta înseamnă că fluxul de „obiecție” afișează acum starea LIA specifică vendorului, nu un toggle generic.
5. Actualizări ale schemei GVL
Schema Global Vendor List adaugă câmpuri pentru granularitatea retenției, statutul LIA și un link lizibil de mașină către secțiunea politicii de confidențialitate a fiecărui vendor pentru scopurile declarate. CMP-urile care cache-uiesc GVL trebuie să-și reîmprospăteze parserul schemei pentru a înțelege noile câmpuri înainte de a indica spre o GVL v2.3.
Schimbări de politică ce afectează UX-ul
TCF este atât o specificație tehnică, cât și un set de Policies. Mai multe schimbări de politică din v2.3 ating direct UI-ul de consimțământ:
- Nu mai există „continuă fără a accepta” ca echivalent al respingerii decât dacă se potrivește vizual cu butonul de acceptare și produce același TC String pe care l-ar produce o respingere completă.
- Paritatea lingvistică — notificarea de consimțământ trebuie să fie disponibilă în fiecare limbă în care este disponibil site-ul însuși, nu doar în limba browserului utilizatorului. CMP-urile trebuie să suporte suprascrierea localei.
- Acces persistent — utilizatorii trebuie să poată ajunge la centrul de preferințe de pe fiecare pagină a site-ului, nu doar de pe pagina de aterizare, iar linkul de acces trebuie să fie etichetat astfel încât un utilizator neexpert să-l recunoască drept legat de consimțământ.
Ce trebuie să facă publisherii
- Confirmă suportul v2.3 al vendorului tău de CMP. Solicită data exactă la care build-ul lor certificat v2.3 va fi disponibil și șirul de versiune pe care îl va raporta.
- Reîmprospătează logica de cache a GVL. Dacă găzduiești singur vreun mirror GVL, actualizează parserul schemei înainte de lansarea GVL v2.3, altfel CMP-ul tău nu va reuși să valideze noii vendori.
- Rescrie UI-ul celui de-al doilea strat astfel încât fiecare toggle să fie implicit oprit, vizibilitatea egală să fie aplicată vizual și perioadele de retenție să fie afișate alături de scopuri.
- Rerulează auditul de conformitate. Cele mai ușoare victorii regulatorii sunt încălcările de dark patterns pe care v2.3 le denunță acum explicit. Remediază-le înainte de următoarea revizuire de executare.
- Planifică o strategie de re-promptare. Deși TC String este compatibil retroactiv, Policies încurajează publisherii să solicite din nou consimțământul când scopul sau dezvăluirea procesării se schimbă material. Decide dacă lansarea v2.3 se califică drept „materială” pentru audiența ta.
Ce trebuie să facă vendorii
- Finalizează un Legitimate Interests Assessment pentru fiecare scop în care declari LI și trimite rezultatul la GVL.
- Actualizează-ți intrarea în GVL cu câmpurile schemei v2.3: granularitatea retenției, declarația LIA și deep link-ul către politica de confidențialitate.
- Validează-ți parserul TC String față de șirurile de referință v2.3 furnizate de IAB Europe.
- Coordonează-te cu partenerii tăi CMP privind o dată comună de cutover, astfel încât prima cerere a cumpărătorului care transportă un șir v2.3 să nu aterizeze pe un vendor doar v2.2.
Capcane frecvente de migrare
- Tratarea v2.3 ca oportunitate de redesign UI. Este tentant să combini actualizările de brand cu lansarea v2.3, dar asta complică testarea conformității. Lansează mai întâi o versiune v2.3 exclusiv de conformitate, apoi iterează pe design.
- Omiterea cerinței de afișare a retenției. Echipele actualizează adesea vizualizarea listei de vendori, dar uită că retenția trebuie să apară acum și în vizualizarea stratificată scop-cu-scop.
- Presupunerea că TC String este suficient. Un șir conform produs de un UI neconform rămâne neconform. Autoritățile de reglementare au amendat în mod repetat operatori ale căror șiruri păreau în regulă, dar ale căror bannere ascundeau butonul de respingere.
- Lăsarea CTV și mobile în afara scopului. v2.3 se aplică fiecărei suprafețe pe care sunt produse semnale TCF. Publisherii care lansează o actualizare web și își ignoră aplicațiile CTV sau mobile creează un mediu hibrid neconform.
Concluzie
TCF v2.3 nu este o ruptură disruptivă față de v2.2, dar este o strângere semnificativă a regulilor care țin laolaltă ecosistemul programatic european. Direcția de mers este clară: mai multă transparență, mai puține dark patterns, mai mult control granular al utilizatorului și mai puțină toleranță pentru cazurile marginale care înainte se strecurau. CMP-urile și publisherii care tratează v2.3 ca pe un patch rapid se vor regăsi din nou în fața autorității de reglementare. Cei care folosesc migrarea pentru a curăța UX-ul celui de-al doilea strat, pentru a renunța la scurtăturile interesului legitim și pentru a reconstrui un flux real de consimțământ cu vizibilitate egală vor ieși de cealaltă parte cu inventar care trece efectiv în era v2.3 — și cu o postură de consimțământ care va supraviețui oricărei v2.4 care urmează.