Por que os problemas de GPP son difíciles de detectar

Cando un visitante dos EUA decide non permitir a venda ou a compartición dos seus datos, esa elección ten que chegar a todos os socios publicitarios da páxina. Co IAB Global Privacy Platform (GPP), viaxa como unha cadea compacta e unha lista de identificadores de sección. Se calquera dos dous é incorrecto — falta, está desactualizado ou leva a sección equivocada — non se rompe nada de forma visible. Os anuncios cargan igual, o banner ten bo aspecto, e o problema só aparece máis tarde, cando os socios ignoran as exclusións ou ofertan menos polo teu inventario.

A boa nova é que case todo se pode inspeccionar desde a consola do navegador. Este titorial percorre as comprobacións na orde en que as faríamos nunha páxina en produción.

Paso 1: confirma que a API existe e está lista

Un CMP compatible con GPP expón unha función global __gpp. Abre DevTools na túa páxina e executa unha orde ping:

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

O obxecto devolto cóntache moito dunha ollada:

• gppVersion — debería ser 1.1 nas implementacións actuais.
• cmpStatus — se o CMP se cargou ou atopou un erro.
• cmpDisplayStatus — se o banner está visible, oculto ou desactivado para este visitante.
• signalStatus — “ready” cando o CMP se decidiu por un estado de consentimento, “not ready” mentres aínda o está decidindo.
• supportedAPIs — as seccións que o CMP pode producir.
• applicableSections — os identificadores de sección que se aplican agora mesmo a este visitante.
• gppString — a propia cadea codificada.

Se __gpp é undefined, o stub do CMP non está ou cárgase demasiado tarde. O stub debe estar no seu sitio antes de calquera script de anuncios que o espere; se non, eses scripts non verán ningún CMP e esperarán ou seguirán sen sinal.

Paso 2: comproba a sección aplicable

Cada marco de privacidade de GPP ten un identificador de sección numérico. Os que os editores atopan con máis frecuencia son o 2 (EU TCF v2), o 5 (TCF canadense), o 7 (US National, “usnat”) e o 8 en diante para as seccións de estados concretos, como California, Virxinia, Colorado, Utah e Connecticut. Un visitante dun estado dos EUA debería ver normalmente a sección nacional ou a sección estatal correspondente en applicableSections, non a sección da UE.

Proba desde varias localizacións. Un erro habitual é un CMP que detecta ben a xeografía para o banner pero escribe na cadea unha sección por defecto sexa cal sexa o caso, ou ao revés. Cunha VPN ou coas ferramentas de vista previa do teu CMP, compara o que mostra o banner co que informa applicableSections.

Paso 3: le os datos da sección

En lugar de decodificar a cadea a man, pídelle ao CMP a sección analizada:

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

Na sección US National, os campos de exclusión usan unha convención sinxela: 0 significa non aplicable, 1 significa que o usuario se excluíu e 2 significa que o usuario non se excluíu. Fíxate primeiro nestes campos:

• SaleOptOut e SharingOptOut
• TargetedAdvertisingOptOut
• Os campos de aviso correspondentes, que rexistran se ao visitante se lle deu aviso de cada práctica

Agora fai a exclusión na páxina — fai clic na túa ligazón “Do Not Sell or Share” ou cambia o axuste no centro de preferencias — e executa getSection de novo. Os campos de exclusión deberían pasar de 2 a 1. Se non o fan, a interface e o sinal non están sincronizados.

Paso 4: proba o camiño de Global Privacy Control

Varias leis estatais esixen que as empresas traten un sinal Global Privacy Control como unha exclusión. Activa o GPC nun navegador ou extensión que o admita, confirma que navigator.globalPrivacyControl devolve true na consola e despois carga a páxina nunha sesión nova. Os campos de exclusión correspondentes deberían marcar xa 1 sen que o visitante toque o banner. Algunhas seccións tamén inclúen un campo que indica que a elección procede dun sinal GPC.

Paso 5: observa os eventos, non só as instantáneas

Os scripts de anuncios non deberían ler a cadea unha soa vez ao cargar a páxina e esquecela. Rexistra un listener para ver o que ven os socios:

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

Deberías observar eventos como listenerRegistered, signalStatus e sectionChange. Cando o visitante cambia unha elección, debe seguir un evento sectionChange cunha cadea actualizada. Se o teu wrapper de header bidding ou a integración do servidor de anuncios só le a cadea antes de que signalStatus pase a “ready”, pode enviar un valor baleiro ou desactualizado.

Paso 6: segue a cadea ata as solicitudes de anuncios

Por último, abre a lapela Network e filtra as túas solicitudes de anuncios. Moitos puntos finais de anuncios aceptan os parámetros gpp e gpp_sid (a cadea e os identificadores de sección aplicables). Comproba que:

1. os dous parámetros están presentes nas solicitudes dos visitantes dos EUA;
2. a cadea coincide coa devolta por ping no momento da solicitude;
3. despois dunha exclusión, as solicitudes posteriores levan a cadea nova e non unha gardada na caché.

Se usas Prebid.js, confirma que o seu módulo de xestión do consentimento está configurado para GPP, e inspecciona as solicitudes de oferta (bid requests) que saen do wrapper e tamén a chamada final ao servidor de anuncios.

Patróns de fallo habituais

• O stub cárgase despois das etiquetas de anuncios — os socios non ven ningún CMP.
• Sección equivocada para a rexión — envíase a sección da UE para tráfico dos EUA, ou ningunha sección.
• Interface e sinal sen sincronizar — o interruptor cambia, a cadea non.
• GPC ignorado — o sinal do navegador nunca se converte nunha exclusión.
• Cadeas desactualizadas nas solicitudes — o wrapper garda na caché o primeiro valor que viu.

Puntos clave

• Comeza con ping: a versión, o estado, as seccións aplicables e a cadea cóntanche a maior parte da historia.
• Usa getSection para ler os campos de exclusión; 1 significa que se excluíu, 2 que non.
• Proba por separado a ligazón de exclusión e o GPC, e confirma que ambos cambian o sinal.
• Escoita eventos e agarda un sinal “ready” antes de que as solicitudes de anuncios lean a cadea.
• Verifica gpp e gpp_sid en solicitudes de rede reais, antes e despois dunha exclusión.