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:

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:

  1. 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.
  2. 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.
  3. 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:

Co muszą zrobić wydawcy

  1. 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ć.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. Ukończ Legitimate Interests Assessment dla każdego celu, dla którego deklarujesz LI, i prześlij wynik do GVL.
  2. Zaktualizuj swój wpis GVL o pola schematu v2.3: szczegółowość przechowywania, deklaracja LIA i głęboki link do polityki prywatności.
  3. Zwaliduj swój parser TC String pod kątem referencyjnych ciągów v2.3 dostarczonych przez IAB Europe.
  4. 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

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.

← Blog Czytaj wszystko →