La diferencia entre ad_user_data y ad_personalization

Todos los artículos

Son dos de las cuatro señales de Consent Mode v2 y controlan cosas distintas. ad_user_data fija el consentimiento para enviar datos de usuario a Google con fines publicitarios. ad_personalization fija el consentimiento para la publicidad personalizada, que es para lo que sirve una audiencia de remarketing. Si se deniega la primera, no llega nada a nivel de usuario; si se deniega la segunda, los datos llegan, pero no sirven para dirigirse a esa persona.

Dos preguntas, en dos puntos distintos

Consent Mode empezó haciendo una sola pregunta sobre publicidad, y era sobre almacenamiento: ¿podemos guardar un identificador publicitario en este dispositivo? Eso es ad_storage, y sigue ahí haciendo el mismo trabajo.

La versión 2 añadió dos más, y lo interesante es que ninguna de las dos trata del almacenamiento. Tratan del uso. ad_user_data pregunta si se pueden enviar datos de usuario a Google con fines publicitarios. ad_personalization pregunta si se pueden usar para publicidad personalizada. Las dos formulaciones son de la propia Google, de su documentación sobre el consentimiento en la plataforma de etiquetas. Así que una configuración publicitaria moderna tiene tres puntos de control en lugar de uno, y los tres son independientes: un visitante puede quedar representado por cualquier combinación de ellos.

Esa independencia es la razón por la que la distinción importa. La mayoría de los banners la esconden detrás de un único interruptor de publicidad, que es un diseño razonable, pero eso significa que la asignación de debajo hace un trabajo que nadie ve. La versión sencilla del modelo completo está en Consent Mode v2 explicado sin jerga.

Cuál frena tu remarketing

La respuesta corta es que las dos, en puntos distintos de la cadena. Leerás que uno de los parámetros es el del remarketing, que queda más ordenado que la realidad.

ad_personalization es la señal que habla del uso en sí. Fija el consentimiento para la publicidad personalizada, y la publicidad personalizada es para lo que sirve una lista de audiencia, así que un visitante que la deniega no es alguien sobre quien puedas actuar de esa forma.

ad_user_data está antes en la cadena. Fija el consentimiento para enviar datos de usuario a Google con fines publicitarios, y si se deniega no llegan datos a nivel de usuario con los que montar una audiencia. Más que bloquear la lista, la deja sin alimentar. Esa misma denegación tiene otro efecto aparte en el recuento de conversiones, que desmontamos en qué le pasa a una conversión de Google Ads cuando se deniega ad_user_data.

Donde esto deja de ser teoría es en Customer Match. Para datos de personas del EEE, Google exige que los dos campos de consentimiento estén concedidos antes de poder usar la lista, y trata un valor ausente como no consentido. Si lo montas en torno a una sola de las señales, puedes acabar con una lista subida que no tienes permiso para usar, y eso es peor que una lista vacía, porque parece que ha funcionado.

La combinación para la que nadie diseña

Deja a un lado los dos extremos. Con las dos concedidas, todo se comporta como esperas, y con las dos denegadas entras en el terreno del modelado, que es el caso que tratamos cuando los visitantes rechazan las cookies sin más.

El estado interesante es ad_user_data concedido con ad_personalization denegado. Es algo perfectamente coherente que una persona quiera: mide mi visita, cuéntame en tus cifras de conversión, no me persigas. También es el estado que más a menudo encontramos sin representar, porque un banner con una sola categoría de publicidad no puede producirlo, y uno con varias muchas veces acaba asignándolas todas a una única señal de todos modos.

El caso contrario, personalización concedida con los datos de usuario denegados, es un síntoma, no un diseño: permiso para personalizar con datos que no tienen permiso para llegar. Si te lo encuentras en producción, normalmente estás ante una asignación rellenada campo a campo en lugar de pensada.

Cómo ver qué señales envía de verdad tu web

Puedes resolverlo con una sola carga de página, y el primer paso pilla a casi todo el mundo.

1. No intentes leer estas dos en gcs

   El parámetro gcs solo lleva ad_storage y analytics_storage. Leer un valor de gcs que parece correcto y concluir que las señales publicitarias están bien es un falso aprobado idéntico a uno real, porque ese parámetro nunca iba a mencionarlas.

2. Mira gcd en su lugar, como comprobación cruzada

   El parámetro gcd viaja en los hits a los servicios de Google y codifica los cuatro tipos de consentimiento junto con cómo se generó cada estado. Google lo considera una implementación interna que puede cambiar, así que úsalo para confirmar lo que ya crees, no como fuente de verdad.

3. Lee el estado de consentimiento en Tag Assistant o en la vista previa

   Esta es la respuesta con la que actúas. Muestra los cuatro tipos de consentimiento con sus valores en la página, en cada evento, y es la única vista que te enseña en el mismo sitio un valor y el momento en que cambió.

4. Prueba el estado mixto a propósito

   Acepta la medición y rechaza la personalización, si tu banner lo permite, y fíjate en si las dos señales se separan de verdad. Si siempre se mueven juntas, tus categorías están asignadas a un solo interruptor, diga lo que diga la interfaz.

5. Comprueba la actualización, no solo el valor por defecto

   Los valores denegados por defecto son fáciles de dejar bien, y es fácil quedarse ahí. Lo que importa es la actualización que se dispara cuando el visitante elige, y si lleva las tres señales publicitarias o solo la que había cuando se montó la configuración. Es la misma disciplina que comprobar la señal de consentimiento en la petición saliente.

Qué hacer cuando ya lo sabes

Si tu banner ofrece una sola categoría de publicidad, asígnala a las tres señales publicitarias y asegúrate de que la actualización las envía juntas. Es un diseño defendible.

Si tu banner ofrece opciones separadas, la asignación tiene que respetarlas, porque una interfaz que muestra granularidad mientras la implementación la colapsa es lo peor de los dos mundos: has asumido la complejidad sin quedarte con ninguna de sus ventajas, y al visitante se le ha mostrado una elección que no existía.

En cualquier caso, comprueba primero si las dos señales de Consent Mode v2 se envían siquiera. Una instalación anterior a ellas puede parecer sana en su pantalla de ajustes mientras solo envía el par original, y ese es un problema distinto al de cualquier visitante que rechace algo.

Velo envía las cuatro señales desde una sola asignación de categorías que puedes leer en una única pantalla, así que el estado que eligió el visitante es el estado que sale de la página. Cómo está conectado lo tienes en la página de producto.