Przewodnik migracji z IAB TCF v2.2 do v2.3: co się zmieniło i jak CMP powinny wykonać aktualizację
IAB Europe Transparency and Consent Framework (TCF) to najszerzej stosowany sygnał zgody w europejskiej reklamie programatycznej. Wersje tego frameworku nigdy nie są tylko kosmetycznymi aktualizacjami — każda z nich odzwierciedla informacje zwrotne od regulatorów, działania egzekucyjne oraz wnioski płynące z tego, jak naprawdę działają wydawcy i dostawcy. Przejście z TCF v2.2 do v2.3 nie jest wyjątkiem.
Ten przewodnik omawia, co faktycznie zmienia v2.3, dlaczego te zmiany istnieją i jak zmigrować produkcyjny CMP bez utraty inventaryzowanej zgody ani naruszania Policies w okresie przejściowym.
Wersja skrócona
TCF v2.3 jest ewolucją v2.2, a nie ponownym projektem architektonicznym. Format TC String jest kompatybilny, istniejące cele i funkcje są zachowane, a większość wymagań UI widocznych dla wydawców pozostaje bez zmian. Istotne zmiany koncentrują się w czterech obszarach:
- Jaśniejsze zasady dotyczące tego, w jaki sposób CMP muszą prezentować informacje o dostawcach i okresy przechowywania.
- Nowe wymogi dotyczące szczegółowych kontrolek drugiej warstwy, których regulatorzy domagali się od decyzji belgijskiego DPA z 2022 roku.
- Zaostrzone egzekwowanie polityki w zakresie dark patterns, równej widoczności i wstępnie zaznaczonych opcji.
- Dostosowania schematu Global Vendor List (GVL) oraz przepływu ujawniania dostawców.
Dlaczego istnieje v2.3
Każda wersja TCF jest negocjacją między trzema grupami: wydawcami, którzy muszą nadal monetyzować, dostawcami, którzy potrzebują stabilnego interfejsu technicznego, oraz regulatorami, którzy nadal znajdują konkretne luki w zgodności. v2.3 jest bezpośrednią odpowiedzią na trzy naciski:
- Działania egzekucyjne wobec nadużywania „uzasadnionego interesu” w ramach v2.2. Kilka europejskich DPA uznało, że zbyt wielu dostawców powoływało się na LI dla celów, dla których zgodna z prawem była tylko zgoda. v2.3 zaostrza ujawnianie zadeklarowanej przez dostawcę podstawy prawnej i pokazuje je wcześniej w interfejsie zgody.
- Trwające skargi dotyczące dark patterns. Zaktualizowane Policies wyraźniej precyzują zasadę równej widoczności i zamykają luki związane ze wstępnie zaznaczonymi przełącznikami w drugiej warstwie.
- Informacje operacyjne od dużych CMP i wydawców. v2.2 wprowadziło kilka obowiązkowych ujawnień, które były trudne do czystej implementacji na urządzeniach mobilnych i CTV. v2.3 usprawnia obowiązkowy zestaw ujawnień i pozwala, aby większa jego część mieściła się w widoku warstwowym.
Kompatybilność TC String
Sam TC String pozostaje kompatybilny wstecz. CMP zgodny z v2.3 produkuje ciągi, które dostawcy v2.2 mogą odczytać, a dostawca v2.3 może konsumować ciągi v2.2 w okresie przejściowym. Wskaźnik wersji w głównym segmencie ciągu identyfikuje, z którą wersją polityki CMP deklaruje zgodność, a wskaźnik wersji GVL przesuwa się do przodu niezależnie.
Praktycznie oznacza to: nie trzeba aktualizować każdego dostawcy jednocześnie i nie trzeba wymuszać nowego zdarzenia zgody u każdego użytkownika w dniu wdrożenia v2.3. Etapowe wdrożenie jest wyraźnie wspierane.
Kluczowe zmiany techniczne
1. Ujawnianie dostawcy i przechowywanie
v2.3 wymaga, aby CMP wyświetlały zadeklarowany przez każdego dostawcę okres przechowywania danych w warstwowym interfejsie, a nie tylko na osobnej liście dostawców. Wartość przechowywania zawsze była częścią GVL, ale v2.2 nie nakazywało, aby użytkownicy widzieli ją obok celów. v2.3 zamyka tę lukę, ponieważ regulatorzy argumentowali, że użytkownicy nie mogli dokonać świadomego wyboru bez wiedzy, jak długo będą przechowywane ich dane.
2. Surowsze kontrolki drugiej warstwy
W drugiej warstwie — widoku „zarządzaj preferencjami” — v2.3 wyraźnie stwierdza, że przełączniki dla nieistotnych celów i dostawców muszą być domyślnie wyłączone. Wstępnie zaznaczone pola lub wstępnie włączone suwaki są naruszeniem polityki, nawet jeśli użytkownik nigdy jawnie nie kliknie „akceptuj”. CMP, które wcześniej polegały na wzorcu „soft opt-in”, będą musiały przerenderować drugą warstwę.
3. Egzekwowanie równej widoczności
Zasada równej widoczności istnieje od v2.1, ale v2.3 definiuje ją z mniejszym polem do interpretacji: kontrolka „odrzuć wszystko” musi znajdować się w tej samej warstwie, mieć ten sam ciężar wizualny, tę samą klasę kontrastu kolorów i tę samą odległość interakcji co „akceptuj wszystko”. Ukrywanie odrzucenia za linkiem, mniejszym przyciskiem lub drugorzędnym ekranem jest teraz wyraźnym niepowodzeniem zgodności, a nie kwestią oceny.
4. Sygnalizacja uzasadnionego interesu
Dostawcy, którzy deklarują uzasadniony interes jako podstawę prawną w ramach v2.3, muszą teraz również zadeklarować, które cele ocenili i dla których zakończyli Legitimate Interests Assessment. CMP są zobowiązane przekazać tę deklarację do interfejsu użytkownika, aby użytkownicy mogli wnieść sprzeciw z pełną informacją. W praktyce oznacza to, że przepływ „sprzeciw” pokazuje teraz status LIA specyficzny dla dostawcy, a nie ogólny przełącznik.
5. Aktualizacje schematu GVL
Schemat Global Vendor List dodaje pola dla szczegółowości przechowywania, statusu LIA oraz czytelnego maszynowo linku do sekcji polityki prywatności każdego dostawcy dla zadeklarowanych celów. CMP, które cache'ują GVL, muszą odświeżyć swój parser schematu, aby zrozumieć nowe pola, zanim wskazane zostanie na GVL v2.3.
Zmiany w polityce wpływające na UX
TCF to zarówno specyfikacja techniczna, jak i zestaw Policies. Kilka zmian Policy w v2.3 ląduje bezpośrednio na interfejsie zgody:
- Koniec z „kontynuuj bez akceptowania” jako odpowiednikiem odrzucenia, chyba że wizualnie pasuje do przycisku akceptacji i produkuje ten sam TC String, jaki utworzyłoby pełne odrzucenie.
- Parytet językowy — powiadomienie o zgodzie musi być dostępne w każdym języku, w którym dostępna jest sama witryna, a nie tylko w języku przeglądarki użytkownika. CMP muszą obsługiwać nadpisywanie ustawień regionalnych.
- Trwały dostęp — użytkownicy muszą mieć możliwość dotarcia do centrum preferencji z każdej strony witryny, a nie tylko ze strony głównej, a link dostępu musi być oznaczony w sposób, który użytkownik niebędący ekspertem rozpozna jako związany ze zgodą.
Co muszą zrobić wydawcy
- Potwierdź wsparcie v2.3 u swojego dostawcy CMP. Zapytaj o dokładną datę, kiedy ich certyfikowana wersja v2.3 będzie dostępna, oraz o ciąg wersji, który będzie raportować.
- Odśwież logikę cache'a GVL. Jeśli sam hostujesz jakiekolwiek lustro GVL, zaktualizuj parser schematu przed udostępnieniem GVL v2.3, w przeciwnym razie twój CMP nie zwaliduje nowych dostawców.
- Przepisz UI drugiej warstwy, aby każdy przełącznik był domyślnie wyłączony, równa widoczność była wizualnie egzekwowana, a okresy przechowywania były wyświetlane obok celów.
- Ponownie przeprowadź audyt zgodności. Najłatwiejsze wygrane regulacyjne to naruszenia dark patterns, które v2.3 wyraźnie teraz wskazuje. Napraw je przed następnym przeglądem egzekucyjnym.
- Zaplanuj strategię ponownego monitu. Chociaż TC String jest kompatybilny wstecz, Policies zachęcają wydawców do ponownego uzyskania zgody, gdy zakres lub ujawnienie przetwarzania zmieniają się istotnie. Zdecyduj, czy twoje wdrożenie v2.3 kwalifikuje się jako „istotne” dla twojej publiczności.
Co muszą zrobić dostawcy
- Ukończ Legitimate Interests Assessment dla każdego celu, dla którego deklarujesz LI, i prześlij wynik do GVL.
- Zaktualizuj swój wpis GVL o pola schematu v2.3: szczegółowość przechowywania, deklaracja LIA i głęboki link do polityki prywatności.
- Zwaliduj swój parser TC String pod kątem referencyjnych ciągów v2.3 dostarczonych przez IAB Europe.
- Koordynuj z partnerami CMP wspólną datę przełączenia, aby pierwsze żądanie kupującego niosące ciąg v2.3 nie trafiło na dostawcę obsługującego tylko v2.2.
Typowe pułapki migracji
- Traktowanie v2.3 jako okazji do przeprojektowania UI. Kuszące jest powiązanie aktualizacji marki z wdrożeniem v2.3, ale komplikuje to testy zgodności. Najpierw wydaj wersję v2.3 skupioną wyłącznie na zgodności, a następnie iteruj projekt.
- Pominięcie wymagania wyświetlania przechowywania. Zespoły często aktualizują widok listy dostawców, ale zapominają, że przechowywanie musi teraz pojawić się również w warstwowym widoku cel po celu.
- Zakładanie, że TC String wystarczy. Zgodny ciąg wyprodukowany przez niezgodny UI nadal jest niezgodny. Regulatorzy wielokrotnie karali operatorów, których ciągi wyglądały dobrze, ale których banery ukrywały przycisk odrzucenia.
- Pozostawianie CTV i mobile poza zakresem. v2.3 dotyczy każdej powierzchni, na której generowane są sygnały TCF. Wydawcy, którzy dostarczają aktualizację webową i ignorują swoje aplikacje CTV lub mobilne, tworzą hybrydowe środowisko niezgodne.
Podsumowanie
TCF v2.3 nie jest zakłócającym zerwaniem z v2.2, ale jest znaczącym zaostrzeniem zasad, które spajają europejski ekosystem programatyczny. Kierunek jest jasny: więcej przejrzystości, mniej dark patterns, bardziej szczegółowa kontrola użytkownika i mniej tolerancji dla skrajnych przypadków, które kiedyś umykały. CMP i wydawcy, którzy traktują v2.3 jak szybką łatkę, znajdą się z powrotem przed regulatorem. Ci, którzy wykorzystają migrację do posprzątania UX drugiej warstwy, wycofania skrótów uzasadnionego interesu i odbudowania prawdziwego przepływu zgody z równą widocznością, wyjdą z drugiej strony z inventarzem, który naprawdę przejdzie w erze v2.3 — i z postawą zgody, która przetrwa cokolwiek przyniesie v2.4.