Röviden

A TCF v2.3 a v2.2 továbbfejlesztése, nem pedig teljes újratervezése. A TC String formátum kompatibilis marad, a meglévő célok (purposes) és funkciók megmaradnak, és a legtöbb, kiadók felé irányuló UI-követelmény változatlanul átöröklődik. A lényegi változások négy területre koncentrálódnak:

• Világosabb szabályok arra, hogyan kell a CMP-knek megjeleníteniük a szolgáltatói információkat és az adatmegőrzési időket.
• Új követelmények a granuláris, második rétegű vezérlőkre, amelyeket a szabályozók a 2022-es belga DPA-döntés óta követelnek.
• Szigorúbb szabályzat-végrehajtás a dark patternök, az egyenrangú megjelenítés és az előre bejelölt opciók körül.
• Módosítások a Global Vendor List (GVL) sémájában és a szolgáltatói tájékoztatási folyamatban.

Miért jött létre a v2.3

Minden TCF-verzió három szereplőcsoport közötti egyeztetés eredménye: a kiadók, akiknek folytatniuk kell a bevételszerzést; a szolgáltatók, akiknek stabil technikai interfészre van szükségük; és a szabályozók, akik folyamatosan újabb megfelelési hiányosságokat tárnak fel. A v2.3 közvetlen válasz három nyomásra:

1. Végrehajtási lépések a „jogos érdek” túlhasználata ellen a v2.2 alatt. Több európai DPA úgy ítélte meg, hogy túl sok szolgáltató hivatkozott jogos érdek (LI) jogalapra olyan célokra, ahol valójában csak a hozzájárulás lett volna jogszerű. A v2.3 szigorítja a szolgáltatók által megadott jogalap-nyilatkozatokat, és ezeket korábban hozza felszínre a hozzájárulási felületen.
2. Folyamatos panaszok a dark patternökről. A frissített Policies egyértelműbbé teszi az egyenrangú megjelenítés szabályát, és bezárja azokat a kiskapukat, amelyek a második rétegen engedték az előre bejelölt kapcsolókat.
3. Gyakorlati visszajelzések nagy CMP-ktől és kiadóktól. A v2.2 több olyan kötelező tájékoztatást vezetett be, amelyeket mobilon és CTV-n nehéz volt tisztán megvalósítani. A v2.3 letisztítja a kötelező tájékoztatások körét, és lehetővé teszi, hogy ezek nagyobb része rétegezett nézetben jelenjen meg.

TC String kompatibilitás

Magának a TC Stringnek a formátuma visszafelé kompatibilis marad. Egy v2.3 CMP olyan stringeket állít elő, amelyeket a v2.2-es szolgáltatók is tudnak olvasni, és egy v2.3-as szolgáltató is fel tudja dolgozni a v2.2-es stringeket az átmeneti időszakban. A string mag-szegmensében lévő verziójelző mutatja, hogy a CMP melyik policy-verzióval való megfelelést állítja, és a GVL verziómutató ettől függetlenül lép előre.

Gyakorlati értelemben ez azt jelenti: nem kell minden szolgáltatót egyszerre frissítenie, és nem kell minden felhasználótól új hozzájárulást kérnie azon a napon, amikor a v2.3-at élesíti. A fokozatos bevezetés kifejezetten támogatott.

Fő technikai változások

1. Szolgáltatói tájékoztatás és adatmegőrzés

A v2.3 előírja, hogy a CMP-k a rétegezett UI-ban is jelenítsék meg minden egyes szolgáltató deklarált adatmegőrzési idejét, ne csak egy külön szolgáltatói listában. Az adatmegőrzési érték eddig is része volt a GVL-nek, de a v2.2 nem követelte meg, hogy a felhasználók ezt a célokkal együtt lássák. A v2.3 bezárja ezt a rést, mert a szabályozók szerint a felhasználók nem tudnak megalapozott döntést hozni anélkül, hogy tudnák, meddig maradnak meg az adataik.

2. Szigorúbb második rétegű vezérlők

A második rétegen – a „beállítások kezelése” nézetben – a v2.3 egyértelművé teszi, hogy a nem alapvető célokra és szolgáltatókra vonatkozó kapcsolóknak alapértelmezetten kikapcsolt állapotban kell lenniük. Az előre bejelölt négyzetek vagy előre bekapcsolt csúszkák policy-sértésnek minősülnek akkor is, ha a felhasználó soha nem kattint kifejezetten az „elfogadás” gombra. Azok a CMP-k, amelyek eddig „puha opt-in” mintára támaszkodtak, kénytelenek lesznek újrarajzolni a második réteget.

3. Az egyenrangú megjelenítés kikényszerítése

Az egyenrangú megjelenítés szabálya már a v2.1 óta létezik, de a v2.3 kevesebb értelmezési mozgásteret hagy: az „összes elutasítása” vezérlőnek ugyanazon a rétegen, azonos vizuális súllyal, azonos színkontraszt-osztályban és azonos interakciós távolságban kell megjelennie, mint az „összes elfogadása” gombnak. Az elutasítás elrejtése egy link mögé, kisebb gomb mögé vagy egy másodlagos képernyőre mostantól kifejezett megfelelési hibának minősül, nem pedig mérlegelés kérdésének.

4. Jogos érdek jelzése

Azoknak a szolgáltatóknak, akik a v2.3 alatt jogos érdek jogalapot deklarálnak, mostantól azt is meg kell jelölniük, hogy mely célokra végeztek érdekmérlegelési tesztet (Legitimate Interests Assessment), és melyekre fejezték be ezt. A CMP-k kötelesek ezt a nyilatkozatot átadni a felhasználói felületnek, hogy a felhasználók teljes körű tájékoztatás birtokában emelhessenek kifogást. A gyakorlatban ez azt jelenti, hogy a „kifogás” folyamat mostantól szolgáltató-specifikus LIA-státuszt mutat, nem pedig egy általános kapcsolót.

5. GVL sémafrissítések

A Global Vendor List séma új mezőkkel bővül az adatmegőrzés részletezettségére, a LIA-státuszra és egy géppel olvasható linkre minden szolgáltató adatvédelmi tájékoztatójának azon szakaszához, amely az adott célokra vonatkozik. Azoknak a CMP-knek, amelyek cache-lik a GVL-t, frissíteniük kell a sémafeldolgozójukat, hogy megértsék az új mezőket, mielőtt v2.3-as GVL-re állnak át.

A felhasználói élményt érintő policy-változások

A TCF egyszerre technikai specifikáció és Policies-gyűjtemény. A v2.3 több policy-változása közvetlenül a hozzájárulási UI-t érinti:

• Nincs többé „folytatás elfogadás nélkül” az elutasítás megfelelőjeként, hacsak nem néz ki pontosan úgy, mint az elfogadás gomb, és nem ugyanazt a TC Stringet eredményezi, mint a teljes elutasítás.
• Nyelvi paritás – a hozzájárulási értesítésnek minden olyan nyelven elérhetőnek kell lennie, amelyen maga a webhely is elérhető, nem csak a felhasználó böngészőjének nyelvén. A CMP-knek támogatniuk kell a locale felülbírálását.
• Állandó hozzáférés – a felhasználóknak a webhely minden oldaláról el kell tudniuk érni a beállítási központot, nem csak a nyitóoldalról, és a hozzáférési linket olyan módon kell feliratozni, hogy egy nem szakértő felhasználó is felismerje, hogy hozzájárulással kapcsolatos.

Mit kell tenniük a kiadóknak

1. Ellenőrizze, hogy a CMP-szolgáltatója támogatja-e a v2.3-at. Kérdezze meg, pontosan mikor lesz elérhető a v2.3-tanúsított build, és milyen verzióstringet fog jelenteni.
2. Frissítse a GVL cache-kezelését. Ha saját GVL-tükröt üzemeltet, frissítse a sémafeldolgozót a v2.3-as GVL bevezetése előtt, különben a CMP nem fogja tudni validálni az új szolgáltatókat.
3. Írja újra a második rétegű UI-t, hogy minden kapcsoló alapértelmezetten kikapcsolt legyen, az egyenrangú megjelenítés vizuálisan is teljesüljön, és az adatmegőrzési idők a célok mellett jelenjenek meg.
4. Futtassa újra a megfelelőségi auditot. A szabályozók számára a legkönnyebben „hozott pontok” a dark pattern-gyanús megoldások, amelyeket a v2.3 most kifejezetten nevesít. Ezeket még a következő ellenőrzés előtt javítsa.
5. Tervezze meg az újra-megkérdezési stratégiát. Bár a TC String visszafelé kompatibilis, a Policies arra ösztönzi a kiadókat, hogy újra kérjenek hozzájárulást, ha az adatkezelés terjedelme vagy a tájékoztatás lényegesen megváltozik. Döntse el, hogy a v2.3-as bevezetés az Ön közönsége számára „lényeges” változásnak minősül-e.

Mit kell tenniük a szolgáltatóknak

1. Végezzen Legitimate Interests Assessmentet minden olyan célra, amelyre jogos érdek jogalapot jelöl, és nyújtsa be az eredményt a GVL-nek.
2. Frissítse a GVL-bejegyzését a v2.3-as séma mezőivel: adatmegőrzési részletezettség, LIA-nyilatkozat és a privacy policy megfelelő szakaszára mutató mélylink.
3. Validálja a TC String-feldolgozóját az IAB Europe által biztosított v2.3-as referencia stringek ellen.
4. Egyeztessen a CMP-partnereivel egy közös átállási dátumról, hogy az első, v2.3-as stringet tartalmazó vásárlói kérés ne egy kizárólag v2.2-t támogató szolgáltatóhoz fusson be.

Gyakori migrációs buktatók

• A v2.3 kezelése UI-redesign lehetőségként. Csábító a márkafrissítéseket a v2.3 bevezetésével összekötni, de ez megnehezíti a megfelelőségi tesztelést. Először egy kizárólag megfelelőségi célú v2.3-kiadást szállítson, és csak utána iteráljon a dizájnon.
• Az adatmegőrzési megjelenítési követelmény figyelmen kívül hagyása. A csapatok gyakran frissítik a szolgáltatói lista nézetet, de elfelejtik, hogy az adatmegőrzésnek most már a célonkénti, rétegezett nézetben is meg kell jelennie.
• Feltételezni, hogy a TC String önmagában elég. Egy nem megfelelő UI által előállított, formailag megfelelő string továbbra is nem megfelelőnek minősül. A szabályozók többször is bírságoltak olyan szereplőket, akiknél a stringek rendben voltak, de a bannerek elrejtették az elutasítás gombot.
• A CTV és a mobil felületek kihagyása a scope-ból. A v2.3 minden olyan felületre vonatkozik, ahol TCF-jelek keletkeznek. Azok a kiadók, akik csak a webes felületet frissítik, és figyelmen kívül hagyják a CTV- vagy mobilalkalmazásaikat, hibrid, részben nem megfelelő környezetet hoznak létre.

Következtetés

A TCF v2.3 nem jelent drasztikus szakítást a v2.2-vel, de érdemi szigorítást hoz azokban a szabályokban, amelyek az európai programmatic ökoszisztémát összetartják. Az irány egyértelmű: nagyobb átláthatóság, kevesebb dark pattern, granulárisabb felhasználói kontroll és kisebb tolerancia azokra a határesetekre, amelyek korábban átcsúsztak. Azok a CMP-k és kiadók, akik a v2.3-at gyors javításként kezelik, könnyen újra a szabályozó előtt találhatják magukat. Akik viszont az átállást arra használják, hogy kitisztítsák a második rétegű UX-et, kivezessék a jogos érdek „kiskapuit”, és valódi, egyenrangú hozzájárulási folyamatot építsenek, a v2.3-korszakban is ténylegesen értékesíthető készlettel rendelkeznek majd – és olyan hozzájárulási gyakorlatuk lesz, amely a várható v2.4-es változtatásokat is nagy eséllyel kiállja.