Por qué tu tráfico de GA4 aparece como Unassigned tras añadir un banner de cookies

Todos los artículos

Unassigned no es tráfico que falte. Es tráfico que GA4 sí recibió y no pudo atribuir a ningún canal. Después de publicar un banner suele aparecer por una de estas tres razones: el consentimiento llega a mitad de la visita, así que el origen original ya se ha perdido; la sesión nunca registró un session_start; o una configuración del lado del servidor está devolviendo una identidad a pings que debían permanecer anónimos.

Unassigned significa recogido, no perdido

Un visitante que nunca da su consentimiento, en un sitio que condiciona bien sus etiquetas, no genera ningún evento. Eso se ve como un total de sesiones más bajo, no como una fila en el grupo Unassigned. Unassigned aparece cuando GA4 sí tiene eventos de una sesión y no puede encajarlos en ninguna definición de canal: sin parámetros de campaña, sin un referrer utilizable o sin un evento que marque el inicio de la sesión del que colgar un origen.

Así que la tranquilidad que ofrecen las páginas de ayuda de la mayoría de proveedores de consentimiento, esa de que Unassigned demuestra que el banner está haciendo su trabajo, vale para el primer patrón de abajo y no para los otros dos. En esos, se está recogiendo algo con una forma que GA4 no puede aprovechar, y eso hay que arreglarlo, no aceptarlo.

Patrón uno: el consentimiento llega a mitad de la visita

Alguien llega desde un anuncio o desde un resultado de búsqueda, aparece el banner y analytics_storage sigue denegado mientras lee. No se almacena en ningún sitio nada que pueda conservar el origen. En la tercera página acepta. GA4 empieza a recoger datos correctamente a partir de ese momento, pero la página en la que empieza es una página interna: el referrer es tu propio dominio y los parámetros de campaña quedaron dos navegaciones atrás. Las reglas de canal no tienen nada que leer, así que la sesión acaba en Unassigned.

Este patrón es real y en parte inevitable. También es el que puedes reducir. Con URL passthrough activado, los identificadores de clic de anuncio de Google viajan en la query string de página en página mientras las cookies están denegadas, así que un visitante que acepta tarde llega igualmente con algo atribuible. Que esa opción esté siquiera disponible para ti depende de qué Consent Mode está ejecutando realmente tu sitio.

Patrón dos: la sesión nunca registró su inicio

La asignación de canal depende del primer evento de una sesión. Si la etiqueta de configuración y las etiquetas de evento están condicionadas de forma distinta, o si el estado por defecto del consentimiento se define después de que la etiqueta de Google ya se haya disparado, acabas con sesiones cuyo primer evento recogido es otra cosa completamente distinta: un envío de formulario, un scroll, una compra.

La señal son sesiones Unassigned que contienen conversiones. Actividad real, sin origen. Eso es un fallo de montaje, no un resultado de privacidad, y pertenece a la misma familia que las caídas repentinas de las que escribimos en por qué tus conversiones de GA4 cayeron de un día para otro.

Patrón tres: a los pings denegados se les da una identidad

Este es del que no escribe nadie y el más rápido en inundar una propiedad. En una configuración de Google Tag Manager del lado del servidor, el cliente de GA4 puede gestionar sus propias cookies. Si se deja en el ajuste Server Managed, el contenedor escribe un identificador propio y lo estampa en las solicitudes entrantes, incluidos los pings sin cookies que se enviaron precisamente porque se denegó el consentimiento.

Ahora esos pings llegan con un identificador estable. En lugar de alimentar el modelado al que debería contribuir el tráfico denegado, se cuentan como sesiones. No llevan ningún dato de campaña, porque no se permitió almacenar ninguno, así que todos acaban en Unassigned. Su proporción sigue de cerca tu tasa de rechazo y aparece a los pocos días de publicar el banner, que es justo por lo que el banner se lleva la culpa.

Lo encontramos en una reconstrucción de consentimiento en producción, después de semanas viendo crecer el grupo Unassigned del cliente sin explicación. La solución fue un único ajuste: cambiar la gestión de cookies del cliente de GA4 a JavaScript Managed, para que un ping denegado siga siendo anónimo de principio a fin. Es también la razón por la que pasarte a un servidor no te permite quitar el banner, algo que tratamos en si sigues necesitando un banner de cookies con etiquetado del lado del servidor.

Cómo saber cuál tienes

1. Compara la forma, no el total

   Comprueba si Unassigned creció o si simplemente cayeron tus totales mientras la mezcla de canales se mantenía estable. Un número más pequeño con la misma mezcla es el consentimiento funcionando como debe. Un grupo nuevo que el mes pasado no estaba ahí es una cuestión de montaje.

2. Busca conversiones dentro de Unassigned

   Crea una exploración con el origen y el medio de la sesión y pon tus eventos clave al lado. Una aceptación tardía produce sesiones silenciosas; las conversiones completas sin origen apuntan más bien a los patrones dos y tres.

3. Lee el estado del consentimiento en un hit real

   Deniega todo, abre el panel de red y busca la solicitud al endpoint de recogida. El parámetro gcs indica el estado, y G100 significa que ambos tipos de almacenamiento están denegados. Ahora comprueba si esa misma solicitud lleva un identificador de cliente. Un ping denegado con un id adjunto es el patrón tres.

4. Abre el cliente de GA4 de tu contenedor de servidor

   Si usas etiquetado del lado del servidor, mira el ajuste de gestión de cookies del cliente. Server Managed significa que el contenedor está acuñando identificadores propios, dijera lo que dijera el estado del consentimiento a la entrada.

5. Comprueba cuándo se dispara el estado por defecto

   El estado por defecto tiene que definirse antes de que se ejecute la etiqueta de Google, en todas las páginas, incluida la primera de la visita. Cualquier cosa más tarde y el primer hit de la sesión sale con un estado que nadie eligió.

Qué puedes recuperar de verdad

Una parte de esto es el precio honesto del consentimiento y no va a desaparecer. En las implementaciones de clientes de Amplio Data solemos ver alrededor de un 34% de las sesiones detrás del banner, y entre un 20 y un 40% de las conversiones perdidas recuperables una vez que Consent Mode v2 y el etiquetado del lado del servidor están bien montados. Las cifras son rangos medidos en implementaciones de clientes de Amplio Data, no una garantía. La recuperación depende de tu mezcla de tráfico, tus regiones y de cómo estén configuradas tus etiquetas.

Conviene decirlo claro, porque las páginas de los proveedores dan a entender lo contrario: el modelado no vacía el grupo Unassigned. Rellena huecos en los informes estándar para tráfico que nunca recogiste. No le pone un origen a una sesión que llegó sin él. Si quieres la foto completa de qué sobrevive a un rechazo, lo tratamos en qué pasa con tus datos de GA4 cuando los usuarios rechazan las cookies.

La versión corta

Unassigned después de un banner son tres problemas distintos bajo una misma etiqueta. El primero es el coste real de una aceptación tardía y se reduce con URL passthrough. El segundo es un fallo de orden en las etiquetas y se delata con conversiones sin origen. El tercero es un ajuste del lado del servidor que deshace en silencio la denegación que debía respetar. Revisa cómo está montado todo antes de dar por buena la explicación tranquilizadora.

Velo envía la señal de consentimiento con la forma que Google espera y te muestra lo que transmite realmente cada estado, así que un fallo como el tercero se ve el primer día y no después de un mes de Unassigned. El mecanismo está en la página de producto.

Si tu problema con Unassigned no tiene forma de consentimiento, el equipo que está detrás de Velo mantiene la lista completa de causas, etiquetado de enlaces y reglas de canal incluidos, en por qué el tráfico de GA4 aparece como Unassigned en el blog de Amplio Data.