¿El tráfico proveniente de acortadores de URL se trata como directo?

24

El tráfico proveniente de URL acortadas como bit.ly, ¿aparecen en Google Analytics como directas o conservan su referencia real?

Ej .: si alguien escribe un bit.lyenlace, se cuenta como directo, pero si alguien hace clic en un bit.lyenlace de Twitter, ¿cuenta como tráfico de referencia de Twitter?

sorpresa
fuente

Respuestas:

18

Los servicios de acortamiento de URL bit.lyy goo.gl(vea la nota a tinyurl.comcontinuación) devuelven un estado HTTP Moved 301 permanentemente, es decir. una redirección de URL. El navegador luego envía una nueva solicitud a la nueva URL (es decir, larga), pasando de nuevo al árbitro. AFAIK esto es lo mismo para la mayoría de los servicios de acortamiento de URL convencionales.

Si el servicio realiza una redirección 301 (como debería), entonces el navegador vuelve a pasar el árbitro. En este caso, no veo ninguna razón para que Google Analytics no muestre este referente en sus informes.

Sin embargo, tenga en cuenta que el navegador en sí puede configurarse para suprimir el referente HTTP, o incluso enviar algo completamente erróneo.

El tráfico proveniente de URL acortadas como bit.ly, ¿se muestran en Google Analytics como directas o conservan su referencia real?

Mantienen al verdadero árbitro. Esto también podría ser "directo", si de hecho fuera una solicitud directa.

Ex. Si alguien escribe un enlace bit.ly, cuenta como directo, pero si alguien hace clic en un enlace bit.ly de Twitter, ¿cuenta como tráfico de referencia desde Twitter?

Sí. Tenga en cuenta que Twitter ahora envuelve todas sus URL en su propio servicio de acortamiento de URL, por lo que la URL de referencia es del formulario http://t.co/xyzxyz.

Un ejemplo

Las siguientes URL acortadas redirigen a una página que muestra el referente HTTP.

Puede ver que siguiendo cualquiera de los enlaces anteriores, se pasa el árbitro HTTP (siempre que su navegador esté configurado para hacerlo). Si copia y pega la URL en una nueva ventana del navegador, no se pasa ningún referente, es un enlace directo.

tinyurl.com (actualizado 2015-08-08)

No sé si esto es algo nuevo, ¡pero acabo de darme cuenta de que tinyurl.comsolo realiza una redirección 301 regular (y envía el Referente HTTP) en la segunda y posteriores solicitudes realizadas por un usuario !? En la primera solicitud tinyurl.comparece cargar una página intermediaria y luego emite una redirección (¿JavaScript?) ¡Esto da como resultado que la primera solicitud devuelva un 200 OKestado y que el árbitro se configure en la URL "pequeña" abreviada! (Y hace algo peculiar con el historial del navegador).

Sin embargo, en la segunda solicitud, recibe una redirección 301 estándar y se pasa el HTTP Referer esperado (esto también se almacenará en caché). (¿Supongo que esto podría estar determinado por una cookie tinyurl.com que se configura durante la primera solicitud?)

2015-08-09: Previamente probé lo anterior usando una nueva ventana de incógnito en Google Chrome, sin embargo, ahora parece estar resultando en una redirección 301 independientemente, por lo tanto, no estoy exactamente seguro de lo que está sucediendo tinyurl.com, ¿fue solo un " falla"?!

HTTPS - Conexiones seguras

Solo una nota adicional sobre enlaces desde contenido seguro (HTTPS) a contenido no seguro (HTTP): esto afecta a cualquier tipo de enlace, no solo a los acortadores de URL. En este caso, el navegador no establece el encabezado de referencia HTTP .

Los clientes NO DEBEN incluir un campo de encabezado Referer en una solicitud HTTP (no segura) si la página de referencia se transfirió con un protocolo seguro.

Fuente: RFC 2616 Sección 15.1.3

Redireccionamiento de JavaScript

Sin embargo, una redirección JavaScript será destruir el árbitro originales. No Locationse establece ningún encabezado y solo ve 200 OKCódigos de estado HTTP.

  • Esta página redirige JavaScript a la misma página que la anterior (que muestra el Referer HTTP). Pero en lugar de pasar el Referer original (es decir, esta página), el Referer HTTP es la página intermediaria que contiene la redirección de JavaScript.
Señor White
fuente
1
Tenga en cuenta que, dado que Pro Webmasters se ha convertido solo en HTTPS y los enlaces abreviados anteriores son HTTP, el Referer ya no es enviado por el navegador en los ejemplos anteriores (como se indica en la sección "HTTPS - Conexiones seguras"). Desafortunadamente, no puedo editar la respuesta para agregar una nota o corregir los enlaces, ya que el uso de servicios de acortamiento de URL ahora está bloqueado en la red de Stack Exchange. Ver: meta.stackexchange.com/questions/64450/…
MrWhite
Los enlaces deben ser reemplazados por un servicio que admita https ( w3dk.com no) ya que stackexchange ahora está en https y el árbitro está perdido en https para redireccionamientos http
the_nuts
2

Depende.

En circunstancias normales, cuando se utiliza un navegador web con Twitter o las redes sociales en general, al hacer clic en un enlace acortado se mostrará el referente original en Google Analytics. Sin embargo, dado que muchos usuarios usan un teléfono móvil y aplicaciones de redes sociales en lugar de un navegador, terminarás con tráfico directo. Si filtra sus datos de GA, probablemente verá mucho tráfico directo desde el móvil.

¿Cómo resolver esto?

En realidad es bastante fácil. Agregue variables de seguimiento de campaña a todas sus URL antes de acortarlas. Entonces puedes ver todo correcto en GA. Con seguimiento de campaña me refiero a agregar utm_source, utm_mediumy también a utm_campaignvariables de URL. Esa es la mejor manera de resolver esto, sin importar el servicio de acortamiento que esté utilizando e incluso a través de diferentes protocolos.

Kristian Svensson
fuente