Por qué tu tráfico de GA4 aparece como Unassigned tras poner un banner

Todos los artículos

Unassigned no es tráfico perdido. Es tráfico que GA4 sí recibió pero no pudo atribuir a ningún canal. Cuando publicas un banner, suele tener una de tres causas. El consentimiento llega a mitad de la visita y el origen ya se ha perdido. La sesión nunca registró un session_start. O una configuración en servidor devuelve una identidad a pings que tenían que seguir siendo anónimos.

Unassigned significa recogido, no perdido

Un visitante que nunca da su consentimiento, en una web que condiciona bien sus etiquetas, no genera ningún evento. Eso se nota en un total de sesiones más bajo, no en una fila del cajón Unassigned. Unassigned aparece cuando GA4 sí tiene eventos de una sesión pero no puede encajarlos en ninguna definición de canal: no hay parámetros de campaña, no hay un referrer aprovechable o no hay un inicio de sesión del que colgar un origen.

Así que el mensaje tranquilizador de casi todas las páginas de ayuda de los proveedores de consentimiento, que Unassigned demuestra que el banner está haciendo su trabajo, vale para el primero de los casos que vienen a continuación, pero no para los otros dos. En esos se está recogiendo algo en un formato que GA4 no puede usar, y eso hay que arreglarlo, no darlo por bueno.

Primer caso: el consentimiento llega a mitad de la visita

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

Este caso es real y, en parte, inevitable. También es el que puedes acotar. Con URL passthrough activado, los identificadores de clic de los anuncios de Google van pasando de página en página en la URL mientras las cookies están denegadas, así que un visitante que acepta tarde sigue llegando con algo que se puede atribuir. Que tengas siquiera esa opción depende del modo que uses, algo que explicamos en Consent Mode básico o avanzado: ¿cuál estás usando?.

Segundo caso: la sesión nunca registró su inicio

La asignación de canal depende del primer evento de la sesión. Hay dos configuraciones que lo rompen. La etiqueta de configuración y las de eventos están condicionadas de forma distinta, o el valor por defecto del consentimiento se fija cuando la etiqueta de Google ya se ha disparado. En ambos casos, el primer evento que recoge la sesión es algo completamente distinto: un envío de formulario, un scroll, una compra.

La pista son sesiones Unassigned que contienen conversiones. Actividad real, sin origen. Eso es un fallo de configuración, no una consecuencia de la privacidad, y es de la misma familia que las caídas repentinas de las que hablamos en Por qué tus conversiones de GA4 cayeron de golpe.

Tercer caso: a los pings denegados se les da una identidad

Este es el caso del que nadie escribe, y el que más rápido inunda una propiedad. En una configuración de Google Tag Manager en servidor, el cliente de GA4 puede gestionar sus propias cookies. Si se deja en el ajuste Server Managed, el contenedor escribe un identificador de origen propio y lo añade a las peticiones entrantes, incluidos los pings sin cookies que se enviaron precisamente porque se había denegado el consentimiento.

Esos pings llegan ahora con un identificador estable. En lugar de alimentar el modelado, que es para lo que está el tráfico denegado, se cuentan como sesiones. No llevan datos de campaña, porque no se permitió guardar ninguno, así que todos acaban en Unassigned. Su volumen sigue a tu tasa de rechazo y aparece a los pocos días de publicar el banner, y por eso la culpa se la lleva el banner.

Lo encontramos al rehacer el consentimiento de una web en producción, después de semanas viendo crecer sin explicación el cajón Unassigned del cliente. El arreglo fue un solo 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 el motivo por el que pasarte a un servidor no te permite quitar el banner, algo que tratamos en ¿Necesitas banner de cookies si usas etiquetado en servidor?.

Cómo saber cuál tienes

1. Compara la forma, no el total

   Comprueba si Unassigned ha crecido o si simplemente han bajado tus totales y la mezcla de canales sigue igual. Un número más bajo con la misma mezcla es el consentimiento funcionando como debe. Un cajón nuevo que el mes pasado no estaba es un problema de configuración.

2. Busca conversiones dentro de Unassigned

   Crea una exploración con el origen y medio de la sesión y pon al lado tus eventos clave. Una aceptación tardía deja sesiones con poca actividad; las conversiones completas sin origen apuntan, en cambio, al segundo y al tercer caso.

3. Mira el estado de consentimiento en un hit real

   Recházalo todo, abre el panel de red y busca la petición al endpoint de recogida. El parámetro gcs indica el estado, y G100 significa que los dos tipos de almacenamiento están denegados. Ahora comprueba si esa misma petición lleva un identificador de cliente. Un ping denegado con un id es el tercer caso.

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

   Si usas etiquetado en servidor, revisa el ajuste de gestión de cookies del cliente. Server Managed significa que el contenedor está generando sus propios identificadores, dijera lo que dijera el estado de consentimiento a la entrada.

5. Comprueba cuándo se fija el valor por defecto del consentimiento

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

¿Puede el modelado cubrir el hueco?

Parte de esto es el precio honesto del consentimiento y no va a desaparecer. Un visitante que rechaza en una web bien configurada no deja ninguna sesión, y cuántos lo hacen depende de tus regiones, de tu audiencia y del diseño de tu banner. Para medirlo en tu propiedad, mira la tasa de consentimiento en tu CMP o compara las sesiones de GA4 con los registros de peticiones de tu servidor o tu CDN. Google puede modelar parte de ese hueco, pero solo cuando la propiedad alcanza los umbrales de datos que describe la documentación de Google sobre el modo de consentimiento. El resultado es una estimación, no tráfico que alguien haya observado.

Hay algo que conviene decir claro, porque las páginas de los proveedores dan a entender lo contrario: el modelado no vacía el cajón Unassigned. Rellena huecos en los informes estándar correspondientes a tráfico que nunca recogiste. No le pone origen a una sesión que llegó sin él. Si quieres ver en conjunto qué sobrevive a un rechazo, lo tratamos en Qué pasa con tus datos de GA4 cuando rechazan las cookies.

La versión corta

El Unassigned que aparece tras un banner son tres problemas distintos bajo la 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 en el orden de las etiquetas y se delata con conversiones sin origen. El tercero es un ajuste del servidor que deshace en silencio la denegación que debía respetar. Revisa la configuración antes de quedarte con la explicación tranquilizadora.

Velo envía la señal de consentimiento con el formato que espera Google y te enseña qué transmite realmente cada estado. Así, un fallo como el tercero se ve el primer día y no después de un mes de Unassigned. Cómo funciona lo tienes en la página de producto.

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