Las dos señales nuevas del modo de consentimiento de Google v2

¿Qué cambió el modo de consentimiento de Google v2?

En noviembre de 2023, el modo de consentimiento de Google v2 añadió dos parámetros publicitarios, ad_user_data y ad_personalization, junto a las señales ad_storage y analytics_storage que las etiquetas de Google ya leían. La documentación de la plataforma de etiquetas de Google lo dice sin rodeos: el modo de consentimiento se actualizó en noviembre de 2023 y ahora contiene dos parámetros adicionales (Manage consent mode). La mecánica de debajo, los comandos default y update y el modelado que Google ejecuta sobre los resultados, está cubierta en una guía práctica del modo de consentimiento. Esta página se queda en lo que la versión 2 puso encima.

¿Qué controlan ad_user_data y ad_personalization?

Los dos parámetros parten una vieja pregunta en dos. La referencia de gtag de Google define ad_user_data como el que fija el consentimiento para enviar datos de usuario a Google con fines publicitarios, y ad_personalization como el que fija el consentimiento para la publicidad personalizada (gtag.js reference). Uno rige la transmisión, el otro rige el uso. Un visitante puede aceptar que sus datos lleguen a Google para medir conversiones y aun así negarse a que lo segmenten con ellos, y la versión 2 le da a esa distinción un formato de transmisión.

Existen siete tipos de consentimiento en toda la API. Las descripciones de Google, citadas de sus propias páginas:

Cada uno de ellos acepta exactamente dos valores, granted o denied. Nada más se interpreta.

¿El RGPD exige el modo de consentimiento de Google v2?

No, y esa confusión es el error más común en lo que se escribe sobre este tema. El modo de consentimiento de Google v2 es un requisito que Google impone a los anunciantes que quieren seguir usando sus productos, sostenido por la política de consentimiento de usuarios de la UE, que se aplica a los usuarios finales del Espacio Económico Europeo, el Reino Unido y Suiza, y que obliga a los anunciantes a obtener consentimiento para el uso de cookies u otro almacenamiento local cuando la ley lo exija y para la recogida, el intercambio y el uso de datos personales para la personalización de anuncios (EU user consent policy). El RGPD y la Directiva ePrivacy imponen los deberes legales de fondo. Ninguno de los dos nombra un parámetro de JavaScript.

La consecuencia práctica: una implementación que envía granted para todo satisface la fontanería de Google y sigue incumpliendo la ley si no se recogió un consentimiento válido. Qué hace válido un consentimiento en primer lugar está aguas arriba de cualquier API, y se cubre en qué cuenta como consentimiento de rastreo y en los requisitos de consentimiento del RGPD para la analítica web. Conecta las señales después de resolver la cuestión legal, no en lugar de resolverla.

Básico o avanzado: ¿qué implementación eliges?

Google documenta dos implementaciones del modo de consentimiento, y la versión 2 hereda ambas. En el modo de consentimiento básico, el sitio impide que las etiquetas de Google se carguen hasta que el usuario interactúa con un banner de consentimiento, y no se envía ningún dato antes de que el usuario consienta. En el modo de consentimiento avanzado, las etiquetas de Google se cargan cuando el usuario abre el sitio o la app con los valores por defecto en denied, y cuando el consentimiento se deniega se envían el estado de consentimiento y pings sin cookies, mientras que cuando se concede se escriben cookies (Ayuda de Google Ads).

La diferencia se ve en el modelado de Google. La misma página de ayuda describe el modo básico como productor de un "General model (less detailed modeling)" y el avanzado como productor de un "Advertiser-specific model (more detailed modeling)". El modo avanzado compra un mejor modelado de conversiones transmitiendo un ping sin cookies desde visitantes que dijeron que no, y esa es una decisión de protección de datos que debería tomar un equipo legal en lugar de uno de crecimiento. Elijas el que elijas, el banner de consentimiento tiene que disparar la llamada update y no limitarse a repintarse.

¿Qué se rompe en los productos publicitarios de Google cuando faltan las señales?

Que falten no es neutral. La documentación de Customer Match de Google afirma: "If these consents are missing, then the consent value is determined as not consented", y que los datos de usuarios del EEE sin consentimiento no se procesarán y no se pueden usar para personalización de anuncios con Customer Match (About Customer Match and the EU user consent policy). La misma página lleva el requisito con fecha: a partir de marzo de 2024, para que las listas de Customer Match se usen en el EEE, ambos campos de consentimiento del tipo ConsentStatus deben estar en 'GRANTED' para indicar que has recibido el consentimiento de usuario exigido.

Qué etiquetas leen siquiera las señales también está documentado. Google lista los productos cuyas etiquetas llevan comprobaciones de consentimiento integradas: Google Analytics, Google Ads, Floodlight y Conversion Linker (Consent mode in Google Analytics). Una etiqueta fuera de esa lista no responde a una llamada gtag('consent', ...), así que bloquearla es tarea tuya.

¿Cómo llevan los comandos default y update los parámetros nuevos?

El comando default corre antes de que se dispare cualquier etiqueta de Google, y el comando update corre cuando el visitante responde. La forma documentada por Google:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});
 
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Dos opciones importan para la corrección. Google documenta wait_for_update con un valor en milisegundos para controlar cuánto esperar antes de enviar datos, pensado para plataformas de consentimiento que resuelven de forma asíncrona, y una clave region fijada según la ISO 3166-2 en el comando default, donde la que tenga la región más específica es la que surte efecto. Que default corra después de que gtag.js ya haya enviado una página vista es el fallo que anula todo el montaje en silencio, y la misma trampa de orden se disecciona en la guía de consentimiento de cookies para Google Analytics.

¿Qué no ha documentado Google?

Google no ha publicado ningún calendario de sanciones para el modo de consentimiento, ninguna multa y ninguna política de suspensión de cuentas ligada a los dos parámetros. La única fecha firme en las propias páginas de Google para esta actualización es el requisito de Customer Match de marzo de 2024 citado arriba; trata cualquier otra fecha de aplicación que circule por blogs como no documentada hasta que Google la publique. La consecuencia documentada es funcional y no punitiva: los datos del EEE sin consentimiento no se procesan para personalización, y la función de audiencia o de medición que dependía de ellos se degrada.

Hay una salida de todo el aparato, que es no enviar señales publicitarias a Google en absoluto. La analítica sin cookies saca los parámetros de la ecuación, y la analítica centrada en la privacidad de Flowsery no usa cookies y se aloja en la UE, así que no hay ninguna decisión de ad_storage que modelar. Los equipos que corren Google Ads siguen necesitando el modo de consentimiento para el lado de los anuncios, porque una herramienta de medición no puede responder por las etiquetas de otro proveedor.

Preguntas frecuentes

¿Es obligatorio el modo de consentimiento de Google v2?

Es obligatorio para los anunciantes que quieren que las funciones de publicidad y medición de Google sigan funcionando con tráfico del EEE, el Reino Unido y Suiza, bajo la política de consentimiento de usuarios de la UE de Google. No es obligatorio bajo el RGPD, que regula el consentimiento en sí y no cómo se lo transmites a un proveedor. Un sitio que no ejecuta etiquetas publicitarias de Google no tiene ninguna obligación de modo de consentimiento por parte de Google.

¿Qué pasa si solo envío ad_storage y analytics_storage?

La documentación de Customer Match de Google afirma que cuando los campos de consentimiento faltan, "the consent value is determined as not consented". Los parámetros de la v1 no sustituyen a los de la v2. Las funciones de personalización que dependen de ad_user_data y ad_personalization tratan ese tráfico como rechazado.

¿Puede ad_user_data estar en granted mientras ad_personalization está en denied?

Sí, y esa combinación es el motivo de haberlos separado. Significa que los datos pueden llegar a Google con fines publicitarios mientras se rechaza la publicidad personalizada. Un banner de consentimiento con conmutadores separados por finalidad debería mapear a ese par en lugar de colapsar ambos en una sola casilla.

¿El modo de consentimiento básico sigue contando como modo de consentimiento de Google v2?

Sí. Básico y avanzado son elecciones de implementación, y ambas llevan los cuatro parámetros de publicidad y analítica. El modo básico bloquea las etiquetas de Google hasta que el visitante interactúa con el banner, así que los parámetros llegan solo en la llamada update.

¿Qué regiones cubre el requisito de Google?

La política de consentimiento de usuarios de la UE de Google nombra a los usuarios finales del Espacio Económico Europeo, el Reino Unido y Suiza. El requisito de consentimiento de Customer Match citado por Google referencia el EEE. La documentación de Google no extiende el requisito a otras regiones.

¿El modo de consentimiento restaura los datos que los visitantes rechazaron?

No. El modo de consentimiento alimenta el modelado de conversiones de Google, que produce estimaciones en lugar de observaciones, y Google etiqueta las dos implementaciones como alimentadoras de un modelo general o de un modelo específico del anunciante. Las advertencias sobre el modelado, y cómo aparecen en los informes, están cubiertas en la guía del modo de consentimiento.

¿En qué se diferencian las señales v1 y v2 del modo de consentimiento de Google?

Las señales v1 son ad_storage y analytics_storage. La versión 2 conservó ambas y añadió ad_user_data y ad_personalization en noviembre de 2023, dividiendo la antigua decisión única de consentimiento en señales separadas para el envío de datos a Google y para su uso en publicidad personalizada.

¿Qué etiquetas de Google revisan realmente las señales del modo de consentimiento?

Google nombra a Google Analytics, Google Ads, Floodlight y Conversion Linker como los productos cuyas etiquetas tienen verificaciones de consentimiento incorporadas. Una etiqueta fuera de esa lista ignora una llamada a gtag('consent', ...) y sigue disparándose salvo que algo más la bloquee.

¿Qué hace wait_for_update en el modo de consentimiento?

Es un parámetro que Google documenta para el comando default, fijado en un valor en milisegundos que indica a gtag.js cuánto tiempo retener las solicitudes antes de enviarlas. Existe para las plataformas de gestión de consentimiento que resuelven de forma asíncrona, así las etiquetas no se disparan en la carga inicial antes de que la plataforma haya reportado una decisión.

¿Puede el parámetro region fijar valores predeterminados distintos según el país?

El comando default acepta una clave region con códigos ISO 3166-2, y Google aplica la región coincidente más específica. Un sitio puede fijar un valor predeterminado para el EEE y otro distinto para el resto en la misma llamada a default.