JotDown, el New York Times y las visitas de 53 minutos de duración

¿Cuantas veces has empezado a navegar por una web y en mitad de esa navegación has empezado a hacer otra cosa, dejando el navegador en un segundo plano? ¿Acaso haces el mismo caso a todas las pestañas que tienes abiertas en tu navegador? La mayoría de usuarios no se paran a pensar en eso, pero a los analistas puede darnos algún que otro quebradero de cabeza, sobre todo dependiendo de la configuración de la herramienta de medición que se use. Como en muchos otros casos, cualquier cosa relacionada con Internet es propensa a fallar y no podemos tomar todos los datos como 100% válidos, por eso hoy os voy a contar un curioso caso con el que me he topado recientemente y que saca a relucir parte del desconocimiento que existe en nuestro país sobre la Analítica Web, sus métodos de medición y la interpretación de los datos obtenidos.

Hace aproximadamente una semana me crucé con el siguiente vídeo de JotDown Magazine mientras ‘perdía’ el tiempo en twitter:

Como podéis imaginar lo primero que pensé al ver el vídeo fue ‘Esto no es posible’ y con algo de incredulidad pero con toda la inocencia del mundo lancé un Tweet mencionando a @JotDownSpain alegando que no terminaba de creerme el famoso dato de los 53 minutos de media para las visitas a su web. Este simple e ingenuo Tweet llamó la atención del Community Manager de JotDown, que se empeñó en intentar convencerme de la validez del dato, argumentando que son datos auditados por OJD Interactiva y, por lo tanto, 100% válidos. Pero yo, que he sido enseñado por los mejores en esto de la analítica web ;), no terminaba de creérmelo, lo que derivó en una conversación un tanto surrealista. Afortunadamente para mi, y para JotDown, uno de sus redactores entró en escena y a pesar de que al principio también optó por atacar mi postura finalmente me propuso comprobar de primera mano la validez de los datos dándome acceso a su cuenta de Google Analytics. Aquí tenéis la conversación de Twitter para que veáis como no hay que actuar cuando se es Community Manager (Chicos, no todos somos trolls con el único objetivo de causar revuelo, algunos tenemos motivos más nobles…).

Twitter javiriestra jotdown

Antes de continuar voy a permitirme la libertad de agradecer a Paula Sanchez y a Iñaki Huerta por su ayuda con este asunto, lo primero que hice cuando empecé a investigar esta circunstancia fue consultar con ellos mis dudas sobre esta situación y ambos me dieron muy buenos consejos. En el caso de Iñaki coincidió justo con que él estaba escribiendo en ese momento un post que trata sobre un tema muy similar a este y pudimos cruzar impresiones. También agradezco el apoyo a mis compañeros de Kpisland que me han animado a escribir este post (gracias Héctor por revisar mis dudas con el código) y por último a Ángel L. Fernández, que tras haber cruzado algún que otro tweet subido de tono al final me ha permitido investigar más este asunto. Quiero que también conste en acta que no tengo nada en contra de JotDown, es más les sigo en Twitter, leo algunos de sus artículos de vez en cuando y tengo en el salón de mi casa el ejemplar especial de series que publicaron hace tiempo. Pero no por eso voy a dejar de cuestionarme unos datos que, para que nos vamos a engañar, solo se lo cree el que lo difunde. Espero que el caso que voy a exponer les pueda ayudar de cara al futuro.

¿Pero esos datos no están auditados? Sí, y aquí es donde llegamos al inicio de mi análisis, que me ha llevado a hablar directamente con ellos (muchas gracias por las aclaraciones) y tener más claro como funcionan sus auditorías y el papel que juegan en la obtención de los datos. Desde JotDown me han asegurado que es OJD quien les da el código de seguimiento de Analytics, pero OJD me ha confirmado que eso no es cierto. Ellos, como auditora, envían a sus clientes unas directrices indicando que datos se pueden medir y cómo hacerlo, es responsabilidad de cada web el implementar la herramienta de seguimiento. A continuación los auditores de OJD comprueban que dicho código está midiendo correctamente las visitas en todas las páginas del sitio web y finalmente se encargan de ‘limpiar’ esos datos, asegurandose de que no se tienen en cuenta mediciones de visitas sospechosas como podría ser el caso de un bot. En cualquier caso es deber de cada web el reportar los datos obtenidos con su herramienta de medición, tomando OJD esos datos como válidos siempre que se cumplan sus requisitos. Vamos a echarle un ojo al código de seguimiento de JotDown para ver donde puede estar el problema:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXXX-X']);
_gaq.push(['_trackPageview']);
(function () {
var ga = document.createElement('script');
ga.type = 'text/javascript';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
//refresh cada 4 min => 240seg
var myVar=setInterval(function(){refresca()},240000);
function refresca(){
_gaq.push(['_trackEvent', 'NoBounce', 'refresh', '240']);
}
//]]>

Efectivamente, la web de JotDown se refresca automáticamente cada 4 minutos (podéis verlo en la línea 15), lo que supone un ligero problema a la hora de calcular el tiempo medio de visita y de estancia en página. Google Analytics no tiene en cuenta el tiempo que pasamos en la última página que visitamos de un sitio web, pero añadiendo este tipo de eventos podemos ‘trucar’ el dato para que el código de seguimiento envíe datos a Analytics continuamente. Aquí podéis ver como la web de JotDown ha lanzado el evento varias veces en una sesión de prueba que hizo mi compañero Héctor.

Debug JotDown

12 eventos en casi una hora

Para comprobar si el resto de webs que aparecen en las publicaciones de OJD (y en el vídeo de JotDown) se rigen por el mismo patrón hemos estado monitorizando su código de Analytics durante varias horas y no hemos encontrado más que algún evento ‘NoBounce’ a los 20-30 segundos para poder tener un dato de Tasa de Rebote algo más ajustado a la realidad, pero nada de eventos que refrescan la página cada cierto tiempo. Aquí tenéis el ejemplo de rtve.es:

Debug Rtve.es

Un sólo evento en casi 4 horas

De hecho OJD nos ha confirmado que los eventos ‘refresh’ son permitidos en webs que tengan contenido que se modifica a ‘tiempo real’ como por ejemplo una web de bolsa o de eventos deportivos. En ningún caso se debería de contar como tiempo de permanencia en página un evento refresh que tiene lugar en una web de contenido estático.

Pero ¿el código de JotDown no solucionaría el problema de la falta de medición del tiempo que pasamos en la última página visitada? Sí, pero estaríamos creando otro tipo de problemas. No quiero hacer profiling, pero aunque JotDown cuente con unos artículos extremadamente interesantes, sería muy arriesgado asumir que todos sus visitantes están leyendo su contenido durante todo el tiempo que dura la visita. Todos hemos abierto alguna vez un enlace a un post que nos parece muy interesante y a mitad de la lectura nos llaman por teléfono o nos llega un email o nos llega una notificación de alguna red social y en ese momento dejamos de leer y pasamos a otra pestaña o usamos otro programa o, directamente, nos levantamos de la silla. Yo soy el primero que tiene siempre infinidad de pestañas con un montón de información interesante esperando a ser leída (y se pueden tirar abiertas todo un día).

Pero esto, como digo, son conjeturas y creo que es mejor comprobar esto con los datos que nos muestra OJD y que hemos contrastado con los datos recogidos en la cuenta de Analytics de JotDown. Por razones que entiendo pero que no comparto, JotDown no nos permite mostrar datos sacados de su cuenta de Google Analytics a pesar de asegurarles que no mostraríamos cifras sino gráficas de tendencias o valores porcentuales, por eso los datos con los que vamos a trabajar son los que se pueden obtener en la web de OJD, pero todo ha sido contrastado con sus datos de GA.

Lo primero a tener en cuenta es la fecha en la que se creo el evento que hemos identificado como el culpable de generar un tiempo medio de visita tan elevado. Si miramos los datos publicados por OJD en los últimos meses vemos cuándo nace el problema. Es en el mes de marzo cuando se empieza a medir el tiempo de las visitas con dicho evento y es ahí cuando vemos un cambio tan significativo. De nuevo, no quiero hacer presunciones, pero seguramente esos 3 minutos de duración media de visita tampoco sea un dato correcto, pero puestos a compararnos con los demás, ese dato sería el válido teniendo en cuenta la forma en la que se obtuvo. Hay que resaltar que en el mes de marzo JotDown cambió su sistema de medición y pasó de ComScore a Google Analytics y según OJD es normal ver alteraciones en los datos cuando se cambia de herramienta de medición, es algo que saben y algo que notifican cuando publican sus datos. De hecho Google Analytics no es un sistema de medición homologado por OJD y por eso es necesario realizar auditorías de esas webs, si los datos fuesen tomados con otras herramientas (como la ya citada ComScore) esos datos se tomarían como válidos desde su origen.

Datos OJD Evolución Mensual

Si pudiésemos desglosar las visitas del mes de mayo en función del tiempo que permanecen en el sitio web, veríamos como casi la mitad de las visitas permanecen menos de 10 segundos en la página mientras que casi una quinta parte de las visitas permanece en el sitio web un tiempo muy prolongado. Nuestro siguiente paso sería segmentar esas visitas –¡Segmenta y vencerás!- para que se nos muestren aquellas que han permanecido en la web más de 53 minutos. De esta forma podríamos ver cual es el tiempo medio de visita que han generado aquellos que están por encima de la media. Os aseguro que los tiempos son desorbitados y el % de visitas que genera esos tiempos, aunque va disminuyendo según se va segmentando, suponen un a porción interesante de las visitas. Podríamos estar así un buen rato hasta dar con aquellas visitas que directamente se han dejado la web abierta durante días y días.

Otro segmento que podríamos aplicar sería ver aquellas visitas que tan solo han visitado una página del sitio web. En ese caso pude comprobar como más de la mitad de las visitas que solo veían una página permanecían en esta menos de 10 segundos y la media del tiempo de visita casi alcanzaba la media hora. Los datos a analizar podrían ser casi infinitos, desde intentar dar con aquellas páginas del sitio web que más tiempo por visita acumulan o filtrar a los redactores y administradores del sitio web para que sus datos no se muestren (aunque no afecta mucho a los datos) hasta dar con la fuente de tráfico que más está contribuyendo a este hecho.

Todo esto que os he contado al final viene a decir lo mismo que nos cuenta Iñaki Huerta en su post sobre el uso de los datos de Analytics como un estandar. Cuando una herramienta como Google Analytics te permite alterar los datos que recoge no puedes tomarlos como un dato comparable con el de otras webs. Si queremos que los datos de Analytics sean comparables habría que fijar unas reglas básicas de implementación de la herramienta o, como ya se viene haciendo, tomar los datos de otras herramientas como ComScore como un estandar de comparación entre webs del mismo sector. Es posible que los datos obtenidos con ComScore tampoco sean 100% ciertos, pero todos estaríamos cortados por el mismo patrón. Para seguir con el ejemplo del vídeo de JotDown, el New York Times no tiene implementado Google Analytics en su web, por lo que los datos de duración de visita no se estaría midiendo igual, cayendo en el mismo caso que rtve.es.

¿Quiere decir esto que no hay forma de saber el tiempo que permanece una visita en nuestro sitio? Si y no. Me explico, cuando hablamos de tiempo de permanencia en nuestra página siempre vamos a tener la incertidumbre de no saber si ese visitante ha estado delante de la pantalla todo el rato, pero si que podemos jugar con otros datos para saber si por lo menos ha leído nuestro contenido.

Existen eventos para medir el consumo de contenido en una web y podríamos saber hasta donde han hecho scroll los visitantes y cuanto han tardado en llegar hasta cierto punto de la página. Pero como suele pasar en el mundo de la Analítica Web, esos datos nunca serán 100% fiables. Hay que buscar la tendencia y no la cifra y observar si los datos van evolucionando de forma gradual y sin cambios extremadamente sospechosos.

En conclusión, no te creas todo lo que te dice tu Analytics, cerciórate de que tu código de seguimiento está bien configurado y se consciente de las alteraciones que pueden sufrir los datos recogidos si juegas con los eventos.

Me despido agradeciendo de nuevo a todo el mundo que me ha echado una mano con este asunto que comenzó de la forma más absurda y poco a poco se ha convertido en un ejercicio de lo más interesante con el que he seguido aprendiendo cosas nuevas sobre este fascinante mundo de la Analítica Web. Os animo a que aportéis en los comentarios lo que se os ocurra en relación a este tipo de situaciones con el código de seguimiento de Analytics y el uso de esos datos de forma pública y ‘oficial’.