Накратко

TCF v2.3 е еволюция на v2.2, а не преизграждане. Форматът на TC String е съвместим, съществуващите цели и функционалности се запазват, а повечето изисквания към интерфейса към издателите остават непроменени. Съществените промени са концентрирани в четири области:

• По-ясни правила как CMP трябва да представят информация за доставчиците и периодите на съхранение.
• Нови изисквания за детайлни контроли на втори слой, които регулаторит�� изискват още от решението на белгийския DPA от 2022 г.
• Затегнато прилагане на политиките относно тъмни модели, равностойна видимост и предварително отметнати опции.
• Корекции в схемата на Global Vendor List (GVL) и потока за оповестяване на доставчиците.

Защо съществува v2.3

Всяка версия на TCF е договаряне между три аудитории: издатели, които трябва да продължат да монетизират, доставчици, които имат нужда от стабилен технически интерфейс, и регулатори, които постоянно откриват конкретни пропуски в съответствието. v2.3 е директен отговор на три вида натиск:

1. Действия по прилагане срещу прекомерна употреба на "legitimate interest" при v2.2. Няколко европейски DPA приеха, че твърде много доставчици прет��ндират LI за цели, за които всъщност единствено съгласието е законосъобразно. v2.3 затяга оповестяванията за правно основание, декларирани от доставчиците, и ги показва по-рано в интерфейса за съгласие.
2. Продължаващи жалби за тъмни модели. Обновените Policies правят правилото за равностойна видимост по-изрично и затварят вратичките около предварително отметнати плъзгачи на втория слой.
3. Оперативна обратна връзка от големи CMP и издатели. v2.2 въведе няколко задължителни оповестявания, които беше трудно да се реализират чисто на мобилни устройства и CTV. v2.3 опростява набора от задължителни оповестявания и позволява по-голяма част от тях да живеят в структуриран, многостепенен изглед.

Съвместимост на TC String

Самият TC String остава обратно съвместим. CMP с v2.3 генерира низове, които доставчици по v2.2 могат да четат, а доставчик по v2.3 може да потребява v2.2 низове през преходния период. Индикаторът за версия в основния сегмент на низа идентифицира с коя policy версия CMP заявява съответствие, а указателят към версията на GVL се развива независимо.

Практическото значение: не е нужно да обновявате всички доставчици едновременно и не е необходимо да принуждавате всеки потребител към ново събитие за съгласие в деня на внедряване на v2.3. Фазираното поетапно внедряване е изрично поддържано.

Ключови технически промени

1. Оповестяване на доставчиците и съхранение

v2.3 изисква CMP да показват декларирания от всеки доставчик период на съхранение на данните в многостепенния интерфейс, а не само в отделен списък с доставчици. Стойността за съхранение винаги е била част от GVL, но v2.2 не изискваше потребителите да я виждат заедно с целите. v2.3 премахва този пропуск, тъй като регулаторите твърдяха, че потребителите не могат да направят информиран избор, без да знаят колко дълго ще се пазят техните данни.

2. По-строги контроли на втори слой

На втория слой — изгледа „управление на предпочитанията“ — v2.3 изрично посочва, че плъзгачите за неесенциални цели и доставчици трябва по подразбиране да са изключени. Предварително отметнати кутии или предварително активирани плъзгачи са нарушение на политиките, дори ако потребителят никога изрично не щракне „приемам“. CMP, които досега разчитаха на модел „soft opt-in“, ще трябва да преработят втория слой.

3. Прилагане на правилото за равностойна видимост

Правилото за равностойна видимост съществува от v2.1, но v2.3 го формулира така, че да има по-малко място за тълкуване: контролът „откажи всички“ трябва да е на същия слой, със същото визуално тегло, същия клас контраст на цветовете и на същото разстояние за взаимодействие като „приеми всички“. Скриването на „откажи“ зад линк, по-малък бутон или вторичен екран вече е изрично нарушение, а не въпрос на преценка.

4. Сигнализиране на legitimate interest

Доставчици, които декларират legitimate interest като правно основание по v2.3, трябва да декларират и за кои цели са направили оценка и за кои от тях са завършили Legitimate Interests Assessment. CMP са задължени да пренесат тази декларация в потребителския интерфейс, така че потребителите да могат да възразят при пълна информираност. На практика това означава, че потокът за „възражение“ вече показва статус на LIA за конкретен доставчик, а не общ плъзгач.

5. Обновления в схемата на GVL

Схемата на Global Vendor List добавя полета за детайлност на периода на съхранение, статус на LIA и машинно четима връзка към секцията от политиката за поверителност на всеки доставчик за декларираните цели. CMP, които кешират GVL, трябва да обновят своя парсър за схемата, за да разбират новите полета, преди да преминат към GVL за v2.3.

Промени в политиките, които засягат UX

TCF е едновременно техническа спецификация и набор от Policies. Няколко от промените във v2.3 в Policies засягат директно интерфейса за съгласие:

• Без повече „продължи без да приемеш“ като еквивалент на отказ, освен ако визуално не съответства на бутона за приемане и не генерира същия TC String, какъвто би се генерирал при пълен отказ.
• Езикова паритетност — уведомлението за съгласие трябва да е достъпно на всеки език, на който е достъпен и самият сайт, а не само на езика на браузъра на потребителя. CMP трябва да поддържат възможност за ръчна смяна на локала.
• Постоянен достъп — потребителите трябва да могат да достигнат до центъра за предпочитания от всяка страница на сайта, а не само от началната, и линкът за достъп трябва да бъде етикетиран по начин, който и неопитен потребител би разпознал като свързан със съгласието.

Какво трябва да направят издателите

1. Потвърдете поддръжката на v2.3 от вашия CMP доставчик. Поискайте точната дата, на която техният билд, сертифициран за v2.3, ще бъде наличен, и какъв version string ще докладва.
2. Обновете логиката за кеширане на GVL. Ако самостоятелно хоствате огледално копие на GVL, актуализирайте парсъра на схемата, преди да бъде пуснат GVL за v2.3, иначе вашият CMP няма да може да валидира новите доставчици.
3. Пренапишете интерфейса на втория слой, така че всеки плъзгач да е изключен по подразбиране, равностойната видимост да е визуално осигурена и периодите на съхранение да се показват до целите.
4. Преработете одита си за съответствие. Най-лесните „победи“ за регулаторите са нарушенията, свързани с тъмни модели, които v2.3 вече изрично посочва. Отстранете ги преди следващия си преглед от регулатор.
5. Планирайте стратегия за повторно искане на съгласие. Въпреки че TC String е обратно съвместим, Policies насърчават издателите отново да търсят съгласие, когато обхватът или оповестяването на обработката се променят съществено. Решете дали вашето внедряване на v2.3 представлява „съществена“ промяна за вашата аудитория.

Какво трябва да направят доставчиците

1. Завършете Legitimate Interests Assessment за всяка цел, за която декларирате LI, и подайте резултата в GVL.
2. Обновете вашия GVL запис с полетата от схемата за v2.3: детайлност н�� периода на съхранение, декларация за LIA и deep link към политиката за поверителност.
3. Валид��райте вашия TC String парсър спрямо референтните низове за v2.3, предоставени от IAB Europe.
4. Координирайте се с вашите CMP партньори за споделена дата на преминаване, така че първата заявка за покупка, която носи v2.3 низ, да не попадне на доставчик, който поддържа само v2.2.

Чести подводни камъни при миграция

• Третиране на v2.3 като възможност за редизайн на UI. Изкушаващо е да обедините обновлението на бранда с пускането на v2.3, но това усложнява тестването за съответствие. Първо пуснете релийз за v2.3, фокусиран само върху съответствието, после надграждайте дизайна.
• Пропускане на изискването за показване на периодите на съхранение. Екипите често обновяват изгледа на списъка с доставчици, но забравят, че периодът на съхранение вече трябва да се показва и в многостепенния изглед по цели.
• Допускането, че TC String е достатъчен. Низ, който формално е в съответствие, но е произведен от несъответстващ интерфейс, остава несъответстващ. Регулаторите многократно са санкционирали оператори, при които низовете изглеждат наред, но банерите крият бутона за отказ.
• Оставяне на CTV и мобилни среди извън обхвата. v2.3 се прилага за всяка повърхност, където се генерират TCF сигнали. Издатели, които пускат актуализация за уеб, но игнорират своите CTV или мобилни приложения, създават хибридна, несъответстваща среда.

Заключение

TCF v2.3 не е разрушителен разрив с v2.2, но е съществено затягане на правилата, които държат заедно европейската програматик екосистема. Посоката е ясна: повече прозрачност, по-малко тъмни модели, по-гранулиран потребителски контрол и по-малка толерантност към граничните случаи, които преди успяваха да се промъкнат. CMP и издателите, които третират v2.3 като бърз кръп, ще се окажат отново пред регулатора. Онези, които използват миграцията, за да изчистят UX на втория слой, да се откажат от shortcuts с legitimate interest и да изградят наново реален поток за съгласие с равностойна видимост, ще излязат от другата страна с инвентар, който действително се търгува в ерата на v2.3 — и с позиция относно съгласието, която ще издържи на всичко, което v2.4 донесе след това.