Proč se problémy s GPP špatně odhalují

Když se americký návštěvník odhlásí z prodeje nebo sdílení svých údajů, musí se tato volba dostat ke každému reklamnímu partnerovi na stránce. U IAB Global Privacy Platform (GPP) putuje jako kompaktní řetězec a seznam ID sekcí. Pokud je cokoli z toho špatně — chybí, je zastaralé nebo nese nesprávnou sekci — nic se viditelně nerozbije. Reklamy se dál načítají, banner pořád vypadá v pořádku a problém se projeví až později tím, že partneři ignorují odhlášení nebo nabízejí za váš inventář méně.

Dobrá zpráva je, že téměř vše můžete zkontrolovat z konzole prohlížeče. Tento tutoriál prochází kontroly v pořadí, v jakém bychom je provedli na živé stránce.

Krok 1: Ověřte, že API existuje a je připravené

CMP kompatibilní s GPP vystavuje globální funkci __gpp. Otevřete na své stránce DevTools a spusťte příkaz ping:

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

Vrácený objekt toho na první pohled řekne hodně:

• gppVersion — u současných implementací by mělo být 1.1.
• cmpStatus — zda se CMP načetl, nebo narazil na chybu.
• cmpDisplayStatus — zda je banner pro tohoto návštěvníka viditelný, skrytý, nebo zakázaný.
• signalStatus — “ready”, jakmile se CMP ustálil na stavu souhlasu, “not ready”, dokud se ještě rozhoduje.
• supportedAPIs — sekce, které CMP umí vytvořit.
• applicableSections — ID sekcí, které se právě na tohoto návštěvníka vztahují.
• gppString — samotný zakódovaný řetězec.

Pokud je __gpp nedefinované, CMP stub chybí nebo se načítá příliš pozdě. Stub musí být na místě před každým reklamním skriptem, který ho očekává, jinak tyto skripty neuvidí žádné CMP a buď počkají, nebo pokračují bez signálu.

Krok 2: Zkontrolujte platnou sekci

Každý rámec ochrany soukromí má v GPP číselné ID sekce. Ty, se kterými se vydavatelé setkávají nejčastěji, jsou 2 (EU TCF v2), 5 (kanadský TCF), 7 (US National, “usnat”) a 8 a výš pro sekce jednotlivých států, například Kalifornie, Virginie, Colorado, Utah a Connecticut. Návštěvník z amerického státu by měl v applicableSections normálně vidět národní nebo příslušnou státní sekci, ne sekci EU.

Testujte z několika lokalit. Častou chybou je CMP, který pro banner geografii zjistí správně, ale do řetězce zapíše výchozí sekci bez ohledu na ni, nebo naopak. Pomocí VPN nebo náhledových nástrojů vašeho CMP porovnejte, co banner zobrazuje, s tím, co hlásí applicableSections.

Krok 3: Přečtěte data sekce

Místo ručního dekódování řetězce požádejte CMP o rozparsovanou sekci:

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

V sekci US National používají pole odhlášení jednoduchou konvenci: 0 znamená nepoužitelné, 1 znamená, že se uživatel odhlásil, a 2 znamená, že se uživatel neodhlásil. Zaměřte se nejprve na tato pole:

• SaleOptOut a SharingOptOut
• TargetedAdvertisingOptOut
• Odpovídající pole notice, která zaznamenávají, zda byl návštěvník o dané praxi informován

Teď na stránce proveďte odhlášení — klikněte na odkaz “Do Not Sell or Share” nebo přepněte volbu v centru předvoleb — a spusťte getSection znovu. Pole odhlášení by se měla změnit z 2 na 1. Pokud ne, uživatelské rozhraní a signál nejsou synchronizované.

Krok 4: Otestujte cestu Global Privacy Control

Několik státních zákonů vyžaduje, aby podniky braly signál Global Privacy Control jako odhlášení. Zapněte GPC v prohlížeči nebo rozšíření, které ho podporuje, ověřte, že navigator.globalPrivacyControl v konzoli vrací true, a pak načtěte stránku v nové relaci. Příslušná pole odhlášení by už měla ukazovat 1, aniž by se návštěvník banneru dotkl. Některé sekce obsahují i pole značící, že volba pochází ze signálu GPC.

Krok 5: Sledujte události, nejen momentky

Reklamní skripty by neměly řetězec přečíst jednou při načtení stránky a zapomenout na něj. Zaregistrujte listener a uvidíte, co vidí partneři:

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

Měli byste vidět události jako listenerRegistered, signalStatus a sectionChange. Když návštěvník změní volbu, měla by následovat událost sectionChange s aktualizovaným řetězcem. Pokud váš header bidding wrapper nebo integrace ad serveru čte řetězec jen předtím, než signalStatus přejde na “ready”, může odeslat prázdnou nebo zastaralou hodnotu.

Krok 6: Sledujte řetězec do reklamních požadavků

Nakonec otevřete kartu Network a vyfiltrujte své reklamní požadavky. Mnoho reklamních endpointů přijímá parametry gpp a gpp_sid (řetězec a platná ID sekcí). Zkontrolujte, že:

1. oba parametry jsou přítomné v požadavcích amerických návštěvníků;
2. řetězec odpovídá tomu, který v okamžiku požadavku vrací ping;
3. po odhlášení nesou další požadavky nový řetězec, ne uložený z mezipaměti.

Pokud používáte Prebid.js, ověřte, že jeho modul pro správu souhlasu je nakonfigurován pro GPP, a zkontrolujte bid requesty opouštějící wrapper i závěrečné volání ad serveru.

Typické vzorce selhání

• Stub se načte po reklamních tagů — partneři CMP vůbec nevidí.
• Špatná sekce pro region — sekce EU odeslaná pro americký provoz, nebo žádná sekce.
• UI a signál nejsou synchronizované — přepínač se změní, řetězec ne.
• GPC ignorován — signál prohlížeče se nikdy nestane odhlášením.
• Zastaralé řetězce v požadavcích — wrapper ukládá do mezipaměti první hodnotu, kterou viděl.

Klíčové poznatky

• Začněte s ping: verze, stav, platné sekce a řetězec prozradí většinu příběhu.
• K čtení polí odhlášení použijte getSection; 1 znamená odhlášen, 2 znamená neodhlášen.
• Odkaz pro odhlášení a GPC testujte zvlášť a ověřte, že oba mění signál.
• Poslouchejte události a počkejte na signál “ready”, než reklamní požadavky řetězec přečtou.
• Ověřte gpp a gpp_sid ve skutečných síťových požadavcích, před odhlášením i po něm.