Zakaj je težave z GPP težko opaziti

Ko se ameriški obiskovalec odjavi od prodaje ali deljenja svojih podatkov, mora ta izbira doseči vsakega oglaševalskega partnerja na strani. Pri IAB Global Privacy Platform (GPP) potuje kot kompakten niz in seznam ID-jev razdelkov. Če je karkoli od tega napačno — manjka, je zastarelo ali nosi napačen razdelek — se nič vidno ne pokvari. Oglasi se še naprej nalagajo, pasica še vedno izgleda urejeno, težava pa se pokaže šele pozneje, ko partnerji prezrejo odjave ali ponudijo manj za vaš inventar.

Dobra novica je, da lahko skoraj vse pregledate iz konzole brskalnika. Ta vodnik vas vodi skozi preverjanja v vrstnem redu, v katerem bi jih izvedli na živi strani.

1. korak: potrdite, da API obstaja in je pripravljen

CMP, združljiv z GPP, izpostavi globalno funkcijo __gpp. Odprite DevTools na svoji strani in zaženite ukaz ping:

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

Vrnjeni objekt na prvi pogled pove veliko:

• gppVersion — pri sedanjih implementacijah naj bo 1.1.
• cmpStatus — ali se je CMP naložil ali je naletel na napako.
• cmpDisplayStatus — ali je pasica za tega obiskovalca vidna, skrita ali onemogočena.
• signalStatus — “ready”, ko se je CMP odločil za stanje privolitve, “not ready”, medtem ko se še odloča.
• supportedAPIs — razdelki, ki jih CMP lahko ustvari.
• applicableSections — ID-ji razdelkov, ki se trenutno uporabljajo za tega obiskovalca.
• gppString — sam kodirani niz.

Če je __gpp nedefiniran, CMP stub manjka ali se nalaga prepozno. Stub mora biti na mestu pred vsako oglasno skripto, ki ga pričakuje, sicer te skripte ne bodo videle nobenega CMP-ja in bodo ali čakale ali nadaljevale brez signala.

2. korak: preverite veljavni razdelek

Vsak okvir zasebnosti v GPP ima številčni ID razdelka. Tisti, ki jih založniki srečujejo najpogosteje, so 2 (EU TCF v2), 5 (kanadski TCF), 7 (US National, “usnat”) in 8 naprej za razdelke posameznih držav, kot so Kalifornija, Virginija, Kolorado, Utah in Connecticut. Obiskovalec iz ameriške zvezne države bi moral v applicableSections običajno videti nacionalni ali ustrezni državni razdelek, ne pa razdelka EU.

Preizkusite z več lokacij. Pogosta napaka je CMP, ki za pasico pravilno zazna geografijo, v niz pa ne glede na to zapiše privzeti razdelek, ali obratno. S VPN-jem ali orodji za predogled vašega CMP-ja primerjajte, kaj prikazuje pasica, s tem, kar javlja applicableSections.

3. korak: preberite podatke razdelka

Namesto da niz dekodirate ročno, od CMP-ja zahtevajte razčlenjen razdelek:

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

V razdelku US National polja odjave uporabljajo preprosto konvencijo: 0 pomeni, da se ne uporablja, 1 pomeni, da se je uporabnik odjavil, 2 pa pomeni, da se uporabnik ni odjavil. Najprej se osredotočite na ta polja:

• SaleOptOut in SharingOptOut
• TargetedAdvertisingOptOut
• Ustrezna polja notice, ki beležijo, ali je bil obiskovalec obveščen o posamezni praksi

Zdaj na strani izvedite odjavo — kliknite povezavo “Do Not Sell or Share” ali preklopite nastavitev v centru nastavitev — in znova zaženite getSection. Polja odjave se morajo spremeniti z 2 na 1. Če se ne, uporabniški vmesnik in signal nista usklajena.

4. korak: preizkusite pot Global Privacy Control

Več državnih zakonov zahteva, da podjetja signal Global Privacy Control obravnavajo kot odjavo. Vklopite GPC v brskalniku ali razširitvi, ki ga podpira, potrdite, da navigator.globalPrivacyControl v konzoli vrne true, nato naložite stran v novi seji. Ustrezna polja odjave bi že morala kazati 1, ne da bi se obiskovalec dotaknil pasice. Nekateri razdelki vsebujejo tudi polje, ki kaže, da izbira izvira iz signala GPC.

5. korak: spremljajte dogodke, ne le posnetkov stanja

Oglasne skripte ne bi smele niza prebrati enkrat ob nalaganju strani in ga pozabiti. Registrirajte listener, da vidite, kaj vidijo partnerji:

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

Opaziti bi morali dogodke, kot so listenerRegistered, signalStatus in sectionChange. Ko obiskovalec spremeni izbiro, mora slediti dogodek sectionChange s posodobljenim nizom. Če vaš header bidding wrapper ali integracija oglasnega strežnika bere niz samo preden signalStatus postane “ready”, lahko pošlje prazno ali zastarelo vrednost.

6. korak: sledite nizu do oglasnih zahtev

Nazadnje odprite zavihek Network in filtrirajte svoje oglasne zahteve. Številne oglasne končne točke sprejemajo parametra gpp in gpp_sid (niz in veljavne ID-je razdelkov). Preverite, da:

1. sta oba parametra prisotna v zahtevah ameriških obiskovalcev;
2. se niz ujema s tistim, ki ga ob času zahteve vrne ping;
3. po odjavi naslednje zahteve nosijo nov niz, ne pa predpomnjenega.

Če uporabljate Prebid.js, potrdite, da je njegov modul za upravljanje privolitve konfiguriran za GPP, ter preglejte zahteve za ponudbe, ki zapuščajo wrapper, in končni klic oglasnega strežnika.

Pogosti vzorci napak

• Stub se naloži za oglasnimi oznakami — partnerji sploh ne vidijo CMP-ja.
• Napačen razdelek za regijo — razdelek EU poslan za ameriški promet ali noben razdelek.
• Uporabniški vmesnik in signal nista usklajena — stikalo se spremeni, niz ne.
• GPC prezrt — signal brskalnika nikoli ne postane odjava.
• Zastareli nizi v zahtevah — wrapper predpomni prvo vrednost, ki jo je videl.

Ključne ugotovitve

• Začnite s ping: različica, stanje, veljavni razdelki in niz povedo večino zgodbe.
• Za branje polj odjave uporabite getSection; 1 pomeni odjavljen, 2 pomeni ni odjavljen.
• Povezavo za odjavo in GPC preizkusite ločeno ter potrdite, da oba spremenita signal.
• Poslušajte dogodke in počakajte na signal “ready”, preden oglasne zahteve preberejo niz.
• Preverite gpp in gpp_sid v resničnih omrežnih zahtevah, pred odjavo in po njej.