Consent Mode: La solución de Google al futuro de la privacidad digital | Capítulo 2

¿Qué esperar en mis datos al implementar avanzadamente? BigQuery vs GA4

Es crucial tener en cuenta las diferencias entre BigQuery y GA4 al desplegar la implementación avanzada de consent mode. La diferencia principal radica en que el modelado solo estará presente en GA4. En BigQuery, se recopilarán todos los datos, tanto de hits con consentimiento como de pings sin consentimiento, pero careceremos de esa "modelización" que Google realiza para compensar las lagunas y conectar las interacciones entre sí.

Examinemos lo que encontraremos en cada herramienta:

• BigQuery

Desde el instante en que implementamos Consent Mode, comenzamos a almacenar datos en BigQuery. Podemos distinguir entre datos con y sin consentimiento a través de las variables de privacy_info, las cuales tomarán los valores "yes" o "no" para cada una de las tipologías de consentimiento (analytics_storage, ads_storage), en función del consentimiento otorgado por el usuario.

¿Qué tipo de información vemos para aquellos eventos con el consentimiento denegado?

En el caso de que se deniegue el consentimiento, no contaremos con ninguna variable persistente que nos permita vincular interacciones entre sí. Por este motivo, observaremos que, para cada nueva carga de página, se generará un nuevo evento de session_start y first_visit en BigQuery, y la variable ga_session_number se poblará en todos los casos como 1.

Un aspecto relevante a considerar es lo que recopilaremos en las dimensiones de atribución del tráfico. Las variables bajo traffic_source no se llenarán, aunque las variables de source, medium y campaign asociadas a los parámetros de evento, así como las relacionadas con los utms manuales (por ejemplo, collected_traffic_source.manual_source), se recogerán, pero únicamente para los eventos que hayan tenido lugar dentro de la primera carga de página, perdiendo la atribución a partir de ese momento.

Finalmente, es esencial destacar que todas las variables personalizadas recopiladas a través de nuestro datalayer, así como el user_id y toda la información de las transacciones, incluido el transaction_id, productos adquiridos, etc., estarán disponibles también en el caso de los Pings sin consentimiento.

• GA4: ¿Cómo habilitar el modo de consentimiento y qué diferencias encontramos?

En relación con GA4, destacamos que la diferencia principal radica en la posibilidad de visualizar datos modelados, siempre y cuando se hayan cumplido los requisitos establecidos por Google, que detallamos más adelante. Una vez que estos requisitos se cumplen, podemos activar el modo de consentimiento accediendo al apartado de Administración, Identidad para los informes, y seleccionando la opción "Mezclado":

Ahora bien, existen en todo caso una serie de informes que no admiten a día de hoy el uso de datos de modelos de comportamiento:

• Audiencias
• Explorador de usuarios, cohorte y exploraciones del tiempo de vida de los usuarios
• Segmentos con secuencia
• Informe "Retención"
• Métricas predictivas
• Exportación de datos (por ejemplo, BigQuery Export)

Consideraciones a tener en cuenta:

Al tener habilitado el método "Mezclado" en GA4, se mostrarán el 100% de las interacciones en la interfaz, incluyendo, por ejemplo, el 100% de las transacciones.

Lo mismo va a ocurrir con los eventos de session_start y first_visit. Sin embargo en este caso veíamos que estos eventos se van a enviar de nuevo con cada nueva carga de página. 

Esto podría resultar en un recuento inflado de estos eventos, y no se pueden considerar como definitivos. En estos casos, el modelado de comportamiento entra en juego para deduplicar estos eventos cuando se utilizan métricas de sesiones y primeras visitas. Proporcionará una estimación más precisa basada en el aprendizaje generado a partir de los datos observados, ofreciendo una visión más realista de estos datos de sesiones.

¿Cómo funciona dicho modelado de comportamiento?

Cuando no se despliegan cookies debido a la falta de consentimiento, la recopilación de información para visitas sin consentimiento implica el envío de eventos aislados, anonimizados y no identificables para cada interacción del usuario suprimiendo en este sentido las variables de user_pseudo_id y ga_session_id, que permiten asociar las interacciones dentro de una misma sesión o a lo largo de sesiones múltiples del mismo usuario.

Con cada nueva carga de página, se genera un nuevo identificador aleatorio, eliminando la trazabilidad entre interacciones al no existir un identificador de usuario persistente. Esto significa que si Google Analytics registra, por ejemplo, 10 páginas vistas, no podrá determinar si pertenecen al mismo usuario o a usuarios diferentes.

Aquí es donde entra en juego el modelado. En este punto, Analytics utiliza el aprendizaje automático para estimar el comportamiento de esos usuarios basándose en aquellos que han aceptado cookies. Siempre emplea datos observados para suplir las lagunas y modelar el comportamiento de los usuarios que no han aceptado.

En resumen, los Pings envían información aislada de las diferentes interacciones del usuario que no ha aceptado cookies, y el modelado aplica el aprendizaje generado a partir de los usuarios observados (que han aceptado cookies) para intentar unir esas interacciones y dar sentido a los eventos aislados.

Requisitos para el modelado de comportamiento

Para que Google pueda llevar a cabo el modelado se deben cumplir ciertos requisitos que proporcionen una base de datos suficiente para el modelado. Estos son:

1. Implementación del Consent Mode: El Consent Mode debe estar implementado en todas las páginas web o en todas las pantallas de la aplicación (APP). Las etiquetas deben cargarse antes de la carga del banner de consentimiento e independientemente de si el usuario otorga su consentimiento.
2. Recopilación de eventos: La propiedad debe recoger, como mínimo, 1.000 eventos por día con el parámetro "analytics_storage=denied" durante al menos 7 días.
3. Usuarios que otorgan consentimiento: La propiedad debe tener, al menos, 1.000 usuarios diarios que envíen eventos con el parámetro "analytics_storage=granted" durante al menos 7 de los 28 días anteriores.

Los datos modelados estarán disponibles a partir de la fecha en que la propiedad cumpla todos los requisitos. En caso de que la propiedad deje de cumplirlos en algún momento posterior, los datos estimados dejarán de estar disponibles hasta que se vuelvan a cumplir los requisitos.

Es importante destacar que los eventos enviados con el parámetro "analytics_storage=denied" se contabilizan para la facturación como un hit más y, por lo tanto, son facturables.

Consideraciones y soluciones desde el punto de vista legal

Dentro de las interacciones que se transmiten con el parámetro "analytics_storage=denied", se incluyen datos como el user_id, transaction_id y dimensiones personalizadas declaradas en el datalayer. Este hecho plantea posibles desafíos legales, ya que variables como el user_id podrían permitir la conexión y asociación de diferentes interacciones, identificando con certeza que provienen del mismo usuario.

Consciente de esta preocupación legal, Google ha desarrollado una solución que permite anonimizar automáticamente aquellos campos que, por defecto, se transmitirían pero que podrían constituir un obstáculo desde el punto de vista legal al contener información a nivel de usuario. En situaciones en las que el usuario haya rechazado las cookies, estos campos se enviarían en blanco, asegurando así el cumplimiento de las regulaciones de privacidad.

Esta iniciativa de Google refleja su compromiso en adaptarse a las necesidades específicas de cada cliente, proporcionando una solución que equilibra el respeto por la privacidad de los usuarios y la necesidad esencial de acceder a parte de sus datos. En Jakala, ya estamos brindando apoyo a varios clientes en la implementación y aprovechamiento de esta funcionalidad.