Unassigned en Google Analytics: qué es, por qué aparece y cómo arreglar el tráfico no asignado

El canal “Unassigned” en Google analytics es el cajón donde acaba todo el tráfico que GA4 no puede encajar en ningún canal del Default Channel Group: ni Organic, ni Paid Social, ni Email, ni Direct… nada. Cuando “Unassigned” se dispara, los informes dejan de explicar bien qué campaña trae negocio y cuál no.

Este problema se ve cada vez más en proyectos de España: ecommerce con checkout en Redsys o PayPal, negocios locales con campañas de Meta + WhatsApp, medios con newsletters sin UTMs coherentes y apps que mezclan web + Measurement Protocol. El patrón se repite: la atribución se rompe y GA4 se rinde, enviando eventos a “Unassigned”.

El objetivo de este artículo es muy claro:

• explicar qué es exactamente Unassigned,

• mostrar dónde suele explotar según el tipo de proyecto,

• y dejar una lista de soluciones 80/20 para reducirlo al mínimo razonable.

Qué es el canal “Unassigned” en Google Analytics y dónde verlo

Cómo funciona el Default Channel Group en Google Analytics

GA4 agrupa las sesiones y eventos en canales utilizando el Default Channel Group. Cada canal (Organic Search, Paid Social, Email, Direct, etc.) tiene reglas basadas en:

• source / medium,

• etiquetas de campaña (UTMs),

• y en algunos casos el tipo de tráfico (por ejemplo, “Organic Social” si el medio es social o social_network).

Cuando los datos de una sesión no cumplen ninguna de esas reglas, GA4 no sabe si se trata de tráfico orgánico, pago, email, referral, etc. En ese caso:

El sistema asigna esa sesión o evento al canal “Unassigned” dentro del grupo de canales predeterminado.

En otras palabras:

• Si hay datos de origen, pero no encajan en ningún canal conocido → Unassigned.

• Si no hay datos suficientes de origen/medio → puede aparecer (not set) y terminar también en Unassigned.

Esto se aplica a:

• Session default channel group,

• User default channel group,

• y en algunos informes, al Event default channel group.

Dónde aparece “Unassigned” en los informes de adquisición

Los sitios principales donde suele verse:

• Informes > Adquisición > Adquisición de tráfico

  • Dimensión: Grupo de canales predeterminado de la sesión.

  • Fila “Unassigned” mostrando sesiones, usuarios y conversiones.

• Informes > Adquisición de usuarios

  • Mismo enfoque, pero centrado en usuarios nuevos/recurrentes.

• Informes de conversión

  • Cuando se analiza por canal y parte de las conversiones queda asignada a “Unassigned”.

• Exploraciones

  • Con tablas personalizadas que combinen canal, fuente/medio, campaña, país, etc.

En muchos proyectos, el primer susto llega cuando se ve algo como:

• “Unassigned” = 30–40 % de las compras de un ecommerce.

• “Unassigned” = buena parte de las conversiones de formularios en campañas de Meta.

Este volumen no significa que los usuarios vengan “de la nada”; significa que GA4 no consigue encajar el tráfico en ningún canal con las reglas actuales.

Por qué GA4 manda tráfico a “Unassigned”

En la práctica, hay decenas de causas posibles, pero la mayoría de los problemas se explican con unas pocas que se repiten constantemente.

UTMs mal configuradas o inventadas (y cómo las interpreta GA4)

El primer sospechoso casi siempre son las UTMs:

• utm_medium con valores que GA4 no reconoce:

  • paid-social, social_paid, cpc-meta, ig_ads, whatsapp, etc.

• Campañas donde unas URLs llevan UTMs y otras no.

• UTMs mezcladas en por trabajar con varios equipos/agencias:

  • unas usan email, otras e-mail, otras newsletter;

  • unas usan paid_social, otras social, otras meta_cpc.

Cuando source/medium no coincide con ninguna regla de canal, GA4 no puede clasificar la sesión y la envía a Unassigned.

Ejemplo típico en un ecommerce de moda en España:

• Campañas de Meta con enlaces:

  • utm_source=facebook

  • utm_medium=paid-social

• GA4 no tiene un canal con regla medium="paid-social", así que esas sesiones no entran en Paid Social → gran parte termina en “Unassigned”.

Redirecciones y acortadores que se comen parámetros

Segunda causa recurrente: las UTMs existen, pero se pierden.

Casos habituales:

• Redirecciones de /landing → /es/landing sin conservar parámetros.

• Migraciones mal resueltas de http → https o de midominio.com → www.midominio.com.

• Acortadores o herramientas de emailing que reescriben la URL y se quedan la versión sin UTMs.

El resultado es:

• El clic se genera con ?utm_source=...,

• pero la página que realmente carga el usuario ya va sin UTMs,

• por lo que GA4 registra la sesión como Direct, Referral o, si no encaja en nada, Unassigned.

En proyectos de lead gen, esto se ve mucho en:

• landings creadas con constructores externos (tipo “/go/landing-name”),

• redirecciones internas mal configuradas al entrar por campañas.

Cross-domain y pasarelas de pago que rompen la sesión

En ecommerce, el gran foco de “Unassigned” suele estar en el checkout:

• El usuario navega por www.tienda.es.

• Pasa a un dominio o subdominio distinto para pagar:

  • tpv.redsys.es,

  • www.paypal.com,

  • checkout.stripe.com,

  • checkout.tienda.es.

• Vuelve a la página de confirmación en el dominio original.

Si el cross-domain tracking y la configuración de referencia no están bien definidos, GA4 puede:

• perder la sesión original,

• crear una nueva sesión con source/medium vacío o poco claro,

• y terminar etiquetando la conversión como Referral o Unassigned.

En muchos ecommerce españoles se ha visto el mismo patrón:
compras desde campañas de Google Ads o Meta que en Analytics aparecen como “Unassigned” porque la sesión se rompió en la pasarela.

Consent Mode, CMP y límites del modelado

Con Consent Mode y las plataformas de consentimiento (CMP), parte del tráfico en Europa (y por tanto en España) se mide con:

• datos parciales,

• eventos sin cookies completas,

• o sólo señales agregadas/modeladas.

En estos casos, GA4 puede:

• registrar eventos de conversión sin suficiente información para reconstruir la fuente/medio,

• modelar parte de la atribución,

• y dejar una fracción del tráfico y de las conversiones en Unassigned.

Esa parte no es “arreglable” con UTMs; forma parte de las nuevas reglas del juego en un entorno con más privacidad.

Dónde explota más “Unassigned” según el tipo de proyecto

Ecommerce (Shopify / Woocommerce / custom): checkout, pasarelas y subdominios

En ecommerce, “Unassigned” suele explotar en:

• Eventos de purchase.

• Sesiones que pasan por:

  • pasarelas de pago externas (Redsys, PayPal, Stripe Checkout…),

  • subdominios tipo checkout.midominio.es,

  • soluciones headless donde el recorrido se reparte entre varios dominios.

Casos frecuentes en tiendas online de España:

• Tienda en Shopify conectada a Redsys:

  • el checkout rompe el contexto y la compra vuelve a GA4 sin una fuente/medio claros.

• Ecommerce en WooCommerce con plugins de pasarela que redirigen por varias URLs antes de la confirmación.

Si no se hace:

• configuración correcta de cross-domain,

• exclusión adecuada de referencias,

• y control del session_id en server-side/Measurement Protocol,

es habitual ver que “Unassigned” concentra una parte importante del revenue.

Proyectos de captación de leads: formularios, call tracking y WhatsApp

En sitios de captación de leads (inmobiliarias, academias, servicios profesionales, etc.), Unassigned suele crecer por:

• Campañas de Meta / WhatsApp con UTMs poco estándar.

• Landings con redirecciones intermedias:

  • click en anuncio → lander → redirección a la página del formulario.

• Integraciones de call tracking que modifican URLs o cargan el formulario por iframes.

Si algunas URLs tienen UTMs bien montadas y otras van “en limpio”, GA4 mezcla sesiones y termina perdiendo parte de la información de origen, sobre todo cuando hay hops intermedios por dominios externos.

Medios, contenidos y afiliación: newsletters, email y push con UTMs inconsistentes

En proyectos de contenido, medios o afiliación, Unassigned no siempre duele en revenue, pero sí en visibilidad real de canales:

• Newsletters que mezclan utm_medium=email, newsletter, boletin…

• Campañas de web push configuradas con medium inventados (push, notificacion, etc.).

• Artículos con enlaces de afiliación que pasan por varios dominios de tracking sin preservar las UTMs de origen.

El resultado:
parte del tráfico de email y push termina sin encajar en las reglas de canal y aparece como Unassigned.

Proyectos web + app: Measurement Protocol, eventos server-side y pérdida de contexto

En proyectos híbridos (web + app) se usan con frecuencia:

• SDK de GA4/Firebase en app,

• etiquetas web en sitio,

• y Measurement Protocol o server-side para enviar eventos (compras, registros, etc.).

Si esos eventos se envían:

• sin client_id o user_id coherente,

• sin session_id correcto,

• o sin parámetros de campaña suficientes,

GA4 recibe conversiones “sueltas”, difíciles de asociar a una fuente/medio y a un canal concreto, por lo que acaban en “Unassigned”.

Cómo diagnosticar el tráfico Unassigned paso a paso en GA4

Filtrar el canal Unassigned y ver fuentes/medios problemáticos

Primer paso: aislar Unassigned.

1. Ir a Informes > Adquisición > Adquisición de tráfico.

2. En la tabla, buscar el canal “Unassigned” en la dimensión Grupo de canales predeterminado de la sesión.

3. Hacer clic en la fila de Unassigned para filtrar solo ese tráfico.

4. Añadir una dimensión secundaria:

   • session source / medium

   • o session campaign

El objetivo es responder:

• ¿Qué source/medium se repiten dentro de Unassigned?

• ¿Hay UTMs inventadas o inconsistentes?

• ¿Hay dominios de pasarela o subdominios de checkout entre las fuentes?

Este paso suele revelar rápidamente problemas como:

• source=(not set) / medium=(not set)

• mediums raros (whatsapp, meta_paid, push, etc.)

• referencias de pasarela (redsys, paypal, stripe) entre las conversiones unassigned.

Detectar patrones por campaña, medio y landing

Con Unassigned filtrado:

• Revisar qué campañas concentran más tráfico no asignado.

• Ver qué páginas de destino (landing pages) reciben esas visitas.

Preguntas clave:

• ¿Es siempre el mismo conjunto de campañas de Meta/Google Ads?

• ¿Salen muchas sesiones unassigned en landings que pasan por redirecciones?

• ¿Coinciden las landings con funnels que incluyen checkout o dominios intermedios?

En un ecommerce, por ejemplo, puede verse que:

• todas las compras desde campañas “Meta – Remarketing España” aparecen como Unassigned,

• y que la landing principal tiene una redirección de midominio.es/meta-oferta a midominio.es/es/oferta/.

Ese tipo de patrón apunta directamente al problema: UTMs que se pierden en la redirección.

Separar lo que es corregible de lo que es “by design” en GA4

No todo el tráfico Unassigned se puede “curar”:

Corregible:

• UTMs mal puestas o inconsistentes.

• Redirecciones que se comen parámetros.

• Cross-domain mal configurado.

• Eventos server-side sin contexto de sesión.

Difícil o imposible de eliminar:

• Sesiones donde el usuario bloquea cookies o rastreo de forma muy agresiva.

• Parte del modelado introducido por Consent Mode en la UE.

• Casos extremos donde la sesión se fragmenta y GA4 recibe eventos totalmente aislados.

La clave está en reducir el Unassigned “evitable” y aceptar que un cierto porcentaje será normal con las restricciones actuales.

Soluciones prácticas para reducir “Unassigned” en GA4

Definir un estándar de UTMs alineado con las reglas de canal de GA4

Primer bloque de trabajo: limpiar las UTMs.

Recomendaciones:

• Elegir un estándar para utm_medium alineado con las reglas de canal de GA4:

  • cpc o ppc para Paid Search,

  • paid_social para Paid Social,

  • email para Email,

  • display para Display, etc.

• Documentar un naming convention y compartirlo con todas las personas/agencias que etiquetan campañas.

• Auditar con regularidad:

  • exportar las URLs de campaña,

  • agrupar por utm_medium y utm_source

  • buscar valores “creativos” que no encajen en ningún canal.

En muchos negocios basta con estandarizar UTMs en:

• Meta Ads,

• Google Ads (cuando no se usa auto-tagging),

• email marketing,

para reducir gran parte del Unassigned.

Corregir redirecciones, acortadores y configuraciones cross-domain

Siguiente foco: que las UTMs lleguen vivas a la landing real.

Checklist:

• Revisar con herramientas de inspección (o a mano) todas las redirecciones intermedias:

  • comprobar si los parámetros utm_ se mantienen hasta la URL final.

• Ajustar reglas en el servidor o en el CMS para que las redirecciones no borren la query string.

• Revisar acortadores y herramientas de emailing:

  • algunos añaden sus propios parámetros pero conservan UTMs;

  • otros reescriben la URL y las pierden.

Para cross-domain:

• Configurar dominio(s) vinculados en GA4 y en la configuración de etiquetas para que la sesión pueda mantenerse entre dominios.

• Revisar la lista de exclusión de referencias (referral exclusion) para que pasarelas de pago no corten la sesión con una nueva fuente.

Ajustar el tracking en pasarelas, subdominios y apps

En entornos con checkout complejo o app:

• Asegurarse de que el ID de medición y la configuración de GA4 es consistente en todas las partes del funnel.

• Verificar que:

  • el config tag de GA4 se dispara antes que otros eventos,

  • session_start se genera correctamente,

  • no se generan sesiones “nuevas” sin necesidad.

• En eventos enviados por Measurement Protocol:

  • incluir client_id y/o user_id,

  • mantener session_id coherente con la sesión de origen,

  • enviar parámetros de campaña cuando estén disponibles.

Esto es especialmente relevante en apps bancarias, travel, delivery o retail muy presentes en España, donde una parte del proceso ocurre en app y otra en web.

Qué esperar (y qué no) del Consent Mode

El Consent Mode ayuda a cumplir normativa de privacidad y seguir midiendo en entornos con cookies limitadas, pero no es una varita mágica para eliminar Unassigned.

Algunos puntos clave:

• Incluso con Consent Mode bien configurado, habrá eventos con datos incompletos de atribución.

• Una parte de las conversiones se asignará mediante modelado y otra parte puede quedar sin suficiente información para entrar en un canal concreto.

• El objetivo no es llevar Unassigned a cero, sino a un nivel razonable:

  • reducir el porcentaje que se debe a errores configurables (UTMs, redirecciones, cross-domain),

  • aceptar el resto como coste de hacer analítica en un entorno con más privacidad.

Opciones avanzadas: cuando el problema está en el backend

Measurement Protocol: client_id, session_id y timestamp_micros bien usados

Cuando se envían eventos con Measurement Protocol:

• Si llega una compra sin client_id ni session_id,

• o con un timestamp_micros muy desalineado respecto a la sesión web,

GA4 puede registrar la conversión como un evento casi “huérfano”, difícil de asociar a un canal concreto, y terminar en Unassigned.

Buenas prácticas:

• Mantener un mapa claro de cómo se construyen y transmiten estos IDs.

• Evitar enviar conversiones muy tarde y sin contexto (por ejemplo, reenvíos masivos desde backend horas o días después).

• Probar siempre con entornos de test para ver cómo se refleja el canal en los informes.

Configuración de la etiqueta GA4 en GTM (config tag y session_start)

En implementaciones con Google Tag Manager:

• Garantizar que la etiqueta de configuración de GA4 (config tag):

  • se carga en todas las páginas clave del funnel,

  • se dispara antes que otros eventos personalizados.

• Evitar duplicidades de session_start y otras etiquetas que podrían partir la sesión en dos sin necesidad.

Cuando el orden de disparo es incorrecto o faltan vistas intermedias, GA4 puede terminar con:

• sesiones rotas,

• eventos sin contexto,

• y más tráfico en Unassigned.

Reporting Identity y grupos de canales personalizados para reclasificar tráfico

Una vez arreglado lo técnico, todavía es posible mejorar la lectura de datos:

• Revisar la Reporting Identity (mezcla de User ID, device ID, modelado) para entender cómo GA4 reconstruye los journeys.

• Crear Custom Channel Groups para:

  • agrupar medios que la definición estándar no interpreta bien,

  • reclasificar tráfico que terminaría en Unassigned o en “Other”.

Esto no arregla errores de etiquetado, pero sí ayuda a presentar datos más claros a equipos de marketing y negocio.

Cómo priorizar qué arreglar primero

Orden de impacto: de las quick wins al trabajo de fondo

Para no perderse entre posibles causas, se puede seguir este orden:

1. UTMs y reglas de canal

   • Normalizar utm_medium y utm_source según las reglas de GA4.

2. Redirecciones y pérdidas de parámetros

   • Revisar las rutas más usadas por campañas de pago y email.

3. Pasarelas y cross-domain

   • Ajustar configuración en ecommerce y funnels de pago.

4. Measurement Protocol / server-side

   • Verificar IDs y contexto en eventos enviados desde backend.

5. Consent Mode y modelado

   • Aceptar parte del Unassigned como derivado de privacidad.

Además, conviene excluir “hoy y ayer” del análisis para evitar ruido de procesamiento, ya que GA4 puede tardar horas en clasificar correctamente el tráfico y mostrar un volumen temporalmente inflado de Unassigned.

Cómo traducir “Unassigned” a lenguaje de revenue y campañas

A negocio no le preocupa tanto el nombre del canal como las respuestas:

• ¿Cuánto dinero viene de Google Ads?

• ¿Qué ROI tienen las campañas de Meta?

• ¿Realmente funcionan las newsletters?

Una forma clara de explicarlo:

• “Ahora mismo, un X % del revenue aparece como Unassigned, por lo que los canales reales están infravalorados.”

• “Arreglando UTMs y checkout, se puede reasignar gran parte de ese porcentaje a Paid Social, Paid Search o Email.”

Ejemplo típico:

• Un ecommerce de decoración ve que 35 % del revenue está en Unassigned.

• Tras revisar UTMs de Meta y redirecciones del checkout, ese porcentaje baja a 10–12 %, y se comprueba que la mayoría de ventas venían realmente de Paid Social y Email.

Qué nivel de “Unassigned” es razonable en cada tipo de proyecto

No existe una cifra mágica, pero sí una referencia práctica:

• En entornos bien etiquetados, con Consent Mode y privacidad fuertes, es normal que exista una parte de Unassigned.

• Cuando más del 20–30 % de las conversiones se concentra en Direct + Unassigned, suele ser señal de problemas de etiquetado o implementación.

En ecommerce y lead gen de España, la prioridad debería ser:

• bajar Unassigned a un nivel que permita entender correctamente qué canales generan negocio,

• y mantener una revisión periódica de UTMs y redirecciones para que no vuelva a crecer sin control.

Preguntas frecuentes

¿Qué es exactamente “Unassigned” en Google Analytics 4?

Es el canal donde GA4 agrupa las sesiones y eventos que no cumplen las reglas de ningún canal predeterminado del Default Channel Group. Suele implicar problemas de etiquetado (UTMs), implementación o limitaciones de datos por privacidad.

¿Dónde se ve el tráfico Unassigned en los informes de GA4?

Principalmente en:

• Adquisición de tráfico (Session default channel group).

• Adquisición de usuarios.

• Algunos informes de conversiones y exploraciones personalizadas donde se use el grupo de canales como dimensión.

¿Cuáles son las causas más comunes del tráfico Unassigned?

Las más frecuentes:

• UTMs mal puestas o inventadas (utm_medium que GA4 no reconoce).

• Redirecciones y acortadores que eliminan parámetros.

• Cross-domain y pasarelas de pago mal configuradas.

• Eventos enviados con Measurement Protocol sin contexto suficiente.

• Limitaciones de datos por Consent Mode y bloqueadores.

¿Por qué en ecommerce gran parte del revenue aparece como Unassigned?

Porque muchos funnels de compra pasan por dominios externos (Redsys, PayPal, Stripe, etc.) o utilizan subdominios de checkout. Si no se configura bien el tracking entre todos esos puntos, la sesión se corta y GA4 acaba registrando la compra sin canal claro.

¿Por qué en campañas de Meta/WhatsApp sale tanto tráfico Unassigned?

Suele deberse a:

• UTMs poco estándar (utm_medium=whatsapp, meta_paid, etc.),

• landings con redirecciones que se comen los parámetros,

• integraciones con formularios o call tracking que modifican URLs.

Armonizar UTMs y revisar las redirecciones suele reducir mucho este problema.

¿Cómo afecta el Consent Mode al canal Unassigned?

Con Consent Mode, GA4:

• recibe menos datos individuales,

• aplica modelado para parte de las conversiones,

• y puede dejar una fracción del tráfico sin información suficiente para clasificarse en un canal concreto.

Ese porcentaje no desaparece completamente, pero puede limitarse si lo demás está bien implementado.

¿Se puede eliminar por completo el tráfico Unassigned?

No de forma realista. Lo razonable es:

• minimizar la parte causada por errores de etiquetado y de implementación,

• y aceptar un nivel residual ligado a restricciones de privacidad, bloqueadores y casos extremos.

Conclusión

El canal Unassigned en GA4 no es un fallo del sistema, sino una forma de avisar de que algo en la configuración no encaja con las reglas de canal o no llega completo.

En la práctica, el enfoque más útil es:

• Tratar Unassigned como un indicador de salud del etiquetado y del tracking.

• Atacar primero el 80/20 de causas: UTMs, redirecciones, pasarelas, cross-domain.

• Aceptar que, en un contexto de privacidad como el de la UE y España, siempre habrá una fracción que dependa del Consent Mode y del modelado.

Cuando el trabajo está bien hecho, el canal Unassigned deja de ser un agujero negro y pasa a ser un ruido residual controlado. A partir de ahí, los informes de Google Analytics vuelven a responder a la pregunta importante: qué canales y campañas generan negocio real.