Кратък отговор: IAB Europe издаде TCF 2.4 на 23 юли 2026 г. Внедряванията в уеб трябва да бъдат актуализирани до 23 октомври 2026 г.; за мобилни приложения и CTV крайният срок е 23 февруари 2027 г. Версията на формата TC-String остава 2, а версията на политиката TCF остава 5. Следователно TCF 2.4 не въвежда нов формат на string като цяло. Важни са актуализираните политики, особено по-строгото третиране на законния интерес на доставчиците.
Най-важното
- TCF 2.4 е текущата спецификация; крайният срок за преход е разделен по среда.
- Уеб: 23 октомври 2026 г. Мобилно приложение и CTV: 23 февруари 2027 г.
- Двоичната версия на TC-String остава 2;
tcfPolicyVersionостава 5. - Вече валидни съгласия не изискват ново съгласие само поради промяна на версията. Ново запитване може да е необходимо по други причини, като например промени в доставчиците, целите или правните текстове.
- Сегментът
DisclosedVendorsстана задължителен с TCF 2.3 и продължава в 2.4. Това не е нова функция на 2.4. - Доставчиците не могат да сигнализират законния интерес само на основата на специални цели. Това правило на 2.4 вече се прилага от април 2026 г.
- Регистрацията и сертификацията са различни твърдения. Проверете също в каква среда е регистрирана CMP.
Какво се променя с IAB TCF 2.4?
TCF 2.4 актуализира политиките и техническите спецификации на Рамката за прозрачност и съгласие. За внедряващите е особено важно да не се бъркат номерата на версиите с полетата в TC-String: основният сегмент продължава да използва версия на формата 2, а версията на политиката остава 5. Следователно интеграциите не трябва да кодират измислена версия на string "2.4" и не трябва да отхвърлят всички съществуващи сигнали само поради промяна на версията.
Практически най-важната промяна се отнася до Vendor Legitimate Interest. Доставчик може да зададе LI бит само ако има поне една допустима цел на обработка. Специалните цели сами по себе си не са достатъчни. CMP трябва да наложат този инвариант при създаване, възстановяване и отмяна на сигналите.
Disclosed Vendors: въведено в 2.3, все още необходимо в 2.4
Сегментът DisclosedVendors документира кои доставчици са действително показани на лицето. Стана задължителен с TCF 2.3 и остава част от правилното внедряване на 2.4. При преход към 2.4 сегментът не трябва да бъде преизмислен, а да бъде проверен спрямо видимия списък на доставчиците:
- Всеки доставчик, съдържащ се в сегмента, трябва да е бил разкрит в интерфейса на съгласието.
- Доставчици, които не са показани, изтрити или неактивни, не трябва да бъдат сигнализирани като разкрити.
- Наборът от доставчици в конфигурацията, интерфейса,
DisclosedVendorsиTCDataтрябва да съответства по проследим начин.
Крайни срокове по среда
| Среда | Краен срок за преход към TCF 2.4 |
|---|---|
| Уеб | 23 октомври 2026 г. |
| Мобилно приложение | 23 февруари 2027 г. |
| CTV | 23 февруари 2027 г. |
Регистрацията в уеб не покрива автоматично мобилни приложения или CTV. Проверете записа на CMP в официалния списък на CMP и средите, посочени там. Biscotti CMP се управлява от Campcruisers GmbH и е регистриран с CMP ID 497 за уеб. Не се твърди регистрация на собствено приложение или CTV.
Постепенен преход към TCF 2.4
1. Проверка на статуса на регистрацията и средата
Сравнете CMP ID, правния субект и регистрираните среди със списъка на официалния CMP. Не разчитайте на логото или обща формулировка като "IAB съответствие".
2. Свързване на текущия глобален списък на доставчиците и избор на доставчици
Заредете текущ глобален списък на доставчиците и определете доставчиците, които действително се използват за конкретния уебсайт или приложение. Интерфейсът и генерираният статус на съгласието трябва да бъдат получени от един и същ набор от доставчици.
3. Внедряване на правилото Vendor-LI по безопасен начин
Не генерирайте сигнал Vendor-LI, ако доставчикът е декларирал само специални цели или не остава допустима LI цел. Проверете това правило и след отхвърляне, отмяна, промяна на GVL и възстановяване на запазено състояние.
4. Запазване на семантиката на TC-String
Продължете да кодирате версия на формата TC-String 2 и версия на политиката 5. Запазете задължителния сегмент DisclosedVendors. Не променяйте полетата на версията на API само защото спецификацията на рамката се нарича 2.4.
5. Целево решение за повторно съгласие
Промяната на версията сама по себе си не е причина за общо повторно съгласие. Вместо това проверете дали целите, доставчиците, правната основа, ограниченията на издателя или информацията, показана на лицето, са се променили съществено. Документирайте решението.
6. Тестване на пълни преходи на състояние
Тестирайте поне Приемане на всички, Отхвърляне на всички, детайлен избор, законен интерес, отмяна, повторно отваряне, рестартиране на браузъра и актуализация на GVL. Декодирайте генерираните strings независимо и сравнете наборите от доставчици и цели.
Техническа контролна лист
__tcfapi('ping', 2, ...)докладва последователни данни на CMP и политика.- Версията на формата TC-String е 2 и
tcfPolicyVersionе 5. DisclosedVendorsсъответства на действително видимия списък на доставчиците.- Vendor-LI никога не се задава без допустима LI цел.
- Отхвърляне и отмяна премахват недопустими сигнали на съгласие и LI.
- Запазени състояния се приемат само ако съответстват на текущата конфигурация.
- CMP ID и регистрирана среда съответстват на публичния списък на CMP.
- Издания за уеб, мобилни приложения и CTV се издават отделно.
Трябва ли съществуващите потребители да бъдат попитани отново?
Не автоматично. Обозначението на версията TCF 2.4 не променя само формата на TC-String нито номера на версията на политиката. Ново съгласие е необходимо, ако предишното решение вече не отразява точно текущата обработка или лицето трябва да получи нова съществена информация. Решението трябва да бъде взето въз основа на действителната промяна в конфигурацията и с правна консултация.
Често срещани грешки
- Кодиране на TCF 2.4 като нова версия на формата TC-String.
- Увеличаване на
tcfPolicyVersionбез нормативна основа. - Неправилно описание на Disclosed Vendors като нова промяна на 2.4.
- Третиране на специални цели като достатъчна основа за Vendor-LI.
- Представяне на регистрация в уеб като регистрация на мобилно приложение или CTV.
- Синонимно използване на "регистриран", "валидиран" и "сертифициран".
- Тестване само на пътя за приемане на всички и пропускане на отхвърляне, отмяна или рестартиране.
Заключение
Преходът към TCF 2.4 не е просто текстова промяна. Той изисква издание, планирано по среда, правилни сигнали Vendor-LI и доказателство, че видимите доставчици, запазено състояние и TC-String съответстват. Всеки, който правилно разграничава версия на формата 2, версия на политиката 5 и историята на Disclosed Vendors, избягва най-честите грешки при преход.
Често задавани въпроси
Е ли TCF 2.4 нова версия на формата TC-String?
Не. Полето на версията в TC-String остава 2; версията на рамката 2.4 не трябва да се записва в това поле.
Променя ли се версията на политиката TCF?
Не. За TCF 2.4 tcfPolicyVersion остава 5.
Е ли Disclosed Vendors ново в TCF 2.4?
Не. Сегментът стана задължителен с TCF 2.3 и продължава в 2.4.
Изисква ли TCF 2.4 винаги повторно съгласие?
Не. Важни са действителните промени в обработката и информацията на потребителя, не само номера на версията.
Е ли Biscotti CMP регистриран за мобилни приложения или CTV?
Текущият запис на регистрацията на Campcruisers GmbH, CMP ID 497, покрива уеб. От това не следва регистрация за мобилни приложения или CTV.
Източници
- IAB Europe, TCF Policies v5.0.b и Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, списък на CMP: https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, формати на Consent String и списък на доставчиците: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Този пост обяснява технически и организационни аспекти и не е правна консултация.