O problema do dobre banner

Moitas aplicacións son en parte nativas e en parte web. Un xogo amosa a tenda, as novas ou as páxinas de axuda nun WebView; unha aplicación de utilidades amosa artigos do seu sitio web; unha aplicación híbrida envolve a maior parte da súa interface en contido web. Cada banda ten o seu propio mecanismo de consentimento: a aplicación nativa usa un CMP ou SDK dentro da aplicación, e as páxinas web cargan un CMP web. Se non están conectados, pídeselle dúas veces ao usuario, as eleccións feitas nun lugar ignóranse no outro, e as solicitudes de anuncios desde dentro do WebView saen cos sinais equivocados.

Esta guía explica como facer que o consentimento nativo e o web coincidan, para que os usuarios respondan unha soa vez e cada solicitude de anuncio leve a mesma decisión.

Onde almacena o consentimento cada banda

Nativo

O IAB TCF especifica como almacena o consentimento un CMP dentro da aplicación: en NSUserDefaults en iOS e en SharedPreferences en Android, con claves estándar como IABTCF_TCString, IABTCF_gdprApplies e IABTCF_PurposeConsents. Os SDK de anuncios len estas claves directamente. O IAB GPP define claves similares co prefixo IABGPP_, como IABGPP_HDR_GppString.

Web

Un CMP web adoita almacenar a súa decisión en cookies propias ou no almacenamento local do dominio do sitio, e expóñea mediante as funcións JavaScript __tcfapi e __gpp. As etiquetas de anuncios da páxina chaman a estas funcións, non ao almacenamento nativo.

A fenda

Os WebViews teñen o seu propio espazo de cookies e de almacenamento, separado do navegador do dispositivo e separado das preferencias nativas da aplicación. En iOS, un WKWebView que usa un almacén de datos non persistente esquece todo ao pecharse. Nada flúe entre as dúas bandas a menos que o construías.

Elixe unha única fonte de verdade

A primeira decisión é que banda é propietaria do consentimento. Para a maioría das aplicacións a resposta é o CMP nativo, porque:

• Execútase primeiro, antes de que se abra ningún WebView.
• Os SDK de anuncios nativos, que adoitan xerar a maior parte dos ingresos, len o almacenamento nativo.
• En iOS, pódese coordinar coa solicitude de App Tracking Transparency.

Comezar pola web pode ter sentido para aplicacións híbridas cuxa interface completa é contido web, pero entón tes que escribir a decisión de volta no almacenamento nativo para os SDK nativos.

Pasar o consentimento nativo ao WebView

Co nativo como fonte de verdade, o WebView ten que ver a mesma decisión. Patróns habituais:

1. Inxectar unha implementación de __tcfapi. Antes de que se executen os scripts da páxina, inxecta un pequeno script que defina __tcfapi (e __gpp se fai falta) e responda as chamadas coa TC string e os valores lidos do almacenamento nativo. As etiquetas de anuncios da páxina obteñen entón a decisión nativa mediante a API estándar.
2. Suprimir o banner web. Configura o CMP web para que se manteña agochado cando a páxina se carga dentro da túa aplicación, por exemplo segundo un parámetro de consulta ou un testemuño de axente de usuario personalizado que controles. Se non, o usuario ve un segundo banner.
3. Pasar a cadea ao cargar. Algúns CMP web poden aceptar unha cadea de consentimento existente ao inicializarse e adoptala. Consulta a documentación do teu CMP web para ver os métodos admitidos.

Sexa cal for o patrón que uses, asegúrate de que os valores inxectados se actualicen cando o usuario cambie a súa elección na pantalla de configuración nativa, non só no seguinte inicio da aplicación.

Devolver o consentimento web ao nativo

Se os usuarios poden cambiar o consentimento dentro do WebView, por exemplo mediante unha páxina de configuración de privacidade, a aplicación ten que sabelo. Usa unha ponte JavaScript: un xestor de mensaxes en iOS ou unha interface JavaScript en Android. A banda web escoita con __tcfapi('addEventListener', ...) e envía a cadea nova ao código nativo, que escribe as claves estándar. Valida a entrada do WebView antes de escribila; acepta só mensaxes do teu propio contido.

Anuncios dentro dos WebViews

Os anuncios renderizados nun WebView son anuncios web. Len o consentimento da páxina, non do almacenamento nativo, salvo que o SDK de anuncios ofreza unha forma de vinculalos. O Mobile Ads SDK de Google, por exemplo, ofrece unha API para rexistrar WebViews de modo que os anuncios que hai dentro poidan usar sinais da aplicación; consulta a documentación actual do teu SDK. En calquera caso, confirma cunha proba que as solicitudes de anuncios desde o WebView levan a mesma TC string ou GPP string que as solicitudes nativas.

Lista de verificación de probas

• Instalación nova: unha soa petición de consentimento, non dúas.
• Rexeita todo no CMP nativo, abre un WebView, inspecciona as solicitudes de anuncios: a cadea debe reflectir o rexeitamento.
• Cambia o consentimento na configuración nativa, volve a un WebView aberto: a páxina debe ver a decisión nova.
• Se existe unha configuración web, cambia aí o consentimento e confirma que as claves nativas se actualizan.
• Pecha a aplicación de maneira forzada e volve lanzala: as decisións persisten nas dúas bandas.
• Proba tanto en iOS como en Android, xa que o almacenamento dos WebViews compórtase de maneira distinta en cada un.

Ideas clave

• O consentimento nativo e o do WebView viven en almacéns separados e non se sincronizan por defecto.
• Elixe unha única fonte de verdade; para a maioría das aplicacións é o CMP nativo.
• Expón o consentimento nativo ao contido web mediante un __tcfapi ou __gpp inxectado e agocha o banner web.
• Usa unha ponte JavaScript para enviar os cambios web de volta ao almacenamento nativo.
• Comproba que as solicitudes de anuncios desde os WebViews levan a mesma cadea de consentimento que as nativas.