Коротко

TCF v2.3 — це еволюція v2.2, а не повна перебудова. Формат TC String сумісний, наявні цілі (purposes) та функції збережено, і більшість вимог до інтерфейсу для видавців залишаються без змін. Суттєві зміни зосереджені в чотирьох напрямах:

• Чіткіші правила щодо того, як CMP мають показувати інформацію про вендорів та періоди зберігання даних.
• Нові вимоги до деталізованих контролів на другому шарі, яких регулятори вимагають ще з рішення бельгійського DPA 2022 рок��.
• Посилене застосування політик щодо dark patterns, рівної помітності елементів та попередньо увімкнених опцій.
• Коригування схеми Global Vendor List (GVL) і потоку розкриття інформації про вендорів.

Чому з’явилася v2.3

Кожна версія TCF — це компроміс між трьома аудиторіями: видавцями, яким потрібно зберігати монетизацію, вендорами, яким потрібен стабільний технічний інтерфейс, і регуляторами, які постійно виявляють конкретні прогалини в дотриманні вимог. v2.3 є прямою відповіддю на три типи тиску:

1. Заходи примусового виконання проти надмірного використання "законного інтересу" у v2.2. Декілька європейських DPA визнали, що надто багато вендорів заявляли LI для цілей, де єдиною законною підставою була згода. v2.3 посилює вимоги до розкриття вендорами правової підстави та виносить ці відомості на більш помітне місце в інтерфейсі згоди.
2. Триваючі скарги на dark patterns. Оновлені Політики роблять правило рівної помітності більш однозначним і закривають лазівки щодо попередньо увімкнених перемикачів на другому шарі.
3. Операційний зворотний зв’язок від великих CMP та видавців. v2.2 запровадила кілька обов’язкових розкриттів, які було складно акуратно реалізувати на мобільних пристроях і CTV. v2.3 оптимізує набір обов’язкових розкриттів і дозволяє більшу їх частину розміщувати в багаторівневому (layered) поданні.

Сумісність TC String

Сам TC String залишається зворотно сумісним. CMP на v2.3 створює рядки, які вендори на v2.2 можуть прочитати, а вендор на v2.3 може обробляти рядки v2.2 протягом перехідного періоду. Індикатор версії в основному сегменті рядка визначає, з якою версією політик CMP заявляє відповідність, а вказівник версії GVL рухається незалежно.

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

Ключові технічні зміни

1. Розкриття інформації про вендорів і періоди зберігання

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

2. Жорсткіші контролі другого шару

На другому шарі — у поданні "керувати налаштуваннями" — v2.3 прямо вимагає, щоб перемикачі для неістотних цілей і вендорів за замовчуванням були вимкнені. Попередньо позначені чекбокси або заздалегідь увімкнені слайдери є порушенням політик, навіть якщо користувач ніколи явно не натискає "прийняти". CMP, які раніше покладалися на патерн "м’якого opt-in", мають переробити відображення другого шару.

3. Посилення правила рі��ної помітності

Правило рівної помітності існує ще з v2.1, але v2.3 формулює його з меншим простором для тлумачень: елемент керування "відхилити все" має бути на тому ж шарі, мати ту ж візуальну вагу, той самий клас контрастності кольорів і таку ж відстань взаємодії, як і "прийняти все". Приховування відхилення за посиланням, менша кнопка або винесення на другий екран тепер є явним порушенням, а не предметом оціночного судження.

4. Сигналізація законного інтересу

Вендори, які вказують законний інтерес як правову підставу у v2.3, тепер також мають задекларувати, для яких цілей вони провели оцінку законного інтересу (Legitimate Interests Assessment) і для яких її завершено. CMP зобов’язані передавати цю декларацію в інтерфейс користувача, щоб ��ористувачі могли заперечити, маючи повну інформацію. На практиці це означає, що потік "заперечити" тепер показує статус LIA для кожного вендора, а не загальний перемикач.

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

Схема Global Vendor List додає поля для деталізації періоду зберігання, статусу LIA та машинозчитуваного посилання на розділ політики конфіденційності кожного вендора для задекларованих цілей. CMP, які кешують GVL, мають оновити свій парсер схеми, щоб розуміти нові поля, перш ніж переходити на GVL v2.3.

Зміни політик, що впливають на UX

TCF — це і технічна специфікація, і набір Політик. Кілька змін у Політиках v2.3 безпосередньо стосуються інтерфейсу згоди:

• Більше ніякого "продовжити без прийняття" як еквівалента відхиленню, ��кщо тільки цей елемент візуально не збігається з кнопкою прийняття і не створює той самий TC String, що й ��овне відхилення.
• Мовний паритет — повідомлення про згоду має бути доступним усіма мовами, якими доступний сам сайт, а не лише мовою браузера користувача. CMP мають підтримувати примусове перевизначення локалі.
• Постійний доступ — користувачі мають мати змогу перейти до центру налаштувань з кожної сторінки сайту, а не лише з лендингу, і посилання на нього має бути позначене так, щоб нефаховий користувач розумів, що воно стосується згоди.

Що мають зробити видавці

1. Підтвердити підтримку v2.3 вашим CMP-вендором. Запитайте точну дату, коли буде доступна їхня збірка з сертифікацією v2.3, і який рядок версії вона буде повідомляти.
2. Оновити логіку кешування GVL. Якщо ви самостійно хостите будь-яке дзеркало GVL, оновіть парсер схеми до виходу GVL v2.3, інакше ваш CMP не зможе валідно обробляти нових вендорів.
3. Переписати інтерфейс другого шару так, щоб усі перемикачі за замовчуванням були вимкнені, правило рівної помітності було візуально дотримане, а періоди зберігання відображалися поруч із цілями.
4. Повторно провести аудит відповідності. Найпростіші цілі для регуляторів — порушення, пов’язані з dark patterns, які v2.3 тепер прямо називає. Усуньте їх до наступної перевірки.
5. Спланувати стратегію повторного запиту згоди. Хоча TC String є зворотно сумісним, Політики заохочують видавців повторно отримувати згоду, коли обсяг або розкриття обробки суттєво змінюються. Визначте, чи вважається ��аше впровадження v2.3 "суттєвим" для вашої аудиторії.

Що мають зробити вендори

1. Завершити Legitimate Interests Assessment для кожної цілі, де ви заявляєте LI, і подати результат до GVL.
2. Оновити свій запис у GVL полями схеми v2.3: деталізація періоду зберігання, декларація LIA та глибоке посилання на політику конфіденційності.
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, але це відчутне посилення правил, які утримують європейську програматик-екосистему в цілісному стані. Напрям руху очевидний: більше прозорості, менше dark patterns, більш детальний контроль користувача і менша толерантність до граничних випадків, які раніше прослизали повз. CMP і видавці, які сприймуть v2.3 як швидкий патч, знову опиняться перед регулятором. Ті ж, хто використає міграцію, щоб очистити UX другого шару, відмовитися від обхідних шляхів із законним інтересом і побудувати справді рівноправний потік згоди, вийдуть з іншого боку з інвентарем, який реально продаватиметься в епоху v2.3, — і з позицією щодо згоди, яка витримає все, що принесе наступна v2.4.