Por que Prebid.js necesita un módulo de xestión do consentimento

Cando se executa unha subhasta de Prebid.js, o envoltorio fai solicitudes paralelas a cada adaptador de licitador configurado. Cada adaptador debe incluír a cadea de consentimento do usuario na súa solicitude de oferta — tcfeu (TCF v2.2 para a UE/UK), usp (CCPA/CPRA), e cada vez máis gpp (a cadea IAB Global Privacy Platform que abarca múltiples estados dos EUA). Sen estes sinais, os SSP e DSP posteriores véñense obrigados a tratar ao usuario como que se negou, descartar a oferta por completo ou — no peor caso — procesar datos ilegalmente.

O módulo de xestión do consentimento de Prebid sitúase entre o teu CMP e o pipeline de solicitude de oferta. Chama á API CMP estándar (__tcfapi, __uspapi, __gppapi), agarda por unha cadea de consentimento e logo inxéctaa automaticamente no payload de solicitude de oferta de cada adaptador. Tamén aplica un filtrado baseado en finalidades cando activas a aplicación do GDPR, bloqueando o acceso ao almacenamento e a execución dos licitadores para os usuarios que non outorgaron as finalidades TCF pertinentes.

Instalación e configuración do módulo principal

Prebid.js constrúese por editor desde docs.prebid.org/download.html. Cando xeras a túa compilación personalizada, tres módulos en «Xestión do consentimento» son importantes:

• consentManagementTcf — xestiona as cadeas TCF v2.2 para o tráfico da UE, UK e Suíza.
• consentManagementUsp — xestiona a antiga cadea US Privacy CCPA/CPRA (aínda requirida por moitos DSP).
• consentManagementGpp — xestiona a cadea IAB GPP, o estándar orientado ao futuro que agora esixen Google, TTD e os principais SSP.

Inclúe os tres se serves tráfico global. Unha vez que a compilación estea no teu CDN, configura os módulos no teu script de configuración de Prebid:

Configuración TCF v2.2

O bloque TCF indica a Prebid que API CMP chamar, canto tempo agardar por unha cadea, e que facer en caso de tempo de espera excedido. Unha configuración de produción típica establece cmpApi: 'iab', timeout: 8000 (8 segundos — suficientemente longo para unha carga lenta de banner CMP) e defaultGdprScope: true para que os usuarios de xurisdicións descoñecidas sexan tratados como dentro do ámbito até que se demostre o contrario. Establecer actionTimeout por separado controla canto tempo espera Prebid cando o usuario aínda non interactuou co banner — mantelo razoable evita un espazo publicitario baleiro se un visitante ignora o banner.

US Privacy e GPP

O USP é sinxelo: activa o módulo e Prebid le a cadea de catro caracteres desde __uspapi. O GPP é máis matizado porque a cadea GPP pode conter múltiples IDs de sección (TCF EU, US National, US California, US Colorado, US Virginia, etc.). Prebid reenvía automaticamente a cadea completa, pero os licitadores inspeccionan seccións específicas. Asegúrate de que o teu CMP emite as seccións GPP correctas para a xurisdición de cada usuario — un CMP mal configurado que emite só a sección US National a un usuario de California provocará que os DSP compatibles con CPRA descarten a oferta.

Activación da aplicación do GDPR (filtrado baseado en finalidades)

Por defecto, o módulo de consentimento pasa a cadea TCF pero non bloquea nada. Para que Prebid aplique realmente as finalidades TCF, activa o conxunto de regras gdprEnforcement. Aquí é onde ocorren a maioría dos erros de configuración — e onde reside a diferenza entre un stack de header bidding conforme e non conforme.

O conxunto de regras estándar bloquea catro actividades cando a finalidade pertinente carece de consentimento:

• storage — condicionado á Finalidade 1 (almacenamento e acceso). Cando se denega, Prebid impide que os licitadores lean ou escriban cookies e localStorage.
• basicAds — condicionado á Finalidade 2 (anuncios básicos). Cando se denega, o licitador queda excluído da subhasta por completo.
• measurement — condicionado á Finalidade 7. Afecta aos adaptadores de análise.
• transmitPreciseGeo — condicionado á Función Especial 1. Cando se denega, Prebid elimina a xeolocalización precisa das solicitudes de oferta.

Para cada regra estableces enforcePurpose: true, enforceVendor: true e unha lista de vendorExceptions. A lista de excepcións de provedores é crítica: calquera licitador que inclúas nela pode participar mesmo sen consentimento explícito de provedor TCF, baixo o argumento de que tes unha base xurídica separada (p. ex., interese lexítimo combinado cun fluxo contractual). Usa isto con moderación — as excepcións demasiado amplas son exactamente o patrón polo que os reguladores comezaron a multar aos editores.

Erros comúns que custan ingresos ou cumprimento aos editores

Tempo de espera demasiado baixo

Se o timeout é máis curto que o tempo de renderizado do banner do teu CMP, Prebid avanza sen cadea de consentimento. Os licitadores tratan iso como non-consentimento e descartan a oferta. Mide a latencia da primeira chamada tcfapi('addEventListener') do teu CMP no percentil 95 e establece o tempo de espera de Prebid por encima diso. 8000 ms é un valor predeterminado seguro; 3000 ms é arriscado se serves mercados onde os banners tardan en localizarse.

Integración GPP ausente no tráfico dos EUA

Os principais SSP e DSP (Google AdX, TTD, Magnite, PubMatic) agora requiren a cadea GPP para a aplicación da negativa nos EUA. Se só emites a cadea USP legada, estes DSP degradarán ou omitirán cada vez máis o teu inventario. Audita as túas respostas de oferta: unha caída brusca do CPM no tráfico dos EUA en 2026 é a miúdo un sinal GPP ausente.

Cadeas de consentimento obsoletas na navegación SPA

As aplicacións de páxina única que reactiván as subhastas de Prebid nos cambios de ruta deben chamar a pbjs.refreshUserIds() e asegurarse de que se obtén a última cadea TCF. Unha cadea en caché de 30 minutos pode conter as preferencias do usuario anterior se o teu sitio usa sesións compartidas.

vendorExceptions ausentes para a análise

Os editores adoitan esquecer que os adaptadores de Prebid Analytics (Google Analytics, informes do lado do servidor) tamén están suxeitos ao filtrado measurement baixo a Finalidade 7 do TCF. Se dependes deles para os informes de ingresos, inclúeos explicitamente baixo as excepcións de provedor da regra de medición, ou acepta a lagoa de datos no tráfico sen consentimento.

Probando a túa configuración antes de produción

Prebid.js expón pbjs.getConfig('consentManagement') na consola do navegador. Verifica que a configuración activa coincide coa túa intención. Logo usa a extensión Chrome Prebid.js Professor ou pbjs.getEvents() para inspeccionar a cadea de consentimento engadida a cada solicitude de oferta. Verifica tres escenarios: un usuario totalmente consentido, un usuario que fixo clic en «Rexeitar todo» e un usuario que descartou o banner sen interactuar. Cada un debería producir un comportamento observable diferente no payload da solicitude de oferta.

Executa as mesmas comprobacións en distintas xeografías usando unha VPN ou o indicador de anulación de xeolocalización do teu CMP. O tráfico da UE debería producir unha cadea TCF e activar gdprEnforcement; o tráfico de California debería producir unha cadea USP e GPP; o tráfico de xurisdición descoñecida debería respectar a túa configuración de defaultGdprScope.

Resumindo

Un stack de xestión do consentimento de Prebid correctamente configurado fai tres cousas á vez: mantén os teus licitadores abastecidos con sinais de consentimento válidos (preservando os CPM), aplica as regras TCF e de negativa dos EUA a nivel do envoltorio (reducindo a exposición regulatoria) e proporciónache un único punto de auditoría cando un regulador pregunta como a túa configuración de header bidding respecta a elección do usuario. Tómate o tempo necesario para establecer os tempos de espera de forma deliberada, activa o GPP xunto co USP para o tráfico dos EUA e revisa a túa lista de vendorExceptions trimestralmente — o custo de equivocarse nisto mídese tanto en multas como en ingresos programáticos perdidos.