De ce sunt greu de observat problemele GPP

Când un vizitator din SUA renunță la vânzarea sau partajarea datelor sale, această alegere trebuie să ajungă la fiecare partener publicitar de pe pagină. Cu IAB Global Privacy Platform (GPP), ea călătorește sub forma unui șir compact și a unei liste de ID-uri de secțiune. Dacă oricare dintre ele este greșită — lipsește, este învechită sau poartă secțiunea nepotrivită — nu se strică nimic vizibil. Anunțurile se încarcă în continuare, bannerul arată bine, iar problema apare abia mai târziu, când partenerii ignoră renunțările sau licitează mai puțin pentru inventarul tău.

Vestea bună este că aproape totul poate fi inspectat din consola browserului. Acest tutorial parcurge verificările în ordinea în care le-am face pe o pagină live.

Pasul 1: confirmă că API-ul există și este gata

Un CMP compatibil GPP expune o funcție globală __gpp. Deschide DevTools pe pagina ta și rulează o comandă ping:

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

Obiectul returnat îți spune multe dintr-o privire:

• gppVersion — ar trebui să fie 1.1 în implementările actuale.
• cmpStatus — dacă CMP s-a încărcat sau a întâmpinat o eroare.
• cmpDisplayStatus — dacă bannerul este vizibil, ascuns sau dezactivat pentru acest vizitator.
• signalStatus — “ready” după ce CMP s-a stabilit asupra unei stări de consimțământ, “not ready” cât timp încă decide.
• supportedAPIs — secțiunile pe care CMP le poate produce.
• applicableSections — ID-urile de secțiune care se aplică acum acestui vizitator.
• gppString — șirul codificat propriu-zis.

Dacă __gpp este undefined, stub-ul CMP lipsește sau se încarcă prea târziu. Stub-ul trebuie să fie la locul lui înaintea oricărui script de anunțuri care îl așteaptă; altfel, acele scripturi nu vor vedea niciun CMP și fie vor aștepta, fie vor continua fără semnal.

Pasul 2: verifică secțiunea aplicabilă

Fiecare cadru de confidențialitate din GPP are un ID de secțiune numeric. Cele pe care editorii le întâlnesc cel mai des sunt 2 (EU TCF v2), 5 (TCF canadian), 7 (US National, “usnat”) și 8 în sus pentru secțiunile statelor individuale, precum California, Virginia, Colorado, Utah și Connecticut. Un vizitator dintr-un stat american ar trebui să vadă în mod normal în applicableSections fie secțiunea națională, fie secțiunea statului respectiv, nu secțiunea UE.

Testează din mai multe locații. O eroare frecventă este un CMP care detectează corect geografia pentru banner, dar scrie în șir o secțiune implicită indiferent de caz, sau invers. Cu un VPN sau cu instrumentele de previzualizare ale CMP-ului tău, compară ce arată bannerul cu ce raportează applicableSections.

Pasul 3: citește datele secțiunii

În loc să decodezi șirul manual, cere CMP-ului secțiunea analizată:

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

În secțiunea US National, câmpurile de renunțare folosesc o convenție simplă: 0 înseamnă neaplicabil, 1 înseamnă că utilizatorul a renunțat, iar 2 înseamnă că utilizatorul nu a renunțat. Concentrează-te mai întâi pe aceste câmpuri:

• SaleOptOut și SharingOptOut
• TargetedAdvertisingOptOut
• Câmpurile de notificare corespunzătoare, care înregistrează dacă vizitatorului i s-a oferit notificare pentru fiecare practică

Acum efectuează renunțarea pe pagină — fă clic pe linkul tău “Do Not Sell or Share” sau comută setarea din centrul de preferințe — și rulează din nou getSection. Câmpurile de renunțare ar trebui să treacă de la 2 la 1. Dacă nu o fac, interfața și semnalul nu sunt sincronizate.

Pasul 4: testează traseul Global Privacy Control

Mai multe legi statale cer ca întreprinderile să trateze un semnal Global Privacy Control drept renunțare. Activează GPC într-un browser sau o extensie care îl suportă, confirmă că navigator.globalPrivacyControl returnează true în consolă, apoi încarcă pagina într-o sesiune nouă. Câmpurile de renunțare relevante ar trebui să indice deja 1 fără ca vizitatorul să atingă bannerul. Unele secțiuni includ și un câmp care arată că alegerea provine dintr-un semnal GPC.

Pasul 5: urmărește evenimentele, nu doar instantaneele

Scripturile de anunțuri nu ar trebui să citească șirul o singură dată la încărcarea paginii și să îl uite. Înregistrează un listener ca să vezi ce văd partenerii:

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

Ar trebui să observi evenimente precum listenerRegistered, signalStatus și sectionChange. Când vizitatorul își schimbă o alegere, ar trebui să urmeze un eveniment sectionChange cu un șir actualizat. Dacă wrapper-ul tău de header bidding sau integrarea cu ad server-ul citește șirul doar înainte ca signalStatus să devină “ready”, poate trimite o valoare goală sau depășită.

Pasul 6: urmărește șirul în cererile de anunțuri

În sfârșit, deschide fila Network și filtrează cererile tale de anunțuri. Multe endpoint-uri de anunțuri acceptă parametrii gpp și gpp_sid (șirul și ID-urile secțiunilor aplicabile). Verifică dacă:

1. ambii parametri sunt prezenți în cererile vizitatorilor din SUA;
2. șirul coincide cu cel returnat de ping în momentul cererii;
3. după o renunțare, cererile ulterioare poartă șirul nou și nu unul din cache.

Dacă folosești Prebid.js, confirmă că modulul său de gestionare a consimțământului este configurat pentru GPP și inspectează cererile de ofertă care pleacă din wrapper, precum și apelul final către ad server.

Tipare frecvente de defecțiuni

• Stub-ul se încarcă după tag-urile de anunțuri — partenerii nu văd deloc un CMP.
• Secțiune greșită pentru regiune — secțiunea UE trimisă pentru traficul din SUA, sau nicio secțiune.
• Interfață și semnal nesincronizate — comutatorul se schimbă, șirul nu.
• GPC ignorat — semnalul browserului nu devine niciodată o renunțare.
• Șiruri învechite în cereri — wrapper-ul păstrează în cache prima valoare văzută.

Concluzii

• Începe cu ping: versiunea, starea, secțiunile aplicabile și șirul îți spun cea mai mare parte a poveștii.
• Folosește getSection pentru a citi câmpurile de renunțare; 1 înseamnă că a renunțat, 2 că nu a renunțat.
• Testează separat linkul de renunțare și GPC și confirmă că ambele schimbă semnalul.
• Ascultă evenimentele și așteaptă un semnal “ready” înainte ca cererile de anunțuri să citească șirul.
• Verifică gpp și gpp_sid în cereri de rețea reale, înainte și după o renunțare.