Por qué el tráfico directo es el cajón de todo lo que la analítica no pudo atribuir

¿Qué es el tráfico directo?

Las herramientas de analítica archivan una sesión como tráfico directo cuando la petición llega sin referrer y sin parámetros de campaña, lo que convierte esa etiqueta en un registro de datos de atribución que faltan, no en un registro de gente escribiendo tu URL en la barra de direcciones. Google Analytics 4 enuncia la regla en las definiciones de su grupo de canales por defecto: una sesión es Direct cuando "Source exactly matches '(direct)' AND Medium is one of ('(not set)', '(none)')". Lee la cifra como un hueco de medición y averigua cuál de las causas de abajo lo está llenando.

¿Por qué Direct no es un canal?

Direct no es un canal, es el cajón de todo lo que la herramienta no pudo atribuir. Cualquier otro canal se define por la evidencia que llevaba la petición, un hostname de origen o un valor utm_medium, mientras que Direct se define por la ausencia de esa evidencia, y una ausencia no lleva ningún comportamiento de marketing adjunto. Trata una línea de Direct que sube como una alerta de instrumentación y audita los enlaces que la gente está pulsando de verdad, igual que auditarías el tráfico que GA4 nunca llega a registrar.

GA4 lleva la distinción un paso más allá. Su cajón Unassigned es "el valor que Analytics usa cuando no hay otras reglas de canal que coincidan con los datos del evento", así que una sesión que lleva una fuente pero no coincide con ninguna regla va a Unassigned, mientras que una sesión que no lleva nada va a Direct.

¿Qué aterriza realmente en el cajón de directo?

Siete mecanismos quitan el referrer o la etiqueta de campaña antes de que tu script se ejecute, y cada uno produce una sesión indistinguible del clic en un marcador. El navegador decide la mayoría de ellos, así que ninguna configuración de etiquetas recupera la fuente.

Causa	Qué llega a tu servidor	Por qué
Una página HTTPS enlaza a una página HTTP	Sin cabecera Referer	El algoritmo de Referrer Policy del W3C devuelve sin referrer en una degradación de seguro a inseguro
El sitio de origen envía Referrer-Policy: no-referrer	Sin cabecera Referer	MDN: "La cabecera Referer se omitirá: las peticiones enviadas no incluyen ninguna información de referrer"
El enlace lleva rel="noreferrer"	Sin cabecera Referer	MDN: la palabra clave le indica al navegador "que omita la cabecera Referer y que por lo demás no filtre ninguna información de referrer"
Una app nativa o un cliente de mensajería abre el enlace	Sin cabecera Referer	El toque no se originó en un documento HTML, así que no hay dirección de origen que el cliente pueda enviar
Un enlace dentro de un PDF o de un documento de Office	Sin cabecera Referer	El lector entrega la URL al navegador como una navegación nueva, no como un salto de documento a documento
Una cadena de redirecciones que pasa por un salto HTTP o un servicio no-referrer	Referrer perdido en ese salto	La especificación de Referrer Policy reinicia la política de referrer de la petición en cada respuesta de redirección, así que un salto puede tirarla para el resto de la cadena
Un enlace de correo sin etiquetar o el escaneo de un código QR	Sin referrer, sin UTM	El cliente de correo o la app de cámara abre la URL sin nada adjunto, y tú no añadiste parámetros de campaña

¿Cómo eliminan el referrer las políticas de referrer?

Una política de referrer es una regla por petición que decide cuánto de la URL de origen pone el navegador en la cabecera Referer. La especificación Referrer Policy del W3C fija strict-origin-when-cross-origin como política de referrer por defecto: envía el origen, la ruta y la cadena de consulta en peticiones del mismo origen, solo el origen en peticiones entre orígenes de HTTPS a HTTPS, y nada en absoluto en una degradación de HTTPS a HTTP. Bajo no-referrer la cabecera no aparece nunca, y bajo origin recibes https://example.com/ sin ruta, suficiente para nombrar el canal pero no la página.

La regla de degradación sorprende a los equipos. El algoritmo de la especificación devuelve sin referrer "si referrerURL es una URL potencialmente confiable y la URL actual de la petición no es una URL potencialmente confiable", así que una sola URL sin HTTPS en cualquier punto de tu embudo convierte tráfico de referencia real en directo. Arréglalo sirviendo cada salto sobre HTTPS, y después lee qué le hacen las políticas de referrer del navegador a la analítica antes de culpar a la herramienta.

¿Por qué las apps, los PDFs y los códigos QR llegan como directo?

Las apps nativas, los lectores de documentos y las apps de cámara llegan como directo porque la cabecera Referer describe una navegación de documento a documento y ninguno de ellos parte de un documento. MDN define la cabecera como la que contiene "la dirección absoluta o parcial desde la que se ha solicitado un recurso", y un mensaje de Slack, un PDF con una lista de precios y un código QR impreso no tienen tal dirección que reportar. La solución es meter tú mismo la fuente en la URL.

Para eso están los parámetros de campaña. Añade utm_source y utm_medium al enlace antes de que entre en la presentación, el PDF, la newsletter o el generador de QR, y la sesión llega etiquetada aunque el referrer haya desaparecido. Flowsery lee esos parámetros en su seguimiento de campañas UTM, y la guía completa de parámetros cubre las reglas de nomenclatura que mantienen las etiquetas legibles en todo un equipo.

¿Cómo se calcula la proporción de tráfico directo?

La proporción de tráfico directo es el número de sesiones directas dividido entre el total de sesiones del mismo período, expresado en porcentaje. Úsala como medición de antes y después en un proyecto de etiquetado, no como referencia contra otros sitios, porque la cifra se mueve con tu mezcla de canales y con los navegadores de tus visitantes.

direct traffic share = (direct sessions / total sessions) x 100

Un sitio registra 42,000 sesiones en un mes y 9,660 de ellas son directas. 9,660 dividido entre 42,000 es 0.23, así que la proporción de tráfico directo es 23 por ciento. El equipo etiqueta cada enlace de la newsletter, pasa una redirección heredada de HTTP a HTTPS, y añade parámetros al código QR de su banner de conferencia. El mes siguiente directo cae a 5,880 de las mismas 42,000 sesiones. 5,880 dividido entre 42,000 es 0.14, una proporción del 14 por ciento, y los 9 puntos de diferencia ahora están en filas de correo y de eventos sobre las que puedes actuar. Cuenta las sesiones de la misma forma en los dos períodos, ya que las definiciones de sesión difieren entre herramientas y un cambio de definición por sí solo mueve el ratio.

Proporción de tráfico directo, antes y después del etiquetado

Antes del etiquetado23 %

Después del etiquetado14 %

¿Cómo se encoge el cajón de directo?

Encoger el cajón de directo es un proyecto de higiene de enlaces, no un ajuste de informes. Trabájalo en orden de volumen: etiqueta los enlaces de correo y newsletter, etiqueta cada enlace que pegues en Slack, LinkedIn o un hilo de comunidad, etiqueta los códigos QR y las URLs impresas, etiqueta los enlaces dentro de PDFs y presentaciones, y después audita tus cadenas de redirecciones en busca de cualquier salto que no sea HTTPS.

Después revisa qué envía hacia fuera tu propio sitio. Una cabecera Referrer-Policy: no-referrer en tus páginas te vuelve invisible en los informes de referencias de tus socios, una decisión de privacidad legítima siempre que la tomes de forma deliberada. Los editores que quieren seguir siendo atribuibles mantienen strict-origin-when-cross-origin y todos sus enlaces salientes sobre HTTPS.

¿Qué hay que revisar cuando el tráfico directo se dispara?

Un salto repentino en el tráfico directo apunta a un cambio en tus enlaces o en tu script de seguimiento, no a una oleada de gente recordando tu dominio. Revisa cuatro cosas en orden: una redirección nueva que tiró un parámetro de campaña, una cabecera Referrer-Policy añadida a tu sitio o al de un socio, una campaña que salió sin etiquetas UTM, y un script que empezó a dispararse antes de que se leyera la cadena de consulta.

Compara el pico contra la misma ventana en una segunda fuente de medición, porque las herramientas cuentan el mismo tráfico de forma distinta y una diferencia entre dos de ellas estrecha la búsqueda rápido.

Preguntas frecuentes

¿El tráfico directo significa que la gente escribió mi URL?

No. Las URLs escritas y los marcadores caen en directo, pero también cada sesión cuyo referrer fue eliminado por una política de referrer, una degradación de HTTPS a HTTP, un enlace con rel="noreferrer", una app nativa, un PDF o una redirección. Direct es el cajón de todo lo que la herramienta no pudo atribuir, y las URLs escritas son una entrada dentro de él.

¿Cuál es un porcentaje normal de tráfico directo?

No hay una referencia defendible, porque la proporción depende de tu mezcla de canales, de los navegadores de tus visitantes y de cuánto de tu inventario de enlaces lleva parámetros de campaña. Mide tu propia cifra, etiqueta tus enlaces, y vuelve a medir. El movimiento entre esas dos lecturas es la cifra que te dice algo.

¿Por qué subió mi tráfico directo después de una migración del sitio?

Las migraciones añaden saltos de redirección, y cada salto puede tirar el referrer o quitar la cadena de consulta que lleva tus parámetros UTM. La especificación Referrer Policy del W3C reinicia la política de referrer de una petición en cada respuesta de redirección, así que un salto mal configurado cambia el comportamiento del resto de la cadena. Sigue una URL de campaña real por cada redirección y confirma que los parámetros llegan al destino final.

¿GA4 trata Direct y Unassigned de la misma forma?

No. GA4 asigna Direct cuando "Source exactly matches '(direct)' AND Medium is one of ('(not set)', '(none)')", lo que significa que no llegó nada. Unassigned es "el valor que Analytics usa cuando no hay otras reglas de canal que coincidan con los datos del evento", lo que significa que llegó algo pero no coincidió con ninguna regla, lo que apunta a un utm_medium mal formado.

¿Puedo recuperar la fuente real de una sesión directa?

No después del hecho. La cabecera Referer o llegó o no llegó, y ningún procesamiento en el servidor reconstruye una cabecera que el navegador nunca envió. Recupera la fuente de aquí en adelante metiéndola en la URL como parámetros de campaña antes de compartir el enlace.

¿Pasarlo todo a HTTPS reduce el tráfico directo?

Elimina una causa. La política strict-origin-when-cross-origin por defecto no envía referrer cuando una página HTTPS enlaza a una página HTTP, así que cualquier URL HTTP en tu embudo convierte sesiones de referencia en directas. Servir cada página y cada salto de redirección sobre HTTPS restaura el origen en esas peticiones, y deja intactas las causas de app, PDF y QR.

¿Por qué aparece tráfico de Slack o LinkedIn como directo?

Un toque dentro de Slack o LinkedIn abre el enlace directamente desde la app, no desde una página HTML, así que el cliente no tiene ninguna dirección de referencia que enviar en el encabezado Referer. La sesión llega igual que un clic en un marcador, indistinguible de alguien que escribió tu URL. Añade utm_source y utm_medium a cada enlace antes de pegarlo en una app de chat o una publicación social, porque es la única forma de etiquetarlo antes de que el referrer desaparezca.

¿Qué le hace rel="noreferrer" a mis informes de tráfico?

La palabra clave noreferrer le indica al navegador que omita el encabezado Referer y no filtre ninguna información de referencia, el mismo efecto que una política no-referrer completa tiene sobre un sitio entero. Un clic en ese enlace cae en el cajón de directo aunque haya empezado en una página tuya, indistinguible de una visita desde un marcador. Añade parámetros de campaña al propio enlace si quieres que la fuente siga apareciendo en tus informes.

¿Debería poner Referrer-Policy: no-referrer en mi propio sitio?

Ese encabezado vuelve tu sitio invisible en el informe de referidos de cualquier socio, porque ninguno de tus clics salientes llevará ya un encabezado Referer. Es una decisión de privacidad legítima siempre que la tomes a propósito, no un ajuste por defecto que dejaste sin revisar. Los sitios que quieren que sus enlaces salientes sigan siendo atribuibles mantienen strict-origin-when-cross-origin y sirven cada enlace por HTTPS.

¿Cuál es la diferencia entre las políticas origin y no-referrer?

Con origin el navegador todavía envía un encabezado Referer, pero recortado al dominio, algo como https://example.com/ sin ruta ni cadena de consulta. Con no-referrer el encabezado no aparece nunca, así que la petición parece una URL escrita a mano. origin todavía nombra qué sitio envió el clic, no-referrer borra la fuente por completo.