Krótka odpowiedź: IAB Europe opublikowała TCF 2.4 23 lipca 2026 r. Implementacje internetowe muszą zostać zmienione do 23 października 2026 r.; dla aplikacji mobilnych i CTV obowiązuje 23 lutego 2027 r. Wersja formatu TC string pozostaje 2, a wersja polityki TCF pozostaje 5. TCF 2.4 nie wprowadza zatem nowego formatu string. Kluczowe są zaktualizowane wytyczne, w szczególności bardziej rygorystyczne traktowanie uprawnionego interesu dostawców.
Najważniejsze informacje
- TCF 2.4 to aktualna specyfikacja; termin migracji jest oddzielony dla każdego środowiska.
- Web: 23 października 2026 r. Aplikacja mobilna i CTV: 23 lutego 2027 r.
- Binarna wersja TC string pozostaje 2;
tcfPolicyVersionpozostaje 5. - Już ważne zgody nie wymagają automatycznego ponownego udzielenia zgody tylko ze względu na zmianę numeru wersji. Ponowne zapytanie może być jednak konieczne z innych powodów, na przykład ze względu na zmianę dostawców, celów lub tekstów prawnych.
- Segment
DisclosedVendorsstał się obowiązkowy w TCF 2.3 i jest kontynuowany w 2.4. Nie jest to nowa funkcja 2.4. - Dostawcy nie mogą sygnalizować uprawnionego interesu wyłącznie na podstawie Special Purposes. Ta reguła 2.4 obowiązuje już od kwietnia 2026 r.
- Rejestracja i certyfikacja to różne stwierdzenia. Sprawdź również, dla którego środowiska zarejestrowana jest CMP.
Co się zmienia w IAB TCF 2.4?
TCF 2.4 aktualizuje wytyczne i specyfikacje techniczne Transparency and Consent Framework. Dla implementujących ważne jest szczególnie nie mylić numerów wersji z polami w TC string: segment Core nadal używa wersji formatu 2, a wersja polityki pozostaje 5. Integracje nie mogą zatem kodować wymyślonej wersji string "2.4" ani odrzucać wszystkich istniejących sygnałów wyłącznie ze względu na zmianę wersji.
Praktycznie najważniejsza zmiana dotyczy Vendor Legitimate Interest. Dostawca może ustawić bit LI tylko wtedy, gdy istnieje dla niego co najmniej jeden dopuszczalny cel przetwarzania. Special Purposes samodzielnie nie wystarczają. CMP muszą egzekwować tę niezmienność podczas generowania, przywracania i odwoływania sygnałów.
Disclosed Vendors: wprowadzony w 2.3, nadal wymagany w 2.4
Segment DisclosedVendors dokumentuje, którzy dostawcy zostali faktycznie pokazani osobie. Stał się obowiązkowy w TCF 2.3 i pozostaje częścią prawidłowej implementacji 2.4. Podczas migracji na 2.4 segment nie powinien być ponownie wymyślany, ale powinien być sprawdzony względem widocznej listy dostawców:
- Każdy dostawca zawarty w segmencie musi zostać ujawniony w interfejsie zgody.
- Dostawcy, którzy nie zostali wyświetleni, usunięci lub nieaktywni, nie mogą być sygnalizowani jako ujawnieni.
- Zestaw dostawców w konfiguracji, interfejsie,
DisclosedVendorsiTCDatamusi być logicznie spójny.
Terminy według środowiska
| Środowisko | Termin migracji na TCF 2.4 |
|---|---|
| Web | 23 października 2026 r. |
| Aplikacja mobilna | 23 lutego 2027 r. |
| CTV | 23 lutego 2027 r. |
Rejestracja internetowa nie obejmuje automatycznie aplikacji mobilnych ani CTV. Sprawdź wpis CMP na oficjalnej liście CMP i wymienione tam środowiska. Biscotti CMP jest obsługiwana przez Campcruisers GmbH i jest zarejestrowana z CMP-ID 497 dla Web. Rejestracja dla aplikacji natywnych ani CTV nie jest tym samym twierdzona.
Stopniowa migracja na TCF 2.4
1. Sprawdzenie statusu rejestracji i środowiska
Porównaj CMP-ID, podmiot prawny i zarejestrowane środowiska z oficjalną listą CMP. Nie polegaj na logo ani ogólnym sformułowaniu takim jak "zgodne z IAB".
2. Powiązanie aktualnej GVL i wyboru dostawcy
Załaduj aktualną Global Vendor List i określ dostawców, którzy są faktycznie używani na konkretnej stronie internetowej lub w aplikacji. Interfejs i wygenerowany status zgody muszą pochodzić z tego samego zestawu dostawców.
3. Wdrożenie reguły Vendor-LI fail-closed
Nie generuj sygnału Vendor-LI, jeśli dostawca deklaruje tylko Special Purposes lub nie pozostał żaden dopuszczalny cel LI. Sprawdź tę regułę również po Reject, odwołaniu, zmianie GVL i przywróceniu zapisanego stanu.
4. Zachowanie semantyki TC string
Nadal koduj wersję formatu TC string 2 i wersję polityki 5. Zachowaj obowiązkowy segment DisclosedVendors. Nie zmieniaj pól wersji API tylko dlatego, że specyfikacja Framework nosi nazwę 2.4.
5. Decyzja o Reconsent
Zmiana wersji sama w sobie nie jest powodem do automatycznego Reconsent. Zamiast tego sprawdź, czy cele, dostawcy, podstawy prawne, Publisher Restrictions lub informacje pokazane osobie uległy istotnym zmianom. Udokumentuj decyzję.
6. Testowanie pełnych przejść stanu
Testuj co najmniej Accept All, Reject All, wybór granularny, uprawniony interes, odwołanie, ponowne otwarcie, restart przeglądarki i aktualizację GVL. Dekoduj wygenerowane stringi niezależnie i porównaj zestawy dostawców i celów.
Lista kontrolna techniczna
__tcfapi('ping', 2, ...)zgłasza spójne dane CMP i polityki.- Wersja formatu TC string to 2, a
tcfPolicyVersionto 5. DisclosedVendorsodpowiada faktycznie widocznej liście dostawców.- Vendor-LI nigdy nie jest ustawiany bez dopuszczalnego celu LI.
- Reject i odwołanie usuwają niedozwolone sygnały zgody i LI.
- Zapisane stany są przyjmowane tylko wtedy, gdy pasują do aktualnej konfiguracji.
- CMP-ID i zarejestrowane środowisko są zgodne z publiczną listą CMP.
- Wydania Web, aplikacji mobilnych i CTV są wydawane oddzielnie.
Czy istniejący użytkownicy muszą być ponownie pytani?
Nie automatycznie. Oznaczenie wersji TCF 2.4 nie zmienia ani samego formatu TC string, ani numeru wersji polityki. Ponowna zgoda jest jednak wymagana, jeśli poprzednia decyzja nie odzwierciedla już prawidłowo aktualnego przetwarzania lub osoba musi otrzymać nowe istotne informacje. Decyzja powinna być podjęta na podstawie rzeczywistej zmiany konfiguracji i z konsultacją prawną.
Częste błędy
- Kodowanie TCF 2.4 jako nowej wersji formatu TC string.
- Zwiększanie
tcfPolicyVersionbez normatywnej podstawy. - Fałszywe opisywanie Disclosed Vendors jako nowej zmiany 2.4.
- Traktowanie Special Purposes jako wystarczającej podstawy dla Vendor-LI.
- Przedstawianie rejestracji Web jako rejestracji aplikacji mobilnej lub CTV.
- Używanie "zarejestrowany", "zwalidowany" i "certyfikowany" jako synonimy.
- Testowanie tylko ścieżki Accept All i pomijanie Reject, odwołania lub restartu.
Podsumowanie
Migracja na TCF 2.4 to nie tylko zmiana tekstu. Wymaga ona zaplanowanego wydania dla każdego środowiska, prawidłowych sygnałów Vendor-LI i dowodu, że widoczni dostawcy, zapisany stan i TC string są spójne. Ci, którzy prawidłowo rozróżniają wersję formatu 2, wersję polityki 5 i historię Disclosed Vendors, unikają najczęstszych błędów migracji.
FAQ
Czy TCF 2.4 to nowa wersja formatu TC string?
Nie. Pole wersji TC string pozostaje 2; wersja Framework 2.4 nie może być zapisana w tym polu.
Czy zmienia się wersja polityki TCF?
Nie. Dla TCF 2.4 tcfPolicyVersion pozostaje na 5.
Czy Disclosed Vendors są nowe w TCF 2.4?
Nie. Segment stał się obowiązkowy w TCF 2.3 i jest kontynuowany w 2.4.
Czy TCF 2.4 zawsze wymaga Reconsent?
Nie. Decydujące są rzeczywiste zmiany w przetwarzaniu i informacjach dla użytkownika, a nie sama numer wersji.
Czy Biscotti CMP jest zarejestrowana dla aplikacji mobilnych lub CTV?
Aktualny wpis rejestracyjny Campcruisers GmbH, CMP-ID 497, obejmuje Web. Z tego nie wynika rejestracja dla aplikacji mobilnych ani CTV.
Źródła
- IAB Europe, TCF Policies v5.0.b i Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, lista CMP: https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, Consent String and Vendor List Formats: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Ten artykuł wyjaśnia aspekty techniczne i organizacyjne i nie stanowi porady prawnej.