El problema del doble banner

Muchas apps son en parte nativas y en parte web. Un juego muestra su tienda, sus noticias o sus páginas de ayuda en un WebView; una app de utilidades muestra artículos de su sitio web; una app híbrida envuelve la mayor parte de su interfaz en contenido web. Cada lado tiene su propio mecanismo de consentimiento: la app nativa usa un CMP o SDK integrado, y las páginas web cargan un CMP web. Si no están conectados, se pregunta al usuario dos veces, las elecciones hechas en un lugar se ignoran en el otro, y las solicitudes de anuncios desde el WebView salen con las señales equivocadas.

Esta guía explica cómo hacer que el consentimiento nativo y el web coincidan, de modo que los usuarios respondan una sola vez y cada solicitud de anuncio lleve la misma decisión.

Dónde guarda el consentimiento cada lado

Nativo

El IAB TCF especifica cómo almacena el consentimiento un CMP dentro de la app: en NSUserDefaults en iOS y en SharedPreferences en Android, usando claves estándar como IABTCF_TCString, IABTCF_gdprApplies e IABTCF_PurposeConsents. Los SDK publicitarios leen estas claves directamente. El IAB GPP define claves similares con el prefijo IABGPP_, como IABGPP_HDR_GppString.

Web

Un CMP web suele almacenar su decisión en cookies de origen propio o en el almacenamiento local del dominio del sitio, y la expone mediante las funciones JavaScript __tcfapi y __gpp. Las etiquetas publicitarias de la página llaman a esas funciones, no al almacenamiento nativo.

La brecha

Los WebViews tienen su propio espacio de cookies y almacenamiento, separado del navegador del dispositivo y de las preferencias nativas de la app. En iOS, un WKWebView que usa un almacén de datos no persistente lo olvida todo al cerrarse. Nada fluye entre los dos lados a menos que lo construyas.

Elige una única fuente de verdad

La primera decisión es qué lado es dueño del consentimiento. Para la mayoría de las apps la respuesta es el CMP nativo, porque:

• Se ejecuta primero, antes de abrir cualquier WebView.
• Los SDK publicitarios nativos, que suelen generar la mayor parte de los ingresos, leen el almacenamiento nativo.
• En iOS, puede coordinarse con el aviso de App Tracking Transparency.

Priorizar la web puede tener sentido para las apps híbridas cuya interfaz entera es contenido web, pero entonces debes volver a escribir la decisión en el almacenamiento nativo para los SDK nativos.

Pasar el consentimiento nativo al WebView

Con lo nativo como fuente de verdad, el WebView necesita ver la misma decisión. Patrones habituales:

1. Inyectar una implementación de __tcfapi. Antes de que se ejecuten los scripts de la página, inyecta un pequeño script que defina __tcfapi (y __gpp si hace falta) y responda a las llamadas con la cadena TC y los valores leídos del almacenamiento nativo. Las etiquetas publicitarias de la página obtienen entonces la decisión nativa a través de la API estándar.
2. Suprimir el banner web. Configura el CMP web para que permanezca oculto cuando la página se cargue dentro de tu app, por ejemplo según un parámetro de consulta o un token de user agent personalizado que controles. De lo contrario, el usuario ve un segundo banner.
3. Pasar la cadena al cargar. Algunos CMP web pueden aceptar una cadena de consentimiento existente al inicializarse y adoptarla. Consulta la documentación de tu CMP web para ver los métodos admitidos.

Sea cual sea el patrón que uses, asegúrate de que los valores inyectados se actualicen cuando el usuario cambie su elección en la pantalla de ajustes nativa, y no solo en el siguiente inicio de la app.

Devolver el consentimiento web a lo nativo

Si los usuarios pueden cambiar el consentimiento dentro del WebView, por ejemplo mediante una página de ajustes de privacidad, la app debe enterarse. Usa un puente JavaScript: un controlador de mensajes en iOS o una interfaz JavaScript en Android. El lado web escucha con __tcfapi('addEventListener', ...) y envía la nueva cadena al código nativo, que escribe las claves estándar. Valida lo que llegue del WebView antes de escribirlo; acepta solo mensajes procedentes de tu propio contenido.

Anuncios dentro de los WebViews

Los anuncios mostrados en un WebView son anuncios web. Leen el consentimiento de la página, no del almacenamiento nativo, salvo que el SDK publicitario ofrezca una forma de vincular ambos. El Mobile Ads SDK de Google, por ejemplo, ofrece una API para registrar WebViews de modo que los anuncios dentro de ellos puedan usar señales de la app; consulta la documentación actual de tu SDK. En cualquier caso, confirma con una prueba que las solicitudes de anuncios desde el WebView llevan la misma cadena TC o GPP que las solicitudes de anuncios nativas.

Checklist de pruebas

• Instalación nueva: un solo aviso de consentimiento, no dos.
• Rechaza todo en el CMP nativo, abre un WebView e inspecciona las solicitudes de anuncios: la cadena debe reflejar el rechazo.
• Cambia el consentimiento en los ajustes nativos y vuelve a un WebView abierto: la página debe ver la nueva decisión.
• Si existen ajustes web, cambia allí el consentimiento y confirma que las claves nativas se actualizan.
• Cierra la app a la fuerza y vuelve a abrirla: las decisiones persisten en ambos lados.
• Prueba tanto en iOS como en Android, ya que el almacenamiento del WebView se comporta de forma distinta en cada uno.

Puntos clave

• El consentimiento nativo y el del WebView viven en almacenes separados y no se sincronizan por defecto.
• Elige una única fuente de verdad; en la mayoría de las apps es el CMP nativo.
• Expón el consentimiento nativo al contenido web mediante un __tcfapi o __gpp inyectado y oculta el banner web.
• Usa un puente JavaScript para devolver los cambios de la web al almacenamiento nativo.
• Comprueba que las solicitudes de anuncios desde los WebViews llevan la misma cadena de consentimiento que las nativas.