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?
Respuestas:
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.
Las siguientes URL acortadas redirigen a una página que muestra el referente HTTP.
http://tinyurl.com/checkreferer (vea la nota importante a continuación sobre tinyurl.com)
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.
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"?!
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
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.
Como referencia, este artículo enumera muchos de los acortadores de URL más populares e indica qué tipo de redirección utilizan.
http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204
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.
Investigué un poco y encontré eso; el tráfico categorizado por Google Analytics variará según el sitio web de acortador de URL.
Consulte este enlace para obtener más información: