() translation by (you can also view the original English article)
Continuando con nuestra serie de interpretación de web analytics, este artículo muestra como factores como el infinite scrolling afectan los coeficientes de rebotes, y como es posible sesgar tus propias analytics para producir resultados más "amigables".
Las cosas no son siempre lo que parecen
"Esto es lo que pasa cuando los editores invierten en historias largas" declarado por Co.Labs en 2013, con un gráfico mostrando una dramática caída en el coeficiente de rebote:
Wow -parece que cayó de alrededor de un 75% un 20%! Por nuestra definición de coeficiente de rebote (el porcentaje de visitas que solo estuvieron en una página), sabemos que esto significa, pre-inmersión, que alrededor de un 75% de las visitas fueron de solo una página; post-inmersión, 20% de las visitas fueron de solo una página.
O, en otras palabras: pre-inmersión, solo 25% de las visitas miraban más de una página; post-inmersión, 80% de las visitas miraban más de una página.
Nota: Desde la publicación, el autor @chrisdannen agregó algunas correcciones, una parte de las cuales se refieren a errores cometidos en la recolección original de información. No hay un problema con nuestros ejemplos, ya que la información sigue sirviendo para nuestros puntos.
Un poco más abajo en el artículo, se comparte este gráfico:
La línea celeste muestra el número promedio de páginas que un usuario ve en una visita, y cambió levemente. Pero espera -si el número de gente que ve más de una página se fue del 25% al 80%, seguramente esta línea debería haber subido también?
Para entender por qué no, primero tomaremos un pequeño desvío.
Infinite Scroll y Coeficiente de Rebotes
Supongamos que vas de una de las home pages de Envato Tuts+, haces scroll hasta el final, y haces click el link a la Página 2. Cuando la Página 2 se carga, tu visita no contará como rebote para la página inicial ni para la Página 2.
Ahora, imagina que implementamos scroll infinito, como vimos en sitios como Twitter y Facebook: cuando haces scroll para abajo hasta el último post en la lista, la página automáticamente carga los siguientes diez posts. Hiciste prácticamente lo mismo que antes, pero porque no hiciste click en un link para cargar una página separada, no cuenta como visitar dos páginas -si dejas el sitio, va a contar como un rebote.
Esto parece una decisión bastante arbitraria. Afortunadamente, Google Analytics provee una forma de arreglarlo: en el código que dice "trae los siguientes diez posts y agregalos a la lista", podemos también decir, "ah, y dile a Google Analytics que esto no cuenta como rebote".
Volviendo a Co.Labs
Creo que puedes justificar razonablemente ignorar un rebote manualmente en ese ejemplo, pero -no es sorprendente- cuantos sitios utilizan esa feature manualmente para ignorar rebotes en toda clase de otras situaciones.
"Estuvo en la página por más de treinta segundos? Dile a Google Analytics que esto no cuenta como rebote!" "Hizo scroll pasando la primer pantalla? Dile a Google Analytics que no cuenta como rebote!"
Personalmente, no soy un entusiasta de esto, porque embarra la definición de un rebote, que puede agregar confusión innecesaria.
Y esto parece ser exactamente lo que pasó en Co.Labs. Tan pronto como haces scroll de algunos pixeles en la página, tu visita ya no cuenta como un rebote. Es posible que los editores invirtieran en historias largas para hacer que los usuarios hagan más scroll, pero sospecho que, en realidad, el trackeo de scroll fue implementado alrededor del mismo tiempo que los editores de Co.Labs comenzaran sus experimentos.
Conclusión
La lección, nuevamente, es que el contexto es importante: el coeficiente de rebotes no es un número mágico que deberíamos apuntar a mantener en cierto rango: es importante saber que representa realmente.
Quizás notaste que, si bien el promedio de páginas/visitas no cambió mucho en el segundo gráfico, si lo hizo el tiempo promedio en la página. Ese es un buen resultado, cierto? Bueno... quizás no. Lo explicaré en mi próximo post.
