Combinar contenido nativo y web en una aplicación
En muchos casos, una aplicación móvil consta de una parte nativa (p. ej., escrita en Java, Kotlin, C++, etc.) y una parte web (generalmente lograda mediante la inserción de una vista web en la aplicación). Para optimizar la experiencia del usuario, hay algunas recomendaciones y estrategias de implementación que puede utilizar.
Configuración básica
En general, recomendamos usar nuestro SDK para iOS or Android para poder integrar el CMP en tu app (parte nativa). El CMP generalmente se activará al iniciar la aplicación, mostrará la capa de consentimiento y permitirá que el usuario tome sus decisiones. Una vez que el usuario tomó las decisiones, el SDK eliminará la capa de consentimiento y la aplicación continuará.
En los casos en que la aplicación incluye una vista web, el contenido de esta vista web (por ejemplo, una página web que contiene publicidad) también necesitará saber si se otorgó el consentimiento y es posible que se necesite soporte para API como IAB TCF o IAB GPP. Por lo tanto, la página web que se carga dentro de la vista web también debe incluir el código CMP (Implementación de HTML del código).
Intercambio de información de consentimiento
Con la configuración principal anterior, el problema es que se le preguntará al usuario dos veces: una vez al iniciar la aplicación y una vez cada vez que se abre una (nueva) vista web. Para evitar esto, la información de consentimiento se puede intercambiar entre SDK y webview. Esto se hace exportando los datos de consentimiento del SDK y adjuntándolos a la URL que se carga dentro de la vista web.
Ejemplo:
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(Existe una función de exportación para ambos SDK, el ejemplo anterior se tomó de los ejemplos de iOS)
Una vez que se carga la vista web, el código CMP en la vista web se ejecutará y encontrará el hash (#cmpimport=.....) en la URL. El CMP importará automáticamente estos datos de consentimiento y ya no utilizará los datos de las cookies o el almacenamiento local. Dado que los datos de consentimiento se han importado al CMP, la capa de consentimiento normalmente no debería aparecer (nuevamente) porque el consentimiento del usuario ya existe.
Por favor note, esa información de consentimiento solo se puede compartir desde el SDK a la vista web y no en la dirección opuesta.
Sintonia FINA
Como último paso, puede haber algunos ajustes que le gustaría hacer.
Por un lado, el código CMP que está integrado en la vista web no debe mostrar el ícono del centro de preferencias (generalmente en el lado inferior izquierdo de la ventana del navegador, lo que permite a los visitantes actualizar sus opciones). Para desactivar el icono, vaya a Menú > Configuración legal > RGPD/CCPA/... > Mostrar icono de preferencias.
Por otra parte, incluso con la #cmpimport=... en la URL, aún puede haber casos en los que el CMP decida mostrar la capa de consentimiento en la vista web. Para evitar eso, recomendamos agregar un configuración del lado del cliente variable a todas las páginas que se muestran dentro de la vista web:
<script>
window.cmp_noscreen = true;
</script>
... your CMP-Code ...Esto evitará que se muestre la capa de consentimiento.
Preguntas Frecuentes
¿Puedo usar el mismo CMP en el SDK y la vista web?
Sí. Para el sistema, no importa si se usa el mismo CMP o un CMP diferente en el SDK, su vista web y/o su sitio web normal. Puede usar el mismo CMP o diferentes CMP en todos los entornos y todos los CMP pueden importar los datos de consentimiento entre sí.
Sin embargo, dado que en la mayoría de los casos la aplicación tiene diferentes necesidades en cuanto a comportamiento y diseño, generalmente es mejor separar los CMP de la aplicación y los CMP de la web. Lo mismo ocurre con los diseños: en general, el mismo diseño se puede usar en todos los entornos, pero en muchos casos tiene sentido tener un diseño separado para el entorno de la aplicación.
Recomendación: Si usa diferentes CMP en su aplicación y en su sitio web, le recomendamos que use el mismo CMP, que se usa en la parte nativa de su aplicación, para usarlo también en las vistas web dentro de su aplicación.
¿Cuáles son las ventajas y desventajas de usar el mismo CMP o uno diferente?
Estas son algunas de las ventajas de usar el mismo CMP en todos sus entornos:
- gestión más fácil de listas de proveedores, propósitos y cookies ya que todos los entornos usan la misma configuración
- sin fricción cuando los datos de consentimiento se transfieren de un entorno a otro
Estas son las desventajas de usar el mismo CMP en todos sus entornos:
- la lista de proveedores es potencialmente más larga en comparación con cuando los CMP están separados (ya que una lista de proveedores combinada debe incluir a todos los proveedores de todos los entornos)
- no hay posibilidad de distinguir ciertas configuraciones generales (por ejemplo, configuraciones generales como URL de privacidad, URL de T&C o configuraciones legales como soporte para GDPR, CCPA y otros)
- más complicado cuando se deben usar diferentes diseños (puede ser necesario usar objetivos)
¿Qué sucede cuando se utilizan dos CMP diferentes?
En caso de que el CMP utilizado en la parte nativa de la aplicación sea un CMP diferente al de la vista web, la información de consentimiento del SDK nativo se importa al CMP de la vista web. En los casos en que exista una diferencia entre la lista de propósitos y/o la lista de proveedores de los dos CMP, el CMP de importación (el que está en la vista web) tratará todos los propósitos y proveedores faltantes como "sin consentimiento" / "excluidos". Para ilustrar esto, supongamos la siguiente configuración:
CMP en la parte nativa de la aplicación:
Propósitos: A, B, C
Vendedores: 1, 2, 3
CMP en la vista web:
Propósitos: C, D, E
Vendedores: 3, 4, 5
En caso de que el usuario acepta en la parte nativa, el resultado será:
CMP en la parte nativa de la aplicación:
Propósitos: A=aceptado, B=aceptado,C=aceptado
Vendedores: 1=aceptado, 2 =aceptado, 3 =aceptado
CMP en la vista web:
Propósitos: C=aceptado, re=rechazado, mi=rechazado
Vendedores: 3=aceptado, 4 =rechazado, 5 =rechazado
En caso de que el usuario rechaza en la parte nativa, el resultado será:
CMP en la parte nativa de la aplicación:
Propósitos: A=rechazado, B=rechazado,C=rechazado
Vendedores: 1=rechazado, 2 =rechazado, 3 =rechazado
CMP en la vista web:
Propósitos: C=rechazado, re=rechazado, mi=rechazado
Vendedores: 3=rechazado, 4 =rechazado, 5 =rechazado
Por favor note que su conducta es independiente de la atribución de fines de los vendedores. Esto significa que el resultado será el mismo que el descrito anteriormente, incluso si todos los proveedores están asignados al propósito C.
Por favor note que su comportamiento es también independiente de las bases legales utilizadas de cada vendedor/finalidad e independiente de la jurisdicción en la que se encuentre el usuario.
