Dlaczego problemy z GPP trudno zauważyć

Gdy odwiedzający z USA rezygnuje ze sprzedaży lub udostępniania swoich danych, ten wybór musi dotrzeć do każdego partnera reklamowego na stronie. W IAB Global Privacy Platform (GPP) podróżuje jako zwarty ciąg i lista identyfikatorów sekcji. Jeśli któryś z nich jest błędny — brakuje go, jest nieaktualny lub zawiera niewłaściwą sekcję — nic się wizualnie nie psuje. Reklamy nadal się ładują, baner wygląda dobrze, a problem ujawnia się dopiero później: partnerzy ignorują rezygnacje albo oferują mniej za Twój zasób reklamowy.

Dobra wiadomość jest taka, że prawie wszystko można sprawdzić z poziomu konsoli przeglądarki. Ten poradnik przechodzi przez kontrole w kolejności, w jakiej uruchomilibyśmy je na działającej stronie.

Krok 1: Potwierdź, że API istnieje i jest gotowe

CMP zgodne z GPP udostępnia globalną funkcję __gpp. Otwórz DevTools na swojej stronie i uruchom polecenie ping:

__gpp('ping', function (data) { console.log(data); });

Zwrócony obiekt od razu wiele mówi:

• gppVersion — w obecnych implementacjach powinno wynosić 1.1.
• cmpStatus — czy CMP się załadowało, czy wystąpił błąd.
• cmpDisplayStatus — czy baner jest dla tego odwiedzającego widoczny, ukryty czy wyłączony.
• signalStatus — „ready”, gdy CMP ustaliło stan zgody, „not ready”, gdy jeszcze się decyduje.
• supportedAPIs — sekcje, które CMP potrafi wygenerować.
• applicableSections — identyfikatory sekcji, które w tej chwili dotyczą tego odwiedzającego.
• gppString — sam zakodowany ciąg.

Jeśli __gpp jest niezdefiniowane, brakuje stuba CMP lub ładuje się on zbyt późno. Stub musi być na miejscu przed każdym skryptem reklamowym, który go oczekuje, w przeciwnym razie te skrypty nie zobaczą żadnego CMP i albo będą czekać, albo ruszą bez sygnału.

Krok 2: Sprawdź właściwą sekcję

Każda ramowa regulacja prywatności w GPP ma numeryczny identyfikator sekcji. Wydawcy najczęściej spotykają 2 (EU TCF v2), 5 (kanadyjski TCF), 7 (US National, „usnat”) oraz 8 i dalej dla sekcji poszczególnych stanów, takich jak Kalifornia, Wirginia, Kolorado, Utah i Connecticut. Odwiedzający z jednego ze stanów USA powinien normalnie mieć w applicableSections sekcję krajową lub odpowiednią sekcję stanową, a nie sekcję UE.

Testuj z kilku lokalizacji. Częsty błąd to CMP, które poprawnie wykrywa geografię dla banera, ale zapisuje w ciągu domyślną sekcję niezależnie od niej, lub odwrotnie. Za pomocą VPN lub narzędzi podglądu w CMP porównaj to, co pokazuje baner, z tym, co raportuje applicableSections.

Krok 3: Odczytaj dane sekcji

Zamiast dekodować ciąg ręcznie, poproś CMP o sparsowaną sekcję:

__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');

W sekcji US National pola rezygnacji stosują prostą konwencję: 0 oznacza nie dotyczy, 1 oznacza, że użytkownik zrezygnował, a 2 oznacza, że użytkownik nie zrezygnował. Najpierw skup się na tych polach:

• SaleOptOut i SharingOptOut
• TargetedAdvertisingOptOut
• Odpowiadające im pola notice, które rejestrują, czy odwiedzającemu przedstawiono informację o każdej praktyce

Teraz wykonaj rezygnację na stronie — kliknij link „Do Not Sell or Share” lub przełącz ustawienie w centrum preferencji — i uruchom getSection ponownie. Pola rezygnacji powinny zmienić się z 2 na 1. Jeśli nie, interfejs i sygnał są rozsynchronizowane.

Krok 4: Przetestuj ścieżkę Global Privacy Control

Kilka stanowych ustaw wymaga, aby podmioty traktowały sygnał Global Privacy Control jako rezygnację. Włącz GPC w przeglądarce lub rozszerzeniu, które go obsługuje, potwierdź, że navigator.globalPrivacyControl zwraca true w konsoli, a następnie załaduj stronę w nowej sesji. Odpowiednie pola rezygnacji powinny już pokazywać 1, bez dotykania banera przez odwiedzającego. Niektóre sekcje zawierają też pole wskazujące, że wybór pochodzi z sygnału GPC.

Krok 5: Obserwuj zdarzenia, nie tylko migawki

Skrypty reklamowe nie powinny odczytywać ciągu raz przy ładowaniu strony i o nim zapominać. Zarejestruj listener, aby zobaczyć to, co widzą partnerzy:

__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });

Powinieneś zobaczyć zdarzenia takie jak listenerRegistered, signalStatus i sectionChange. Gdy odwiedzający zmieni wybór, powinno nastąpić zdarzenie sectionChange z zaktualizowanym ciągiem. Jeśli Twój wrapper header biddingu lub integracja z ad serverem odczytuje ciąg tylko przed tym, jak signalStatus zmieni się na „ready”, może wysłać pustą lub nieaktualną wartość.

Krok 6: Śledź ciąg w żądaniach reklam

Na koniec otwórz kartę Network i przefiltruj swoje żądania reklam. Wiele endpointów reklamowych przyjmuje parametry gpp i gpp_sid (ciąg i identyfikatory właściwych sekcji). Sprawdź, czy:

1. oba parametry występują w żądaniach od odwiedzających z USA;
2. ciąg zgadza się z tym, który zwrócił ping w chwili żądania;
3. po rezygnacji kolejne żądania niosą nowy ciąg, a nie zbuforowany.

Jeśli używasz Prebid.js, upewnij się, że jego moduł zarządzania zgodą jest skonfigurowany pod GPP, i sprawdź bid requesty opuszczające wrapper oraz końcowe wywołanie ad servera.

Typowe wzorce awarii

• Stub ładuje się po tagach reklamowych — partnerzy w ogóle nie widzą CMP.
• Zła sekcja dla regionu — sekcja UE wysyłana dla ruchu z USA albo brak sekcji.
• Interfejs i sygnał rozsynchronizowane — przełącznik się zmienia, ciąg nie.
• GPC ignorowane — sygnał przeglądarki nigdy nie staje się rezygnacją.
• Nieaktualne ciągi w żądaniach — wrapper buforuje pierwszą zobaczoną wartość.

Najważniejsze wnioski

• Zacznij od ping: wersja, status, właściwe sekcje i ciąg mówią większość.
• Użyj getSection, by odczytać pola rezygnacji; 1 oznacza rezygnację, 2 brak rezygnacji.
• Przetestuj osobno link rezygnacji i GPC oraz potwierdź, że oba zmieniają sygnał.
• Nasłuchuj zdarzeń i czekaj na sygnał „ready”, zanim żądania reklam odczytają ciąg.
• Zweryfikuj gpp i gpp_sid w prawdziwych żądaniach sieciowych, przed rezygnacją i po niej.