Hace tiempo que quería escribir este post, pero no se me ocurría como terminar de enfocarlo. En mis clases sobre Analítica Web suelo decir que uno de los motivos por los que instalar Google Analytics es que poco a poco se ha convertido en un estándar. Es decir, al ser una herramienta que usan la mayor parte de las webs del mundo resulta fácil comparar el mismo dato en distintas webs que la usen. Esto no pasa con otras herramientas, pues como cada una calcula sus indicadores de forma distinta un dato entre dos herramientas distintas normalmente es poco comparable.

Todo esto, teniendolo bajo control, es cierto. Pero no significa que el dato de Google Analytics sea un valor indiscutible que podamos usar para demostrar públicamente nuestra grandeza al mundo (por llamarlo de algún modo). Sí, este post es una queja hacia una nueva costumbre en el sector: veo cada vez más y más casos en los que se intenta usar los datos de Google Analytics como herramienta para presentar a desconocidos, de forma totalmente indiscutible, quienes somos y nuestro potencial…

• «Tu publicidad la pondré yo en mi sistema y luego te pasaré un informe de analytics para que veas impresiones»
• «Has tenido 2000 visitas en tu post patrocinado, lo dice mi analytics asi que aunque no hayas recibido tráfico la campaña ha ido muy bien»
• «Soy lider en el sector porque mi analytics tiene x mejores datos que el resto»

Señores, Google Analytics es una herramienta interna, que como tal permite ser configurada y manipulada. Peor aun, permite que podamos cometer errores en su configuración. En conclusión, sus datos no sirven para nada fuera del ámbito de la propia empresa que examina el tráfico y que por lo tanto sabe lo que ha hecho y lo que no. Siempre que explico esto acabo poniendo el mismo ejemplo: si a mi me da la gana, puedo multiplicar por 10 el tráfico percibido por cualquier Analytics en cualquier web solo con un par de añadidos a su código… Y es que es tan fácil meter la pata si no controlamos bien cómo funciona la herramienta…

Cómo hay que hacer las cosas

Lo primero, usemos públicamente o no nuestros datos, es asegurarnos de que internamente los datos que usamos son efectivamente validos. Más allá de que podamos o no usarlos para justificar ante terceros según que cosas lo importante es que los datos para nosotros sean reales. Así que antes de nada dos consejos:

1. Asegura tu código

Lo primero es que tu código analytics (el javascript que se copia y pega) debe estar siempre auditado. Los cambios deben testearse y probarse y más importante aún: debemos ser muy conscientes de como afectan a nuestros datos cada acción que realizamos.

Para esto tenemos muchas herramientas en el marcado: plugins para chrome, para firefox y alguna que otra novedosa herramienta que está naciendo. Pero nada de esto servirá si no sabemos lo que es un hit y como afectará lanzar distintos hits a valores como nuestro rebote, tiempo de estancia, páginas vistas, conversiones, etc.

2. Maneja siempre un perfil con datos reales

Lo segundo es tener cuidado con los filtros y hacks que le indiquemos a la herramienta. Están muy bien para conseguir nueva información, pero nunca perdiendo ni un solo dato real. Los datos reales son importantísimos. Son los únicos que nos marcan continuidad y que nos permiten comparar nuestro tráfico limpio con otras webs (aunque sea internamente).

Así que siempre hay que dejar un perfil sin filtros o en su defecto con filtros que arreglen posibles cambios que realicemos en javascript.

Google Analytics no es válido para ofrecer datos públicos

Como decía antes, aún teniendo mucho cuidado, la credibilidad de tus datos es en realidad nula. Al final tu controlas tu analytics por lo que por mucho que prometas que tienes un dato no significa que lo tengas. Repito: Yo podría tener mañana mismo un pico de 10 millones de visitas en mi blog solo lanzando códigos falsos hacia analytics. Podría bajar mi rebote a la mitad tan solo lanzando un par de eventos y podría, sencillamente, guardar con Universal lo que me diese la gana en mi cuenta de analytics (de hecho suelo hacerlo solo para probar cosas en algunas cuentas).

Google Analytics es una herramienta demasiado configurable e inestable para que podamos basarnos en sus datos para cualquier tipo de dato público.

En cambio existen otras herramientas que han sido creadas justo para tal fin:

• En su día tuvimos a OJD implantado en todas las grandes webs y medios
• Más adelante cogió Comscore el relevo
• Y otras herramientas como Alexa Certified, han lanzado sus herramientas de medición de audiencias realistas

Perdonad que no profundice más, pero no es un tema ni que conozca al detalle ni que personalmente me llame la atención. Básicamente tienes que mirar que herramienta de comparación de tráfico usa tu sector e instalarla en tu web para poder compararte con el resto de webs y así pedir más o menos por tu publicidad según lo lider que seas en dicho sector. Este tipo de herramientas si que son válido, pues están hechas justo para eso y en teoría van auditadas para que no hagas tonterias. Aún así no son pocos los que hacen algo parecido a «trampas» y se atribuyen más tráfico con distintas técnicas, pero eso es otra historia, al menos usas la herramienta que toca.

Otro tema importante son los indicadores usados. Esos, como la propia herramienta, no los escoges tu, sino que es el sector el que determina por que métricas deben compararse unas webs con otras. Ahí por ejemplo siempre digo que los grandes medios se equivocan al compararse por usuarios únicos cuando la publicidad sabe de métricas mejores que los usuarios únicos… Da igual, ellos mandan, tu sólo puedes nadar a un poco a contracorriente, cansarte y luego seguir el cauce.

Un caso práctico

Desde que hace 2 años me fui a vivir a las Baleares, he empezado, poco a poco, a interesarme por el sector hotelero y turístico con el que hasta entonces no me había metido a fondo. Hace algo más de un mes, leí un post que me llamó mucho la atención:

• Preferente.com supera las 2 millones de páginas vistas en el último mes

Adelanto que no tengo ningún tipo de relación comercial o de cualquier otro tipo con los responsables de esta web por lo que tomaros el artículo solo como lo que es, un simple ejemplo. Por otro lado, espero que si mi post llega a ellos aprovechen los comentarios como una pequeña auditoría gratuita de su analytics y corrijan sus problemas. Yo solo lo muestro porque me parece un ejemplo muy claro de lo que os expongo y donde puedo basarme solo en aspectos públicos: su post y sus códigos en la web.

Básicamente el artículo es una comparación pública de los datos que una empresa de contenidos con los de otra. No entraré en valoraciones sobre este tipo de prácticas y os pido que vosotros tampoco lo hagáis pues repito, lo interesante es ver el ejemplo.

Resumiendo, ellos mismos indican que sus datos son:

• 2.023.622 de páginas vistas
• 14’45” de tiempo de estancia medio de la visita
• Menos de un 1% de rebote

Sobre las visitas…

A cualquiera que haya trabajado con unas cuantas webs deberían extrañarle estos datos. Para empezar no se nos hablar de visitas ni usuarios, métricas esenciales para un medio de contenidos que hubiesen terminado de redondear su artículo y de hacerlo más creíble para su audiencia. Como comentaba antes: tu no eliges tus métricas, si a día de hoy las visitas mandan, ponlas.

Luego, en el artículo se comentan cosas como:

Ahí está lo que os decía… No, analytics justo no vale para estas cosas, por mucho de que se esté corriendo el bulo de que así es por el sector. Alexa en cambio si que vale justo para eso: no toma el dato de los buscadores, ¡no! lo toma de un plugin que se instala en distintos navegadores de los usuarios y que va capturando toda su navegación para extrapolarla al total de la población. El dato de Alexa se suele criticar porque el perfil de la gente que se lo instala suele ser técnico por lo que las webs tecnológicas se ven hinchadas con respecto a otras temáticas, pero en un mismo sector es un dato bastante bueno si no puedes permitirte nada más. De hecho es costumbre comparar con alexa varias webs muy parecidas en un mismo sector para ver realmente quien tiene más visitas. Las visitas no serán exactas pero la comparación porcentual entre una web y otra suele ser bastante acertada.

¿Y el resto de datos?

Dejando las visitas a un lado, el número de páginas vistas podría ser cierto sin problemas. Hasta ahí todo más o menos bien, pero para webs de contenidos una estancia media de más de 14 minutos y un rebote casi inexistente no son solo datos brutalmente buenos, son sencillamente datos imposibles. NADIE tiene estos datos, repito NADIE. Deberías ser una APP realmente interesante para contar con 14 minutos de visita media y el rebote inferior a un 1% sencillamente no existe.

Claro, lo siguiente que hice fue ir directo al código de analytics de la web a ver que me encontraba. Os paso un resumen de las cosas que vi y que demuestran que los datos de analytics, por pequeños errores pueden ser muy distintos a la realidad, por lo que es mejor no hacerlos públicos como algo indiscutible.

El problema con las páginas vistas

Lo primero que ves es que tienen un problema de códigos de analytics.

Se inicia Analytics 3 veces por página. Dos se realiza con una misma cuenta, la que parece tener problemas de configuración y una tercera con una cuenta que no mezcla los datos pero en la que por lo visto no se han basado para ese artículo.

Para cada inicio de Analytics se provoca una página vista, por lo que para empezar, ya están duplicando el número de páginas vistas de su web solo por un error de doble código. Esto es más común de lo que parece, webs que en distintas actualizaciones han puesto un anaytics olvidándose de retirar el antiguo.

Pero el problema es mayor aún pues han decidido medir algunas métricas en su site de una forma que les está aumentando todavía más sus páginas vistas:

Se captura una nueva página vista cada vez que un usuario hace click en un link de comentarios

Como puede verse ante un onclik, se genera un _trackPageview nuevo. Esto de forma controlada no supone un problema pero si cuando solo estás capturando el onclick y de todas formas luego provocas otras página vista.

Se captura una nueva página por cada 58 segundos en el listado de post

Para poder capturar el scroll que hacen los usuarios lanzan un evento que cada 58 segundos cambia una variable personalizada de valor y genera una nueva página vista. Sin duda en la variable personalizada tendrán el valor del scroll que quieren pero a costa de nuevas páginas vistas que no son reales.

Con estos tres ejemplos ya estamos viendo que si por ejemplo yo entro en esta web, paso un minuto mirando su home a ver si me gusta lo que veo y acabo clicando en los comentarios de una noticia debería haber generado 2 páginas vistas y en cambio generaré 6.

– 2 al llegar
– 1 a los 58 seg para medir mi scroll
– 1 al clicar en los comentarios
– 2 al visualizar la nueva página de comentarios

Sobre el rebote

En cuanto al rebote, encontramos en la web dos detalles que hacen que entendamos porque capturan un rebote tan bajo.

Eventos para anular rebote

Una de las técnicas de configuración de Google Analytics aconsejadas es la manipulación del rebote a base de lanzar eventos cuando se cumpla un criterio que para nosotros signifique que ese usuario ya no es un rebote.

Es una técnica común y muy útil para separar el tráfico de calidad del «tráfico basura» pues el rebote por defecto de Analytics se produce con todos los usuarios que solo hagan una página vista en su visita algo que mete en este saco de tráfico basura a muchos usuarios a los que realmente les interesó lo que vieron (leyeron la noticia pero no hiceron más de una página vista, clickaron en la publicidad, etc.).

El problema es que si manipulas el rebote y luego usas ese dato públicamente estas jugando con tus propias reglas de rebote bajo vs otras webs con rebote sin manipular (y por tanto más alto).

En este caso se hace una curiosa manipulación del rebote a los 40 segundos de estancia en el site:

No solo eso, sino que se hace de forma cíclica (cada 40 segundos se lanza este evento: a los 40, 80, 120, etc.)

Eso ya nos reduciría el rebote muchísimo, pero es que además hay otro factor que lo va a reducir aun más…

Como decía, analytics entiende como rebote toda página de la que solo tiene una página vista, pero es que en este caso eso no sucede casi nunca, pues al entrar en la home o en una noticia directamente provoco dos páginas vistas anulando el rebote aunque solo pase ahí uno o dos segundos. Esto explica sin duda un rebote no solo inferior al 1% sino al 1 por 1000.

El tiempo de estancia

Sobre el tiempo de estancia también hay que entender un poco como funciona analýtics. La gente suele pernsar que la herramienta realmente captura cuanto tiempo pasan los usuarios en el site, pero esto es sumamente dificil por lo que se usan trucos para calcular el tiempo de estancia.

Para saber el tiempo de estancia Analytics realiza el siguiente proceso:

– Captura el tiempo que pasa de página vista a página vista (o evento)
– Para el tiempo transcurre para la última página vista, como no tiene la siguiente no lo calcula.

Eso significa que todas esas mediciones de tiempo de analytics nunca tienen en cuenta la última página vista del usuario. Podéis hacer una prueba simple: filtrad por usuarios con solo una página vista y veréis que el tiempo que da siempre es 0:00, como no tiene la siguiente no lo sabe y pone 0.

En este caso, contamos con el efecto contrario. Recordemos que tenemos un evento que cíclicamente se lanza cada 40 segundos para anular rebote y otro que lo hace cada 58 segundos para capturar scroll. Eso significa que mi tiempo ya no se rige por páginas vistas sino por el último de estos eventos que es lanzado.

Así pues, se produce el efecto captura de navegadores abandonados, que es cuando un usuario deja de ver o leer una página (cambia de pestaña o se levanta del ordenador) y nosotros seguimos capturando el tiempo de estancia de ese usuario. Siempre hay usuarios de este tipo y es conveniente no capturar su tiempo pues no es realista.

Así pues, es suficiente que yo me deje siempre abierta esta página para ir sumando minutos y minutos a mi navegación, por lo que al hacer la media veremos ciertos picos que la aumentan considerablemente. De esta forma las estancias de 14 minutos no son tan descabelladas.

Conclusiones y consejos

Analytics es altamente inestable si no se usa bien. Hay que acudir a expertos para una instalación correcta. Y no lo digo porque yo ofrezca esos servicios (que también, claro), como yo hay muchos otros que pueden hacer un trabajo más o menos avanzado de implementación de analytics pero que validarán que los datos que se capturan son correctos. Basar una decisión de negocio en datos falsos puede suponer grandes pérdidas para algunas empresas.

Al margen de esto, hacer públicos tus datos de analytics es una costumbre que deberíamos erradicar. Existen herramientas mejores para este tipo de publicaciones: más reales, más seguras, más preparadas para ello. Que sin duda nos permitirán realizar afirmaciones mucho más contundentes. Sigamos lo que ya se hace y no reinventemos la rueda. Cada herramienta sirve para un fin, intentar arreglarlo todo con el mismo destornillador no es buena idea.