16 formas de reducir el tráfico directo en Google Analytics

Actualizado: 24 de julio de 2023. El tráfico directo en Google Analytics es a menudo mal entendido. Si crees que el tráfico directo es el que introduce la dirección de tu sitio web en la barra de direcciones o accede a él a través de los marcadores, tengo malas noticias. En realidad, eso es solo una fracción de lo que el tráfico directo es en realidad.

La primera razón de esta confusión radica en el nombre mismo. Directo. ¿Es realmente directo? En Google Analytics, el tráfico directo realmente significa «No sé de dónde vino ese visitante». Puede ser de la barra de direcciones, de los marcadores de tu navegador, del correo electrónico, del chat/mensajero, etc. Debería llamarse «desconocido» en su lugar. Pero este despotrique es para otro momento.

Hay muchas razones que afectan a este tipo de tráfico y quería abordar las formas de reducir el tráfico directo en Google Analytics. Además, en la segunda mitad de esta entrada de blog, mencionaré cosas que no tienes control y que tendrás que aceptar.

Tabla de contenidos

Una rápida visión general del tráfico directo

Hay varias cosas que ayudan a Google Analytics a determinar de dónde ha venido el visitante a su sitio web:

• Parámetros UTM en la URL como utm_medium, utm_source, utm_campaign, etc.
• Referrer, también conocido como el URL de la página anterior (aunque hay que tener en cuenta que hay muchas limitaciones relacionadas con la privacidad aquí)
• gclid y otros parámetros similares que indican que un visitante ha venido de campañas publicitarias pagadas
• La fuente de tráfico se sobrescribe en el nivel de código/etiqueta

Si ninguno de estos parámetros devuelve valores significativos (o si simplemente no existen) cuando un visitante llega a su sitio web, dicha sesión se atribuye al tráfico (directo) de Google Analytics.

¿Puedes ver cómo el nombre directo es confuso aquí? En realidad, significa que una fuente de tráfico es simplemente desconocida.

«¡Pero el tráfico directo es una prueba de nuestra fuerte marca!»

Si tienes el 40% del tráfico directo y crees que esto sucede por tus sólidas campañas de marca, tengo malas noticias. A menos que estés trabajando con una marca enorme y conocida, lo más probable es que tu tráfico directo esté más relacionado con las limitaciones del rastreo web (o simplemente con una mala configuración) en lugar de que la gente busque directamente tu marca.

Desafortunadamente, no puedo probarlo. En realidad, no creo que nadie pueda probar qué tipo de tráfico directo viene a TU sitio web. Tal vez tu marca es fuerte y recibes muchos visitantes verdaderamente directos. Tal vez no lo sea. Y por lo que he visto, siempre apuesto por lo último.

¿Por qué? Porque eventualmente, las auditorías de GTM/GA descubren muchos problemas técnicos.

El tráfico directo es una caja negra. Nadie puede probar lo que realmente es en tu caso. Si alguien puede, me gustaría conocerlo y aprender.

En lugar de despotricar sobre todo esto, me gustaría ir a la parte más práctica de esta guía, las razones por las que se obtiene el tráfico directo en Google Analytics y cómo tratar con eso.

Definitivamente puedes revisar todos estos elementos de la lista e implementarlos en tu configuración. Con suerte, eso reducirá parte de tu tráfico directo y atribuirá esas sesiones a otras fuentes de tráfico.

Además, mencionaré varias razones sobre las que no tienes control. Considéralas como «gotas».

Estoy bastante seguro de que hay más elementos que podrían ser añadidos a la lista. Si te falta algo, házmelo saber en los comentarios y actualizaré la lista.

Cómo reducir el tráfico directo en Google Analytics

Primero comenzaré con las razones que pueden impactar realmente y más cerca del final de esta guía, compartiré otras razones que tendrán que aceptar como un hecho.

Primero, empecemos con cómo puedes reducir el tráfico directo en Google Analytics. Ten cuidado, esto puede requerir mucha investigación y auditoría por tu parte.

#1. Su sitio web está en HTTP y hay redirecciones desde sitios web con HTTPS

Como he mencionado en uno de los capítulos anteriores de esta guía, uno de los parámetros que utiliza Google Analytics para determinar la fuente de tráfico es el Referrer.

Si otro sitio web contiene un enlace de retroceso a su sitio Y ese sitio tiene un HTTPS en la URL (mientras su sitio está en HTTP), el referenciador no se pasará.

Por lo tanto, si su sitio web sigue sin usar SSL (lo que significa que la dirección de su sitio sigue conteniendo http:// en lugar de https://, sus números de tráfico directo se verán afectados por ello.

Si no sabes cómo añadir SSL, ve y encuentra un desarrollador que lo haga por ti. De verdad, lo digo en serio. Por favor, hazlo. Estamos en el 2023.

Sin embargo, ten en cuenta una cosa más. Imagina un sitio web de terceros que contenga un enlace a tu sitio (https://www.3rdpartysite.com). Ese sitio web está usando https:// en el URL. Su enlace a tu sitio contiene http://. Acabas de migrar a la versión https.

Si un visitante hace clic en su enlace en https://www.3rdpartysite.com, luego es redirigido a http://www.yoursite.com y luego es redirigido a https://www.yoursite.com, el remitente también se perderá. Eso es porque la redirección en el medio no tiene https. Esto puede requerir más comunicación de su sitio para conseguir que el enlace de vuelta se actualice de http a https.

Si todavía está en http, entonces más retrasa la migración, las mayores consecuencias de los vínculos de retroceso «http» que tendrá en el futuro.

#2. Tu solución de consentimiento de cookies está perdiendo la fuente de tráfico

Si ha implementado un banner de consentimiento de cookies en su sitio web debido a GDPR o alguna otra regulación de privacidad Y un visitante da su consentimiento justo en la segunda (o subsiguiente) vista de página, esa sesión será tratada como una (directa).

¿Por qué?

Porque la fuente de tráfico sólo está disponible en la primera página (si hablamos de sitios web normales, no de aplicaciones de una sola página).

He aquí una situación. Un visitante aterriza en su sitio (el URL puede contener UTMs o tal vez el referente del sitio web anterior está disponible). Una vez que el visitante va a la siguiente página, el URL cambia y sus UTMs ya no están. Además, el valor del referenciador cambiará. Ahora el valor del referente contiene el URL de la página de destino (porque es la página anterior). GA tratará esto como una auto-referencia, lo que significa que la fuente de tráfico de tu sesión es (directa).

Entonces, ¿cuáles son las situaciones exactas en las que este problema es posible?

• La barra/popular de consentimiento de tu cookie no es llamativa y el visitante simplemente la ignora, por lo que continúa navegando (y entonces pierdes tu fuente de tráfico)
• También he visto algunos casos de soluciones mal implementadas en los que el visitante (inmediatamente después de haber dado su consentimiento) es redirigido a alguna otra página, por lo que también se pierden los parámetros de referencia/otros.

¿Qué hacer en este caso?

En primer lugar, sólo para salvarme, publicaré el habitual «No soy abogado, debería discutir esto con su departamento legal». Muy bien, ahora podemos continuar.

Sugeriría eso:

• La barra de consentimiento de la cookie no debe redirigir a los visitantes a ningún sitio después de que den su consentimiento. Sólo déjalos que naveguen más lejos y disparen sus códigos de rastreo en consecuencia.
• La ventana emergente de consentimiento de la cookie debe ser visible y llamar la atención una vez que el visitante llega al sitio. El visitante debe hacer su elección de inmediato – aceptar o rechazar. Su objetivo es conseguir esa elección en la primera vista de página.

#3. UTM con errores

Es una práctica normal marcar sus URL con parámetros adicionales llamados UTM(utm_medium, utm_source, utm_campaign, utm_term, utm_content).

Si el visitante llega a su sitio web y el URL contiene esos parámetros, GA atribuirá esa sesión a la fuente de tráfico que se menciona en esos parámetros.

Por lo general, estos parámetros se utilizan en el marketing por correo electrónico, publicaciones en medios sociales, publicidad de pago, canales personalizados (como los libros electrónicos), etc.

Pero aquí está el truco. Si quieres que los UTM funcionen correctamente, deben estar correctamente formateados:

• Se recomienda que los parámetros UTM vayan en la URL después del signo de interrogación (aunque también es posible usar UTMs después del #, eso no es recomendable). Ejemplo: mysite.com?utm_medium=social&utm_source=twitter.com
• Diferentes parámetros deben ser conectados con un ampersand (&)
• Los nombres de los parámetros UTM deben ser exactamente como este:
  • utm_medium
  • utm_source
  • utm_campaign
  • utm_term
  • utm_contento
  • Otras variaciones (como utmMedium, etc.) no funcionarán.

Entonces, ¿dónde está el problema? Muy a menudo, veo errores de escritura o simplemente una mala configuración en los informes de GA.

Si el visitante llega a su sitio web y el valor del Referrer está vacío pero el URL contiene parámetros UTM, esa sesión se atribuirá a alguna fuente de tráfico (que se describe en esos UTM). Pero si los UTM son incorrectos (es decir, están formateados incorrectamente), esa sesión se atribuirá a (directo).

La forma más fácil de comprobar si sus UTMs están rotos es ir al informe de Páginas de Aterrizaje en Google Analytics (ir a Comportamiento > Contenido del sitio > Páginas de Aterrizaje).

Si los UTMs son correctos, no se mostrarán en las URLs de la página. GA sólo los lee, los atribuye a la fuente de tráfico correcta y eso es todo. Los UTMs no se mostrarán como parte del URL.

Pero si usted o sus colegas los agregaron a la URL incorrectamente, los verá en sus informes.

En ese informe de páginas de aterrizaje, haga clic en «Avanzado» junto a la barra de búsqueda.

A continuación, introduzca los siguientes filtros:

• Incluir Fuente/Medio que contiene (directo) / (ninguno)
• e incluir la página de aterrizaje que contiene utm

¿El informe ha devuelto algo? ¿Sí? Entonces aquí tienes tus UTMs rotas. Haga lo posible por arreglarlos y contacte a los responsables de algunos de esos UTMs, y pídales que lo arreglen.

¿Cómo puedes encontrar a esas personas? Tendrás que hacer de detective y resolver esas cosas por tu cuenta.

Otras cosas para buscar en ese mismo informe (pero no limitado a):

Espero que te hagas una idea.

#4. Enlaces afiliados sin referenciador o UTMs

¿Su empresa tiene un programa de afiliados? Si es así, lo más probable es que al menos una parte de tus enlaces de afiliado llegue como tráfico directo.

En GA, ve a Comportamiento > Contenido > Páginas de aterrizaje. Digamos que todos tus enlaces de afiliado contienen el parámetro URL affiliate_id. Ejemplo: mysite.com?affiliate_id=123123.

Ahora, introduzcamos «affiliate_id» (sin comillas) en la barra de búsqueda del informe de la página de aterrizaje. Nota: si su parámetro de identificación de afiliado es diferente, introduzca SU parámetro allí (por ejemplo, aID, affID, partner_id, etc.).

El informe devolverá la lista de páginas de destino que contenían el parámetro affiliate_id.

Ahora, agregue la dimensión secundaria Fuente/Medio. Finalmente, abra la búsqueda avanzada en GA e introduzca la siguiente condición: Incluir el contenido de Fuente/Medio (directo).

Como resultado, obtendrás una lista de todas las sesiones de tus afiliados que son tratadas como (directas) en Google Analytics.

» alt=»how to reduce direct traffic in google analytics» width=»791″ height=»336″ data-src=»https://www.analyticsmania.com/wp-content/uploads/2020/07/how-to-reduce-direct-traffic-in-google-analytics.jpg» data-srcset=»https://www.analyticsmania.com/wp-content/uploads/2020/07/how-to-reduce-direct-traffic-in-google-analytics.jpg 791w, https://www.analyticsmania.com/wp-content/uploads/2020/07/how-to-reduce-direct-traffic-in-google-analytics-300×127.jpg 300w, https://www.analyticsmania.com/wp-content/uploads/2020/07/how-to-reduce-direct-traffic-in-google-analytics-768×326.jpg 768w» data-sizes=»(max-width: 791px) 100vw, 791px» />

Una solución rápida es crear varias variables y sobrescribir los datos de la campaña en las etiquetas de Google Analytics. Si la URL contiene affiliate_id, entonces configuraremos manualmente la fuente de tráfico para que sea utm_medium=affiliate y utm_source para que sea el ID real de un afiliado que condujo a esos visitantes a tu sitio).

Crear la primera (nombrar esta variable cjs – campaignMedium):

function() { return window.location.href.indexOf('affiliate_id') > -1 ? 'affiliate' : undefined;}

Si su parámetro de afiliación es diferente (no el affiliate_id), insértelo en el código anterior (en lugar del affiliate_id)

La 2ª variable (nombre esta variable cjs – campaignSource):

function() { return window.location.href.indexOf('affiliate_id') > -1 ? {{url - affiliate_id}} : undefined;}

Para que la 2ª variable funcione, debes crear una variable URL en el Google Tag Manager con los siguientes ajustes:

El nombre de esa variable debe ser estrictamente url – affiliate_id. Si el nombre de tu parámetro de ID de afiliado es diferente, utiliza ese en su lugar. Pero asegúrate de sustituirlo en todas las variables anteriores.

Por último, ve a tu variable de configuración de Google Analytics > Más ajustes > Campo para establecer y añadir dos nuevos campos (como he mostrado en la captura de pantalla de abajo). Los nombres de los campos distinguen entre mayúsculas y minúsculas.

En el campo de valor de la campañaMedio, he insertado la primera variable JS personalizada que hemos creado recientemente. Y en el campo de la campañaFuente, he insertado la segunda variable Custom JS.

#5. Acortadores de URL

Si se utilizan acortadores de enlaces, pueden perder el remitente, por lo que no hay datos de la fuente de tráfico. Lo que podrías hacer es añadir UTMs a la URL de destino final.

Por ejemplo, en lugar de insertar«https://www.mywebsite.com/some-landing-page», podrías insertar«https://www.mywebsite.com/ some-landing-page?utm_medium=……»(reemplace los puntos con los parámetros reales del UTM).

De esa manera, incluso si el referenciador no está disponible, los UTM indicarán correctamente la fuente de tráfico a Google Analytics.

No tengo formas rápidas de auditar los enlaces cortos, por lo que probablemente tendrá que revisarlos/actualizarlos uno por uno en su plataforma/app de acortadores de enlaces.

#6. A los enlaces en documentos no web les faltan UTMs

Si sus visitantes/usuarios pueden descargar archivos como libros electrónicos (y esos archivos están en PDF o en algún otro formato rico), esos archivos podrían contener enlaces a su sitio web, ¿verdad?

Cuando un visitante hace clic en cualquiera de esos enlaces, el remitente no está disponible. Nunca. Incluso si abre los PDF con Chrome, el referenciador no está disponible.

¿Una solución? Todos los enlaces de sus PDF y archivos similares deben contener parámetros UTM.

Si ya tienes un montón de libros electrónicos publicados y ninguno de ellos contiene UTM en los enlaces, tendrás que actualizarlos manualmente. Si muchas personas ya han descargado sus libros electrónicos, no podrá cambiar los enlaces de esos archivos.

Hablando de la convención de nombres, una de las ideas podría ser así:

• utm_medium=pdf
• utm_source=[tipo de contenido], por ejemplo, utm_source=libro, utm_source=lista de control, etc.
• utm_campaign=[nombre del documento], por ejemplo, utm_campaign=very-cool-ebook.

#7. Los UTM no se adoptan en toda la empresa

Incluso si conoces los UTM y los usas siempre, tus colegas podrían no estar en la misma página. Necesitas comunicarte con ellos y pedirles que siempre usen los UTM en los enlaces en PDF, correos electrónicos, etc.

Cuando mucha gente trabaja con UTM, la comunicación y la coherencia se convierten en un desafío.

Mucha gente = muchas convenciones de nombres diferentes, también conocido como «random $h!t everyone comes up». Algunas personas pueden usar utm_medium=email mientras que otras en su empresa pueden usar utm_medium=Email.

Google Analytics distingue entre mayúsculas y minúsculas, por lo que el correo electrónico y el email son dos fuentes de tráfico diferentes.

¿Qué puedes hacer al respecto?

Una de las formas podría ser crear una hoja de cálculo con tus convenciones de nomenclatura. Siempre que alguien quiera generalizar un enlace con los UTMs, lo necesita:

• Introducir todos los parámetros UTM en ciertas celdas y luego la hoja devolverá la URL
• Sin embargo, al ver esa hoja, tendrán que mirar otros UTM ya existentes y al menos tratar de seguir la convención de nombres.

Para inspirarse, pueden echar un vistazo a la hoja de cálculo de Annie Cushing (Annielytics).

Cuantos más enlaces estén etiquetados con UTM, menor será el tráfico (directo).

#8. Tráfico falso de bots

Es muy probable que ya estés recibiendo tráfico falso de los bots y lo veas en Google Analytics.

En el pasado, eso era posible de abordar con dimensiones como Proveedor de Servicios en GA pero, desafortunadamente, esos días ya han pasado. Hemos perdido esos valiosos datos en GA que eran útiles en la lucha contra el spam.

Como una solución alternativa, se podría tratar de implementar esta solución. Pero tened en cuenta sus limitaciones de cuota.

Además, asegúrate de haber activado esta casilla de verificación en la configuración de la vista de tu Google Analytics. Hazlo en todas las vistas (excepto en la vista «Raw»).

#9. Implementación incorrecta del protocolo de medición

El protocolo de medición permite a los comercializadores/analistas/desarrolladores enviar los datos directamente a Google Analytics. No se necesitan códigos de rastreo, la comunicación se realiza de servidor a servidor.

Esto es útil en algunos casos. Por ejemplo, si un visitante inicia una compra pero todavía tiene que hacer la transferencia bancaria, debe contar la venta cuando los fondos lleguen a su cuenta bancaria.

En el momento en que esto ocurre, el visitante probablemente estará fuera de línea, por lo que los códigos de seguimiento regulares (incluido el GTM) son inútiles.

Pero en este caso, sus desarrolladores podrían enviar los datos de la compra directamente desde el servidor de su sitio web a Google Analytics a través del protocolo de medición.

En teoría, esto suena muy bien. Sin embargo, los desarrolladores a veces estropean las cosas olvidándose de incluir datos importantes. ¿El resultado? La mayoría de sus sesiones se atribuyen al tráfico (directo) en GA y todos esos usuarios se muestran como Nuevos Usuarios.

¿Cuál es la razón? Los desarrolladores no pasan los ID de cliente correctos a Google Analytics.

El ID de cliente es un ID aleatorio que es asignado por el código de seguimiento de Google Analytics. Cuando el visitante navega por su sitio, ese ID persiste en todas las páginas (a menos que se cambie un dispositivo o se eliminen las cookies). Cuando reciba los fondos del cliente en su cuenta bancaria, el código del desarrollador deberá enviar los datos de la compra a GA junto con el ID de cliente de ese visitante. Entonces GA podrá atribuir la compra a la fuente de tráfico no directo anterior.

Esto significa que los desarrolladores deben:

1. Recuperar el ID de cliente mientras el visitante está en el proceso de compra
2. Almacene esa identificación de cliente en la base de datos y luego utilícela en la solicitud que se envía al Protocolo de Medición después de que los fondos se hayan recibido con éxito mediante transferencia electrónica.

Esto es mucho más técnico que el resto de la guía, por lo que sólo les dejaré los recursos relacionados para que los lean como un homewok:

#10. No todas las páginas de su sitio web tienen el código de Google Analytics (o Google Tag Manager)

Esta es una situación, un visitante llega a cierta página de su sitio web de Google. El referenciador es «google.com» por lo que sería fácil identificar la fuente de tráfico.

Pero por alguna razón (tal vez un error humano), esa página no tiene implementado un código de seguimiento de Google Analytics. Entonces el visitante navega a la segunda página que tiene el código GA.

Por lo tanto, la primera página en GA es en realidad la segunda página de ese visitante. Y el valor del referente de esa página es su propio sitio web. Esto significa que GA tratará esto como un auto-referente, de ahí la sesión directa.

¿Cómo se puede evitar esto? Audite su sitio web y compruebe si GA está implementado en todos los sitios.

Una de las posibles opciones es usar la Rana Gritona.

La Rana Gritona es una solución que es especialmente popular entre los profesionales de SEO que quieren comprobar lo que está pasando en los sitios web de sus clientes. ¿Cómo se relaciona con GTM o GA? Se puede configurar para que rastree todo el sitio web y busque información particular (como scripts).

Si has implementado Google Analytics a través de GTM, entonces podrías configurar Screaming Frog para que siga buscando https://www.googletagmanager.com/gtm.js en el código fuente del sitio web. Esta URL es utilizada por el contenedor del Google Tag Manager.

En la aplicación de Screaming Frog, vaya a Configuración > Personalizar > Buscar e introduzca la siguiente condición:

No contiene https://www.googletagmanager.com/gtm.js

Ingrese el URL del sitio web que desea revisar y presione el botón de Inicio.

Eso es todo! A medida que el rastreo progresa, podrá ver los URL completos de las páginas en las que falta el código del contenedor GTM. Su próximo paso es, obviamente, añadir el código de rastreo a esas páginas o pedirle a un desarrollador que lo haga.

Y luego, por supuesto, asegúrese de que el disparador de su etiqueta de Google Analytics en el Administrador de etiquetas de Google está relacionado con Todas las páginas u otra condición que dispara en todas las páginas.

Si has implementado Google Analytics directamente en el código fuente del sitio web, entonces aquí hay otras URL que podrías usar en la auditoría:

• https://www.googletagmanager.com/gtag/js (si estás usando la última versión del código de GA, gtag.js)
• https://www.google-analytics.com/analytics.js (si está usando la versión anterior, llamada Universal Analytics). Se recomienda encarecidamente que migre a la versión más reciente.

Si ninguna de las opciones anteriores funciona, probablemente esté usando versiones GA más antiguas. En ese caso, es hora de que migre a la versión más reciente. Lo digo en serio.

#11. ITP

ITP (Intelligent Tracking Prevention) es un mecanismo de mejora de la privacidad que se aplica a los navegadores de Safari y también a todos los navegadores de iOS.

Hay muchas cosas que afectan pero una de las principales en el contexto del tráfico directo es:

• Las cookies establecidas por Google Analytics (y otros códigos de seguimiento de JavaScript) están programadas para expirar en 7 días (a menos que el visitante regrese a su sitio antes)
• Las cookies establecidas en la página cuando el visitante llega directamente desde la red publicitaria (por ejemplo, los anuncios de Google o de Facebook) están programadas para expirar en 24 horas (a menos que el visitante siga navegando por su sitio)

Así que si adquieres un visitante por primera vez de la búsqueda de Google y luego ese visitante regresa después de 8 días, Google Analytics:

• Lo tratará como un nuevo usuario
• La fuente de tráfico actual tendrá prioridad. Si la fuente de tráfico actual de esa sesión repetida es directa, también se informará como directa en GA.

Si el visitante de la búsqueda de Google regresa después de 6 días (y entra a su sitio, digamos, desde un chat de Slack), entonces GA lo tratará como un usuario que regresa y la fuente de tráfico será «orgánica» debido a la atribución del último clic no directo de GA.

¿Qué puedes hacer con el ITP? Limita las cookies que se establecen a través de JavaScript del lado del cliente (léase: a través de códigos de seguimiento JS que se añaden a través de GTM o están codificados en el código fuente del sitio web). Pero si las cookies se establecen desde el lado del servidor, sus datos de caducidad están bien (al menos por ahora).

Por lo tanto, podría pedir a sus desarrolladores que construyan un servicio que reescriba las cookies y extienda su fecha de caducidad. Alternativamente, podrías usar una solución ya preparada, Cookiesaver, que es más fácil de implementar. Sin embargo, tenga en cuenta las preocupaciones de privacidad sobre este método de rastreo.

#12. ¿Remarcaron recientemente y cambiaron el dominio?

Si es así, compruebe si sus números de tráfico directo han aumentado después del lanzamiento de la nueva marca. Puede ir a GA > Adquisición > Todo el tráfico > Fuente/Medio y luego haga clic en (directo) / ninguno.

A continuación, elija un intervalo de fechas más amplio y compruebe si hubo un aumento repentino en el día en el que cambió de marca públicamente o varios días después.

Si observa un aumento repentino, lo más probable es que se deba a algunas redirecciones (entre el antiguo y el nuevo dominio) y que el referenciador se pierda en algún punto del camino.

Desafortunadamente, no tengo una forma rápida de identificar qué es exactamente lo que está roto (si conoces una, por favor, por favor, házmelo saber 🙂 ). Pero aquí hay varias ideas:

• Revise algunos de los vínculos de retroceso de su cliente/negocio que redirigen al dominio más antiguo. Haga clic en algunos de ellos. Luego, cuando finalmente llegues al nuevo dominio, abre la consola de JavaScript de tu navegador e introduce document.referrer. Si sólo ves comillas con un valor vacío, entonces existe la posibilidad de que el valor del referenciador se pierda en algún lugar de las redirecciones entre tu antiguo y nuevo dominio.
• Compruebe qué fuentes de tráfico (especialmente en el medio de referencia) han perdido el tráfico después de la redirección. Pueden darte algunas pistas sobre qué tráfico de referencia se ha convertido en el directo. Por ejemplo, en la siguiente captura de pantalla, he identificado que el tráfico de referencia se redujo significativamente después del cambio de marca oficial. El siguiente paso que haría es comprobar si el tráfico directo aumentó en una cantidad similar. En caso afirmativo, comprobaría los vínculos de referencia más populares, haría clic en ellos en sus respectivos sitios web y vería si el referente es visible en la consola. Si el referente se pierde, consultaría con los desarrolladores.

Este proceso suele ser muy agotador, especialmente si trabajas como consultor para el cliente y no conoces su negocio tan bien como ellos. Como resultado, no tienen ni idea de lo que estás buscando y no sabes exactamente qué preguntar porque todavía no tienes una imagen clara de su ecosistema tecnológico.

¿Qué debe hacer cuando identifica las fuentes de tráfico/referencias que redirigen a los visitantes a su sitio pero ya no devuelven al remitente?

Primero, recopilar un puñado de ejemplos de páginas (en otros sitios web) que contengan sus vínculos de retroceso. Luego, envíe esos enlaces a los desarrolladores de su sitio web y explique: cuando se hace clic en su enlace de retroceso, las redirecciones se producen entre su antiguo y su nuevo dominio, y el remitente está en algún lugar perdido. Ellos tienen que arreglarlo – sus desarrolladores tienen que preservar el referenciador.

No es tu trabajo saber y explicarles CÓMO hacerlo. Sólo diles que necesitas que el referente se conserve cuando se haga clic en esos enlaces y se redireccione entre tu antiguo y nuevo dominio. Si no saben cómo arreglar eso, tal vez sea hora de buscar devs más experimentados.

#13. El rastreo de dominios cruzados mal configurado

Si los visitantes pueden navegar de un dominio a otro (no estoy hablando de subdominios del mismo dominio), es necesario implementar el rastreo entre dominios de Google Analytics. Sin embargo, si configuras mal algo, es probable que parte de tu tráfico se convierta en (directo) en los informes de GA.

Uno de los posibles casos que me viene a la mente es este: actualizaste la lista de exclusión de referencias en Google Analytics correctamente pero el ID de cliente de GA es diferente en los distintos dominios.

¿El resultado de esto? Obtendrás un montón de nuevos usuarios en el dominio B y su fuente de tráfico será directa (porque el dominio A está excluido de las referencias).

Si quieres aprender a configurar correctamente el seguimiento entre dominios en Google Analytics con Google Tag Manager, descarga mi libro electrónico gratuito a continuación.

#14. Revisa el informe de Páginas de aterrizaje en GA por una vez más

En esta entrada del blog, ya hemos revisado esos informes varias veces. Pero hagámoslo una vez más. En este capítulo, deberías buscar cualquier cosa sospechosa e inusual. No daré consejos muy específicos porque cada sitio web es diferente, pero aquí está uno de los ejemplos teóricos.

Primero, vayamos a GA > Comportamiento > Contenido del sitio > Páginas de aterrizaje. Añade la dimensión secundaria «Fuente/Medio».

En la barra de búsqueda, haga clic en avanzado, introduzca la siguiente condición y pulse Aplicar.

Note que incluyo el signo de interrogación en el filtro de búsqueda. En este caso, estamos buscando páginas de aterrizaje que tenían algunos parámetros de URL (también conocido como consulta) pero que fueron asignados a las sesiones directas. ¿Alguno de esos parámetros le resulta familiar?

Tal vez una URL que contiene el parámetro ?_hsmi significa que este correo electrónico fue enviado a través de Hubspot pero por alguna razón, el enlace no estaba decorado con UTMs?

¿Cómo sé que _hsmi pertenece a los enlaces de los correos electrónicos de Hubspot? Una de las habilidades más valoradas en estos días es el googlear.

Una vez que identifiques la herramienta de la que provino esa sesión directa, es hora de (una vez más) jugar al detective y averiguar por qué algunos enlaces de Hubspot no están decorados.

Ten en cuenta que no sé si es posible tener un enlace sin decorar en Hubspot. Esto es sólo un ejemplo teórico. Haga la misma investigación sobre otros parámetros de consulta sospechosos.

Esto no será rápido y fácil.

#15. Tráfico desde las aplicaciones de Android

Aparentemente, cuando un visitante llega a su sitio web desde la aplicación Android (por ejemplo, desde Linkedin), el referente está realmente presente en una página pero Google Analytics lo ignora, por lo tanto el tráfico directo.

Afortunadamente, esto se puede arreglar con la configuración del Google Tag Manager y el filtro de Google Analytics.

Para mi blog, esto redujo el tráfico directo en un 3%. Pero el número variará en diferentes sitios web.

Primero que nada, necesitas crear una dimensión personalizada en tu propiedad de Google Analytics. Ve a GA Admin > Definiciones Personalizadas > Dimensiones Personalizadas y crea una nueva dimensión. Puedes llamarla como quieras, por ejemplo, Referrer o CD – Referrer. Configura el alcance a Hit.

Después de crearla, verá el índice de una Dimensión Personalizada. Recuerda ese número.

Ahora, ve al Administrador de etiquetas de Google y abre tu variable de configuración de Google Analytics que es usada por tus etiquetas GA. Luego ve a Más Ajustes > Dimensiones Personalizadas > Agregar Dimensión Personalizada.

Introduce el índice de la dimensión personalizada y en el campo Valor, inserta la variable {{Referrer}} incorporada.

Si utiliza varias variables de configuración GA en su configuración, haga esta configuración en todas ellas. Pruebe la configuración y publique los cambios.

Para ver la prueba de concepto (que el tráfico de las aplicaciones de android se trata como tráfico directo), espere un día para recopilar algunos datos nuevos en GA y luego haga lo siguiente: vaya a GA > Adquisición > Todo el tráfico > Fuente / Medio y haga clic en el tráfico (directo) / (ninguno). Luego agregue la dimensión personalizada recientemente creada como una dimensión secundaria.

Y aquí está la prueba de que el tráfico de la aplicación androide se trata como tráfico directo.

Varias aplicaciones de Android se muestran como «android-app://….»

En esa lista, puede que también vea su propio dominio (pero eso sucede debido a la Lista de Exclusión de Referidos).

Entonces, ¿qué deberías hacer ahora? Deberías crear dos filtros. Uno reescribirá el Medio de ese tráfico, el otro reescribirá la Fuente.

En Google Analytics, ve a Admin > Filtros ( bajo la vista ) y crea un filtro con los siguientes ajustes:

• Nombre: Reescribir – Fuente de la aplicación Android
• Tipo de filtro – Personalizado > Avanzado
• Campo A -> Extracto A:[seleccione su dimensión personalizada – referenciador], establezca el valor: ^android.app…(.*)
• CampoB -> Extracto B: Seleccione el medio de la campaña e introduzca (none )
• Salida a -> Constructor: Seleccione la fuente de la campaña e introduzca $A1
• El campo A es obligatorio: Sí
• El campo B es obligatorio: Sí
• Sobrescribir el campo de salida: Sí
• Sensible a las mayúsculas y minúsculas: No
• Guardar

A continuación, cree un segundo filtro con los siguientes ajustes:

• Nombre: Reescribir – Medio de aplicación Android
• Tipo de filtro – Personalizado > Avanzado
• Campo A -> Extracto A:[seleccione su dimensión personalizada – referenciador], establezca el valor: ^android.app…(.*)
• CampoB -> Extracto B: Seleccione el medio de la campaña e introduzca (none )
• Salida a -> Constructor: Seleccione el medio de la campaña e introduzca android-app
• El campo A es obligatorio: Sí
• El campo B es obligatorio: Sí
• Sobrescribir el campo de salida: Sí
• Sensible a las mayúsculas y minúsculas: No
• Guardar

Una vez que las creas, el tráfico de tu aplicación Android será atribuido a una nueva fuente/medio, llamada [URL de la aplicación] / android-app

Importante: siempre pruebe primero sus filtros en las vistas de prueba (antes de aplicarlos a las vistas maestras).

Una vez más, gracias a Marek por señalar esto. Aquí está la guía original (usé una captura de pantalla de ella también).

#16. Si es posible, pida no incluir el noreferrer en los vínculos de retroceso (#quiteUnlikely)

No soy un constructor de enlaces y creo que sería bastante malo en esto. Tengo serias dudas de que este consejo sea útil pero hey, tal vez funcione al menos en algunos casos en los que tienes muy buenas relaciones.

Así que aquí está la cosa: si un enlace en otro sitio web redirige a los visitantes a tu sitio y ese enlace contiene «rel=noreferrer», ese tráfico se convertirá (directo) en tus informes de la AG (a menos que haya UTMs). Eso sucede porque (¡sorpresa!) el referenciador no se pasa.

Por lo tanto, si eso es posible (en la mayoría de los casos, probablemente no), pida que se elimine el noreferrer del parámetro rel en ese elemento de enlace.

Hablando de la relación costo/beneficio de esta solución, diría que deberías invertir más de tu tiempo en otros consejos mencionados en esta entrada del blog. Si ya era un desafío adquirir el vínculo de retroceso, conseguir que alguien quite el noreferrer será aún más difícil. Además, algunos webmasters podrían rechazar su solicitud por problemas de privacidad.

De todos modos, solo quería mencionar que en caso de que estés desesperado por soluciones 🙂

Cosas que deberías aceptar

Hablando de todos los consejos anteriores sobre cómo reducir el tráfico directo en Google Analytics, tienes al menos algún tipo de control/impacto. Puedes solucionar algunos problemas por ti mismo, mientras que en otros casos, puedes cooperar con los desarrolladores.

Pero hay situaciones en las que simplemente hay que aceptar el hecho: una parte importante de tu tráfico directo está relacionado con medios que no pasan por el referenciador. Punto.

#1. Algunos sitios web no envían los datos del remitente

Esto está relacionado con la punta #16. Si un vínculo de retroceso a su sitio web tiene un parámetro rel=»noreferrer», ese tráfico se mostrará como directo en sus informes de la AG.

Pero esta no es la única forma en que se puede configurar la política de referidos. También se puede configurar:

• en las cabeceras HTTP
• en las meta etiquetas de la página web. Si abres el código fuente de la página web y ves esto en la cabecera
  esto significa que ningún enlace en un sitio pasará por el remitente, por lo tanto el tráfico directo.
• a través del atributo referrerpolicy

#2. Los chats y los mensajeros no suelen enviar al remitente

Si alguien comparte el enlace de tu sitio web en Slack y la otra persona hace clic en él, es una sesión directa para ti, amigo mío. Y no hay nada que podamos hacer al respecto. Además, los mensajeros normalmente tienden a no pasar por el remitente. Aunque he notado que el Facebook Messenger todavía pasa al remitente.

#3. Los visitantes pueden usar plugins de navegador que afectan al remitente…

Por ejemplo, una Extensión de cromo llamada Control de Remitentes le permite forjar el remitente O deshabilitarlo completamente. Si un visitante llega a su sitio web con el referenciador desactivado, lo adivinó – no hay nada que podamos hacer al respecto.

#4. La gente puede introducir la dirección en la barra de direcciones (o marcarla)

Lamentablemente, no se puede identificar si el visitante realmente lo hizo o tal vez el visitante acaba de aterrizar en su sitio web desde otro medio que no pasa por el referenciador. No hay manera de hacer eso.

Además, existe la posibilidad de que un visitante aterrice en su sitio desde un correo electrónico (y los UTM están en la URL) y lo marque, cada vez que se hace clic en ese marcador, la fuente de tráfico de la visita no será (directa). También utilizará los UTMs que fueron almacenados en el marcador.

Cómo reducir el tráfico directo en Google Analytics: Palabras finales

Cuando se trata de reducir el tráfico directo en Google Analytics, no hay una solución única que funcione para todos. Incluso si logras implementar todos los consejos, no alcanzarás los números REALES de tráfico directo en tus informes de la AG.

Desafortunadamente, esto es lo que nosotros (los mercadólogos y analistas) tenemos que aceptar y con lo que tenemos que trabajar.

Pero si usted está pensando que tiene un gran volumen de tráfico directo sólo porque su marca es fuerte, eso es, muy probablemente, no es cierto.

Mi objetivo de esta entrada en el blog era mostrarte que el término tráfico directo es engañoso y que debería ser renombrado como «No tengo ni idea de dónde vino este visitante» y, con suerte, después de leer esta guía e implementar al menos algunos de los consejos, has conseguido distribuir el tráfico directo a otras fuentes de tráfico.

Este es un tema interminable y si sabes algo que no se mencionó en esta guía, me encantaría escuchar tus opiniones.

¿Tienes alguna pregunta? Publica un comentario a continuación.