Aprendiendo a usar Google Analytics

Hasta ahora siempre había usado Awstats y aunque tenía muchas limitaciones, me había acostumbrado a esta herramienta de análisis de estadísticas de servidor. Sin embargo hace unos meses Ubaldo me comentó las bondades de Google Analytics y decidimos ponerlo en Panoramio y Alzado. Al principio la adaptación fue difícil, pero pero tres meses más tarde las ventajas de Google Analytics (en adelante GA) se han hecho evidentes:

Permite comparaciones y seguir tendencias

Un número en bruto no sirve de nada si no lo puedes comparar con otro. Saber que en X periodo han habido Y páginas vistas no te dice mucho, ¿es mucho o poco? ¿va el sitio bien o mal? Solo cuando comparas un dato con otro de un periodo equivalente del pasado los números sirven para algo. Cualquier experto en análisis de datos sabe esto y es justo lo que hace GA.

Con casi cada dato que da, GA incluye por defecto la comparación con un dato anterior y la correspondiente tendencia (flechitas verde, sube, o roja, baja). Esto ayuda a saber de un vistazo la evolución del sitio. La comparación por defecto es de una semana, pero se puede configurar al periodo que nos interese.

Los tradicionales programas de estadísticas dejan mucho que desear porque aunque incluyen todos los datos (incluso más datos que GA), las comparaciones deben ser de memoria. Ciertamente con el tiempo sueles aprender los números que sueles tener, es un poco primitivo, poco fiable y no te da una visión clara de la evolución del sitio.

El gran incoveniente de GA es el primer día. Al estar tan centrado en comparar datos y buscar tendencias, sin datos históricos sus tablas de datos apenas tienen sentido. Puesto que GA no analiza los logs de servidor sino que funciona a partir de un código que se incluye al final de cada página solo puede tener datos desde el día que el código se incluyó. Esto provoca que la primera visión sea decepcionante. Hay que tener paciencia y dejarlo correr un par de semanas para que muestre sus ventajas.

Centrado en lo más probablemente relevante

Tradicionalmente los programas de estadísticas incluyen mucha información poco relevante: información sobre hits, ancho de banda, accessos de robots, host, tipos de archivo descargados, etc. Añadir más información no es gratis, tiene un coste, la información menos relevante quita visibilidad a la información más relevante.

Ciertamente estos datos pueden ser útiles para personas que trabajan en optimización de buscadores o para los técnicos que se preocupan del rendimiento del servidor. Sin embargo este exceso de información menos relevante y compleja, conlleva que el resto de miembros de la organización y especialmente los responsables del sitio, terminen ignorando las estadísticas.

En mi experiencia quienes toman las decisiones, apenas consultan las estadísticas más allá de las páginas vistas y el número de visitantes globales. Normalmente simplemente no entienden las estadísticas, no son capaces de sacar conclusiones y creo que en parte es por a causa de la interfaz de los programas de estadísticas tradicionales. Ignorar las estadísticas supone que los responsables tomen decisiones sin tener en cuenta una información crucial y opten por la intuición en lugar de los datos cuantitativos objetivos.

En lugar de incluir toda la información disponible de una vez, GA se centrá en solo lo que estima que más probablemente sea útil y relevante (fuentes del tráfico, contenidos más vistos, rutas de clicks, conversiones, etc.). Incluso tiene un resumen ejecutivo y el resto de información la segmenta según los objetivos (marketing, contenido, conversiones, etc.) y en diferentes niveles de detalle. La información se dosifica.

Además para no saturar con largos listados por defecto solo muestra los principales 5 datos de cada análisis. Evidentemente sacrifica detalles para dar una visión rápida y clara de lo más relevante para un siti web. Con este enfoque, GA no está dirigido a quienes disfrutan mirando las estadísticas de su sitio hasta el mínimo detalle para saber donde ha sido referenciado su blog y de donde han venido 2 visitantes.

Por otro lado la integración de Adwords con Google Analytics y la posibilidad de definir metas y averiguar conversiones (de visitante a cliente, o de registro a subida de fotos, por ejemplo) son herramientas increíblemente útiles para mejorar la usabilidad del sitio y que ciertamente interesarán mucho a los responsables del sitio y la gente de marketing.

Conclusiones

GA es especialmente útil para quienes no quieren perder demasiado tiempo mirando estadísticas, pero necesitan conocer rápidamente los números más relevantes del sitio y conocer tendencias.

Quienes por distintas razones hasta ahora han prestado poca atención a las estadísticas de su sitio web GA les da la oportunidad para sacarles jugo y utilizarlas como herramienta básica tanto es la toma de decisiones como en el día a día.

Nota: Aunque parte de la crítica que hice a los sistema de estadísticas en el artículo: Logs y estadísticas: la verdad, pero no toda, sigue siendo válida, algunos de los problemas se resuelven con sistemas como GA.

El necesario liderazgo inicial de los técnicos

Hace unas semanas leí el artículo de Rogelio Bernal (al que conocí personalmente en nuestra visita a Googleplex el mes pasado) "¿Estudias informática? ¡Ah, un emprendedor!" y me pareció que tenía mucha razón. Igualmente el artículo de Kirai va en la misma línea.

Creo que alguna gente piensa que el desarrollo, la parte técnica de un proyecto, es algo secundario y por tanto programar es un trabajo aparte que lo puede hacer cualquier currante o incluso se puede sub-contratar y ser realizado por una tercera parte externa.

En mi opinión esto no es así. No diré que los técnicos deben ser los líderes en absolutamente todo tipo de proyectos tecnológicos, pero especialmente en start-ups y en las primeras fases de arranque de un proyecto si considero importante el liderazgo de los técnicos, es más, si es un equipo creo que la última palabra la deben tener ellos.

Quizás suena raro que esto lo diga yo que no soy un técnico, pero la verdad es que en el tiempo que estoy trabajando codo a codo con Joaquín Cuenca, mi socio en Panoramio y que se ocupa de toda la parte "técnica" lo he visto bastante claro. Otros tendrán experiencias diferentes, pero esta es la mia y por eso la cuento.

Es normal que esta idea inicialmente choque, de hecho hablando con Pau Llop al comentarle yo todas estas ideas, trazó un paralelismo con el mundo físico y me planteó esta pregunta "¿Es más predominante el papel de los encargados de las imprentas que el de los periodistas en un diario en papel?"

Mi respuesta es negativa, evidentemente el papel del periodista en un periódico es más importante que el de los impresores, pero creo que no se puede comparar. Los servicios de impresión son, hoy en día, lo que se llama una commodity, algo estándarizado y para lo que hay miles de proveedores que te lo darán con un nivel de calidad muy similar. Para imprimir más copias o tener mejor nivel de calidad simplemente hay que pagar más.

Sin embargo el desarrollo web no es en absoluto una commodity, no está estandarizado y los niveles de calidad que los proveedores tecnológicos pueden aportar son muy diferentes. Por pagar más no tienes más, por tener un equipo más grande no siempre trabajas más rápido. Es normal, es algo nuevo.

A la hora de crear una web, no basta con decirle al programador "quiero esto" porque "esto" se puede hacer de mil maneras, hay mil detalles, mil implicaciones que o se conoce la tecnología muy bien o se puede meter soberanamente la pata. Si el programador no tiene poder para decidir la mejor manera, tomar la decisión última, establecer las prioridades, podemos tener problemas serios.

Esto sucede porque en nuestra ignorancia los no-técnicos muchas veces damos por hechas ciertas cosas que luego no son tan triviales o viceversa. Se pueden poner varios ejemplos sencillos que harán sonreir a más de uno que conozca bien el tema, pero creo que es interesante comentarlos para no quedarnos solo en lo abstracto:

- Conseguir que una newsletter por e-mail enviada simultaneamente a decenas de miles de personas funcione bien no es trivial. No es física cuántica, pero si lo quieres hacer tu mismo y quieres que funcione perfectamente bien, puede darte más complicaciones de lo que parece. De hecho por algo hay servicios comerciales de pago, como elistas del propio Rogelio, muchas empresas están dispuestos a pagar con tal de que les resuelvan el problema. Si no eres técnico puedes pensar que sitios como elistas o como Loquo no tienen mucha complicación a nivel técnico. Es un error típico.

- Servidores: si un servidor esta sobrecargado, el problema no se resuelve tan fácilmente como comprando un servidor más potente, añadiendo más servidores o disponiendo de más ancho de banda. Optimizar los servidores es casi un arte, de hecho hay tanta casuística diferente hoy en día que cada web de las grandes (de las que sirven muchos millones de páginas al día), tiene una solución interna diferente. Si hay suerte servicios como el S3 de Amazon conseguirán convertir el hosting en una commodity donde simplemente pagas más y tienes más, pero a día de hoy pocos sitios pueden aguantar el efecto slashdot sin caer o arrastrarse. Aprovechar al máximo el efecto slashdot o cualquier aparición en medios muy populares es primordial al arrancar un proyecto.

- Las estimaciones de tiempo son muy inexactas porque es muy complicado saber a priori cuando se tardará en desarrollar una funcionalidad y menos aún un proyecto al completo. Al final todos los proyectos se retrasan y mucho. El no-técnico puede empeñarse en poner una fecha, pero la cosa tardará lo que tenga que tardar según lo que se haya decidido hacer o no, por eso es importante que el técnico tenga la última palabra sobre lo que se hace o se renuncia, para reducir al máximo el margen de error. La dificultad de estimar los tiempos hace que las estrategias de desarrollo ágil estilo 37signals suenen muy bien a la gente de perfil técnico que saben bien la importancia y magnitud de estos defases. En muchos casos es mejor empezar con una versión extremadamente sencilla y evitar los grandes planes que aumentan la probabilidad de error en las estimaciones temporales.

Puntualizar que una cosa es hablar del liderazgo de los técnicos y otra decir que todos los técnicos sean buenos para emprender. Aparte de los conocimientos técnicos, hace falta predisposición e interés por otras áreas. Sin embargo creo que es más fácil que un técnico inteligente aprenda de finanzas, periodismo, usabilidad o de marketing, que un MBA, un psicólogo o un periodista aprendan programación u optimización de servidores.

Todo lo anterior no quiere decir que los perfiles no-técnicos sean prescindibles, para nada, el programador aprenderá finanzas o usabilidad, pero dificilmente podrá ser un experto en todas las áreas, necesitará consejos, asesoramiento. Sin embargo a fin de cuentas toda la ejecución dependerá de los técnicos y eso será lo que termine marcando la diferencia.

Los grandes rediseños no son recomendables

Es imposible valorar qué es lo que ha funcionado bien o mal cuando se rediseña una web al completo. Cuando todo cambia es imposible aislar variables y decir qué ha causado qué. Todas las mediciones estarán contaminadas, no sabremos si la sección X es más visitada porque en la nueva versión tiene un link con fuente más grande, porque ha cambiado de situación o porque hemos redactado mejor sus contenidos. Si no sabemos qué es lo que ha pasado no podemos aprender nada ni demostrar nada, todo quedará en especulaciones.

Si no podemos demostrar que han sido determinados cambios concretos que nosotros postulñabamos los determinantes para cierta mejora (aumento de tráfico, de ventas, etc.) separándolos del resto de cambios del gran rediseño, será difícil para los responsables del sitio valorar nuestro trabajo en la mejora de la interfaz. ¿Hay más ventas en la nueva web gracias a la frescura de la nueva imagen que conecta con el público? tal y como argumenta el creativo, o ¿por qué el botón "comprar" tiene mayor contraste y ya no es un texto azul oscuro sobre fondo negro? tal y como argumenta el especialista en usabilidad? Evidentemente esto es una broma exagerada para ilustrar una situación en la que cada uno barre para su casa.

Es más adecuado realizar a diario pequeños cambios en elementos concretos, unas palabras en del texto de un link, la posición de un link, un elemento gráfico, etc. Los efectos positivos, negativos o neutros de los pequeños cambios se pueden medir de manera relativamente fácil. Cuando no está claro el porcentaje de clicks en un link concreto porque hay varios links al mismo contenido y no diponemos de herramientas avanzadas de seguimiento de clicks, se puede recurrir a métodos artesanos como incluir una página oculta con redirección durante unos días. Así podremos medir con exactitud el antes y el después del cambio realizado.

Los grandes rediseños que incluyen cambios en la estructura de carpetas y urls del sitio suponen tirar a la basura años de indexación en Google y empezar de 0. Aunque hay métodos para indicar a Google las nuevas urls, no siempre funcionan adecuadamente y se toman su tiempo para volve rankear a los niveles iniciales.

Por otro lado los usuarios se molestan con los cambios bruscos de interfaz, no importa que la web claramente mejore, mucha gente se molestará. Los pequeños cambios por el contrario son percibidos positivamente.

Los grandes rediseños solo son buenos cuando realmente la versión anterior era realmente deficiente a todos los niveles y era necesario hacer tabla rasa. El rediseño total tiene sentido especialmente cuando la arquitectura del sitio antiguo bloqueaba la indexación por Google; malas urls, javascript en enlaces, etc.