En muchos casos, una aplicación móvil consta de una parte nativa (por ejemplo, escrita en Java, Kotlin o C++, etc.) y una parte web (que suele conseguirse insertando una vista web en la aplicación). Para optimizar la experiencia del usuario, hay algunas recomendaciones y estrategias de implementación que puedes utilizar.

Configuración básica

En general, recomendamos utilizar nuestro SDK para iOS o Android con el fin de integrar el CMP en tu aplicación (parte nativa). El CMP se activará normalmente al iniciar la aplicación, mostrará la capa de consentimiento y permitirá al usuario tomar sus decisiones. Una vez que el usuario haya tomado sus decisiones, el SDK eliminará la capa de consentimiento y la aplicación continuará.

En los casos en que la aplicación incluya una vista web, el contenido de dicha vista (por ejemplo, una página web que contenga publicidad) también deberá saber si se ha dado el consentimiento, por lo que podría ser necesario el soporte de API como IAB TCF o IAB GPP. Por lo tanto, la página web que se carga dentro de la vista web también debería incluir el código CMP (implementación HTML del código).

Intercambio de información sobre el consentimiento

Con la configuración básica anterior, el problema es que se le preguntará al usuario dos veces: una al iniciar la aplicación y otra cada vez que se abra una (nueva) vista web. Para evitarlo, la información de consentimiento se puede intercambiar entre el SDK y la vista web. Esto se hace exportando los datos de consentimiento desde el SDK y adjuntándolos a la URL que se carga en la vista web.

Ejemplo:

// Swift version
let consentData = cmpManager.exportCMPString()
if let url = URL(string: "https://mywebsite.com/....#cmpimport=" + consentData) {
    myWebView.load(URLRequest(url: url))
}

// Kotlin version
val consentData = cmpManager.exportCMPString()
myWebView.loadUrl("https://mywebsite.com/....#cmpimport=" + consentData)

 

La exportCMPInfo función está disponible para ambos SDK, tanto para iOS como para Android.

Una vez que se cargue la vista web, el código CMP de la vista web se ejecutará y buscará el hash (#cmpimport=.....) en la URL. El CMP importará automáticamente estos datos de consentimiento y dejará de utilizar datos de cookies o del almacenamiento local. Dado que los datos de consentimiento se han importado al CMP, la capa de consentimiento no debería aparecer (de nuevo) normalmente, ya que el consentimiento del usuario ya existe.

Ajustes de precisión

Como último paso, es posible que quieras realizar algunos retoques.

Por un lado, el código CMP integrado en la vista web no debe mostrar el icono del centro de preferencias (que suele aparecer en la parte inferior izquierda de la ventana del navegador y permite a los visitantes actualizar sus opciones). Para desactivar el icono, ve a Menú > Ajustes legales > RGPD/CCPA/… > Mostrar icono de preferencias.

Por otro lado, incluso con el #cmpimport=... en la URL, puede haber casos en los que el CMP decida mostrar la capa de consentimiento en la vista web. Para evitarlo, recomendamos añadir una variable de configuración del lado del cliente a todas las páginas que se muestren dentro de la vista web:

<script>
 window.cmp_noscreen = true;
</script>
... your CMP-Code ...

Esto evitará que se muestre la ventana de consentimiento.

Preguntas frecuentes

¿Puedo utilizar el mismo CMP en el SDK y en la vista web?

Sí. Para el sistema no importa si se utiliza el mismo CMP o un CMP diferente en el SDK, en tu vista web y/o en tu sitio web habitual. Puedes utilizar 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 necesidades diferentes en cuanto a comportamiento y diseño, suele ser mejor separar los CMP de la aplicación y los CMP web. Lo mismo ocurre con los diseños: en general, se puede utilizar el mismo diseño en todos los entornos, pero en muchos casos tiene sentido contar con un diseño independiente para el entorno de la aplicación.

¿Cuáles son las ventajas y desventajas de utilizar el mismo CMP o uno diferente?

Estas son algunas de las ventajas de utilizar el mismo CMP en todos tus entornos:

• Gestión más sencilla de las listas de proveedores, fines y cookies, ya que todos los entornos utilizan la misma configuración
• sin fricciones cuando los datos de consentimiento se transfieren de un entorno a otro

Estas son las desventajas de utilizar el mismo CMP en todos tus 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 ciertos ajustes generales (por ejemplo, ajustes generales como la URL de privacidad, la URL de los Términos y Condiciones, o ajustes legales como la compatibilidad con el RGPD, la CCPA y otros).
• Es más complicado cuando hay que utilizar diseños diferentes (puede que sea necesario utilizar segmentaciones).

¿Qué ocurre cuando se utilizan dos CMP diferentes?

En caso de que el CMP utilizado en la parte nativa de la aplicación sea 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 haya una diferencia entre la lista de fines y/o la lista de proveedores de las dos CMP, la CMP importadora (la de la vista web) tratará todos los fines y proveedores que falten como «sin consentimiento» / «excluidos». Para ilustrarlo, supongamos la siguiente configuración:

CMP en la parte nativa de la aplicación:
Finalidades: A, B, C
Proveedores: 1, 2, 3

CMP en la vista web:
Finalidades: C, D, E
Proveedores: 3, 4, 5

En caso de que el usuario acepte en la parte nativa, el resultado será:

CMP en la parte nativa de la aplicación:
Finalidades: A = aceptada, B = aceptada, C = aceptada
. Proveedores: 1 = aceptado, 2 = aceptado, 3 = aceptado.

CMP en la vista web:
Finalidades: C = aceptado, D = rechazado, E = rechazado
Proveedores: 3 = aceptado, 4 = rechazado, 5 = rechazado

En caso de que el usuario rechace la parte en su idioma nativo, el resultado será:

CMP en la parte nativa de la aplicación:
Finalidades: A = rechazada, B = rechazada, C = rechazada
. Proveedores: 1 = rechazado, 2 = rechazado, 3 = rechazado.

CMP en la vista web:
Finalidades: C = rechazado, D = rechazado, E = rechazado
. Proveedores: 3 = rechazado, 4 = rechazado, 5 = rechazado.