En la primera parte de esta serie: “Introducción al análisis de riesgos“, te hemos ofrecido una visión general sobre qué normativas de protección de datos existen, qué requisitos se deben cumplir para recopilar datos de conformidad con el GDPR y cuáles son sus consecuencias.
En esta parte, abordaremos la cuestión de cómo funciona técnicamente una CMP (Plataforma de Gestión de Consentimiento).
¿Por qué veo banners de consentimiento una y otra vez?
Quizá te hayas preguntado alguna vez por qué sigues viendo el banner de consentimiento en un sitio web, aunque ya hayas tomado una decisión previamente. Pues bien, puede deberse a diferentes motivos.
Más allá de situaciones especiales, la razón más probable es que estés visitando el sitio web con diferentes dispositivos o navegadores. Esto se debe a que, al igual que la mayoría de los sistemas de análisis web, el CMP no puede reconocer a un usuario a través de diferentes navegadores o dispositivos. Veamos cómo funciona el CMP.
Los usuarios son instancias del navegador
Esto quiere decir que, cuando un usuario visita la página de un sitio web en la que se ha implementado correctamente un CMP, este CMP en particular intervendrá inmediatamente.
En otras palabras, si un usuario visita el sitio web por primera vez (o repetidamente sin haber tomado una decisión explícita), se mostrará el banner de consentimiento correspondiente.
Si el usuario ya ha tomado una decisión explícita en una sesión anterior, esta decisión se utiliza para disparar aquellas tecnologías a las que el usuario ha dado su consentimiento.
Entonces, ¿cómo distingue el CMP al usuario y cómo sabe el CMP qué tecnología ha consentido el usuario?
En primer lugar, veamos cómo identifica el CMP a un usuario. Para ello, revisaremos los CMP de Usercentrics y OneTrust.
Usercentrics
Tan pronto como se abre una página web en el navegador donde está implementado Usercentrics, se genera un controllerId y se almacena en el Almacenamiento Local del navegador.
Inicialmente, no importa si el usuario consiente explícitamente el uso de tecnologías o no, el controllerId sólo sirve para reconocer al usuario o la instancia del navegador.
En el contexto de este controllerId, sin embargo, también se almacena el consentimiento explícito o el rechazo de las tecnologías por parte del usuario.
La principal ventaja de almacenar el controllerId así como el consentimiento/rechazo explícito en el Almacenamiento Local es principalmente que éste -a diferencia de las cookies- no puede ser eliminado automáticamente sin intervención posterior.
OneTrust
Si un usuario abre ahora una página web en el navegador en el que está implementado OneTrust, se crea el denominado consentId. Sin embargo, a diferencia de Usercentrics, este no se almacena en el almacenamiento local del navegador, sino en forma de cookie.
De forma similar a Usercentrics, no importa si el usuario consiente explícitamente el uso de tecnologías o no, porque el consentId también se utiliza para reconocer al usuario o la instancia del navegador.
En el contexto de este consentId, también se almacena el consentimiento explícito o el rechazo de categorías por parte del usuario.
El almacenamiento de estos datos en una cookie conlleva el riesgo de que también se eliminen cuando se borren las cookies (por ejemplo, a través de la configuración del navegador) y el usuario vuelva a ver el banner de consentimiento.
Visitar el sitio web por segunda o más veces
Ahora, en cuanto el usuario visita el sitio web por segunda o más veces, el CMP extrae la información almacenada sobre el consentimiento dado o denegado y la introduce en la capa de datos del navegador.
A continuación, la tecnología correspondiente puede utilizar esta información para disparar o no una etiqueta. De este modo, se garantiza que las etiquetas que requieren consentimiento sólo se activen si el usuario ha dado su consentimiento.
Uso de los datos procedentes del CMP
Veamos ahora cómo podemos utilizar la información proporcionada por el CMP con Google Tag Manager.
En primer lugar, el CMP proporciona los consentimientos otorgados por el usuario en el DataLayer de GTM en el momento de la inicialización. La forma de hacerlo depende principalmente del CMP que se utilice.
Por ejemplo, el CMP de Usercentrics proporciona el consentimiento para cada tecnología configurada de forma granular en la DataLayer:
El CMP de OneTrust, en cambio, agrupa varias tecnologías en categorías y, por tanto, sólo almacena en el dataLayer el número de categoría para el que existe consentimiento:
Ambos enfoques tienen sus ventajas y desventajas, que veremos con más detalle en otro artículo.
La información disponible en el dataLayer ahora puede ser almacenada en una variable de la capa de datos y utilizada en consecuencia en la configuración de disparadores para las respectivas etiquetas.
Así, por ejemplo, si desea personalizar el disparador para lanzar la etiqueta de Google Analytics, se accionará el disparador sólo si el dataLayer tenía el valor
- “Google Analytics: true” cuando se use Usercentrics o
- “C0002” en “OnetrustActiveGroups” cuando se use OneTrust.
Potenciales problemas
El procedimiento aquí descrito también puede dar lugar a las denominadas condiciones de carrera.
Una condición de carrera es una situación no deseada que se produce cuando el GTM intenta activar dos o más activadores simultáneamente, que fallan debido a la secuencia de eventos o a la falta de datos en la capa de datos.
Por lo tanto, es necesario garantizar que la información y los eventos proporcionados puedan ejecutarse en el orden correcto. Un medio probado en GTM es, por ejemplo, el uso de grupos de desencadenantes.
¿Necesitas ayuda?
Cuando no estés seguro de si estás experimentando una condición de carrera o si no estás familiarizado en absoluto con la aplicación de un CMP, no dudes en recurrir a nosotros en e-CENS, estamos aquí para ayudarte.
Próximamente
La próxima parte de la serie se centrará en cómo compensar las lagunas creadas por la falta de consentimiento…
