En mi vida profesional he tenido que enfrentarme varias veces con grandes proyectos de Analítica. Proyectos en los que están involucrados varios departamentos, y que van desde implementar una herramienta, a sacarle partido a los datos, pasando por formar a los responsables pertinentes. Un camino largo y complejo, en el que si no aplicas estrategias de gestión del cambio de forma adecuada te quedas sin gasolina nada más arrancar.
Voy a ser totalmente sincero: si puedo contar esto es porque lo he vivido. He visto fracasar proyectos, y si alguien de este sector dice que eso no le ha pasado, entonces no sabe de lo habla o, peor aún, está mintiendo.
No soy muy amigo de las enumeraciones, un recurso que simplifica la descripción de procesos complejos y que suele transmitir una falsa sensación del tipo “esto es muy sencillo”. Pero aunque me traicione a mí mismo, hoy voy a enumerar.
Para que un proyecto de Analítica salga bien, debemos seguir una hoja de ruta previamente consensuada con el cliente, en la que no deberían faltar los siguiente puntos:
1. Entender los objetivos de negocio.
2. Determinar qué debemos medir para saber si los objetivos de negocio se están cumpliendo.
3a. Seleccionar una o varias herramientas capaces de recoger lo que se necesita medir.
3b. Auditar las herramientas con las que trabaja el cliente, para determinar si son capaces de recoger lo que se necesita recoger.
4. Implementar las herramientas seleccionadas, o mejorar la implementación existente para recoger los datos necesarios.
5. Recopilar datos, y revisar la correcta recepción de los mismos.
6. Analizar los datos y establecer hipótesis de mejora.
7. Programar tests para probar nuestras hipótesis, y determinar si los KPIs establecidos en la etapa 2 son los adecuados.
8. Replantear los KPIs en función de los resultados de la etapa 7.
9. Repetir los test, o programar acciones nuevas, en función de los resultados de la etapa 8.
10. Vuelta a empezar desde el punto 6.
Por lo general, se avanza satisfactoriamente hasta el punto 3. La empresa está motivada y gran parte del trabajo depende de los analistas. Las cosas suelen estancarse, en mayor o menor medida, en la fase de implementación.
Es aquí donde el proyecto pasa del departamento de marketing al de IT (o a los desarrolladores externos), que son los encargados de implementar el código de seguimiento en las páginas, del envío de HITs mediante protocolo HTTP y, en general, de todas las actividades que desembocan en la recopilación de los datos definidos en las fases anteriores.
La fase de implementación, y resumiendo mucho puede subdividirse a su vez en:
- Implementación propiamente dicha
- Revisión y ajustes
Es cierto que la irrupción de los gestores de Tags ha simplificado bastante el trabajo de los desarrolladores técnicos, cuando hablamos de implementaciones de herramientas de análisis en Webs y Apps. Sin embargo, nada les libra de tener que poner el script del gestor de tags en todas las páginas del site (u operar con el SDK correspondiente para gestionar el envío de datos desde una APP), y de incluir los dataLayers necesarios para enviar información a las herramientas.
Mientras más compleja es una una implementación, más trabajo tendrán los desarrolladores (evidentemente).
Para evitar que la implementación se transforme en una travesía por el desierto, es esencial involucrar al departamento de IT en el proyecto, y desde su inicio. Es muy común que los técnicos tengan conocimiento del trabajo que se les viene encima cuando ya se han establecido las necesidades de medición, y tras haber seleccionado las herramientas, al final de la etapa tres.
Esto suele tener dos consecuencias claras (y muy relacionadas entre sí). La primera y más lógica: los desarrolladores no tienen tiempo de estimar el esfuerzo que la implementación (o la mejora de la misma) les va a llevar. Consecuentemente, cuando se supone que debería comenzar el trabajo técnico, el equipo encargado ni siquiera ha reservado los recursos y las horas necesarias. Esto supone que el proyecto no está planificado desde su punto de vista (y tienen razón). Además, sin planificación es imposible que el proyecto de analítica sea una prioridad para ellos (puesto que son los responsables de otras mil cosas esenciales).
Esto nos lleva a la segunda consecuencia de una inclusión tardía: el equipo de IT no conoce las necesidades de marketing, y les es difícil entender la importancia del proyecto. Nadie les ha explicado nada, más allá de hacerles llegar un documento de implementación larguísimo que no saben cuándo podrán afrontar.
Ante este panorama, no podemos esperar que para los desarrolladores el proyecto sea una prioridad, o que incluso estén fácilmente dispuestos a convertirlo en prioridad.
Por lo tanto, y a riesgo de repetirme, es primordial que IT esté al tanto del proyecto desde las primeras fases del mismo, y que los responsables finales de los datos les hayan explicado previamente su importancia.
Las etapas 5 y 6, una vez superada la implementación, no deberían dar problemas. Si las cosas se hicieron bien (a nivel técnico) los datos comenzarán a llegar y, dependiendo del tráfico del site, del uso de las APPs o de la cantidad de HITs que se envíen a las herramientas con información “offline”, más tarde o más temprano tendremos un volumen suficiente de datos como para empezar a analizarlos y obtener conclusiones con significancia estadística.
Estas conclusiones deben servirnos para plantear hipótesis de mejora en todos los aspectos, desde los cambios de usabilidad, hasta las acciones de captación de tráfico o usuarios. Las cosas suelen a estancarse de nuevo cuando llega la hora de programar y lanzar test para determinar qué hipótesis de mejora son las correctas. Es decir, en la etapa 7.
Normalemente, cuando se habla de test de optimización la gente piensa en experimentos A/B o multivariantes, en los que se prueba una versión de una página clave contra otras, para determinar cuál de esas versiones es la que más conversiones genera. Es cierto que este tipo de experimentos son esenciales, pero no son los únicos.
También debemos testear nuestas decisiones de captación de tráfico, la eficacia de nuestros mails, nuestra estrategia de precios (si estamos ante una solución de comercio electrónico), la respuesta de nuestros seguidores a los post que publicamos en redes sociales (según el tipo de mensaje que estamos transmitiendo), nuestras acciones de fidelización…
Ya sé, son mil cosas. Todo es complejo. Todo parece urgente. Y por aquí empezamos a vislumbrar las causas por las que todo se detiene cuando llegamos a la fase 7.
a) Los analistas lo solemos tener claro, pero los responsables de los datos no. No saben qué priorizar, y dónde asignar presupuesto y recursos para las acciones de mejora.
b) Las acciones de mejora son complejas. Las de optimizaciòn de procesos, por ejemplo, implican a varios departamentos (marketing, diseño, IT…); las de captación de tráfico dan miedo (hay mucho dinero en juego); las de comunicación también asustan (pues hablamos de la imagen de marca). No es raro que a la hora de la verdad se imponga la lógica del “virgencita, virgencita, que me quede como estoy”.
c) Cualquier proceso de optimización, sobre cualquiera de los aspectos optimizables, conlleva costes, directos e indirectos. Algunos más, otros menos, pero el coste en horas y recursos, en todos los casos, es inevitable. Es común que los proyectos de Analítica se estanquen tras los primeros análisis, porque nadie previó que tras eso habría costes de optimización. Hay veces, y esto es muy triste, en que una fase de implementación mal planificada se come gran parte de las horas, y el presupuesto destinado a optimización se ve inútilmente consumido.
Por lo tanto, para afrontar con éxito la fase 7, es necesario:
1. Definir desde el incio las prioridades de trabajo. Es decir: determinar el orden en el que se afrotarán las labores de optimización, y dejar muy claro a qué departamentos afecta cada una de estas labores.
Los lectores atentos se preguntarán: ¿cómo se pueden definir desde el inico las prioridades de trabajo, si aún no hay datos para saber qué debo mejorar?
Respuesta: es posible, porque me refiero a los grandes bloques de optimización, no a las acciones concretas. Los grandes bloques de optimización son, por este orden:
Usabilidad y experiencia de usuario
Sí, usabilidad. Es común que las empresas quieran empezar por captación de tráfico y fidelización. Desde mi punto de vista eso es un grave error.
Cuando quieres montar una fiesta, primero limpias la casa y la preparas para recibir a los invitados. De lo contrario, corres el riesgo de que estos se vayan pronto (un baño sucio da muy mala impresión), y que no vuelvan más.
La única razón que justificaría empezar por acciones de captación tráfico, es que no haya un volumen suficiente de usuarios como para sacar conclusiones válidas de los datos que se recogen.
Las acciones de optimización de la usabilidad son las que generalmente se realizan mediante los test A/B o Multivariantes. Y aquí me lanzo a la piscina: para mí, la mejor usabilidad es la que genera más conversiones. Ahí queda eso.
Como es evidente, hasta no tener datos no sabremos qué debemos optimizar en Usabilidad. Pero una cosa es segura: si no somos Amazon, habrá mil para elegir. Ya priorizaremos cuando llegue el momento. De todas formas, puedo arriesgarme y precedir tres de los posibles aspectos a mejorar :
– Velocidad de carga
– Procesos de compra
– Formularios de registro
Captación de tráfico
Si ya hemos arreglado la casa, podemos empezar a inivitar a la gente al baile. Pero la cuestión es invitar a los amigos de verdad. No a cualquiera que pase por la calle y que no le guste lo que hemos preparado para cenar. La optimización de las acciones de captación deben tener como fin atraer a usuarios realmente interesados en lo que ofrecemos. La clave es calidad, no cantidad (aunque mientras más usuarios de calidad tengamos, mejor).
Si queremos optimizar la estrategia de captación de tráfico, yo empezaría por las campañas de pago que están activas. Suelen ser las que tienen costes directos más elevados. La optimización de las campañas en Adwords (y por extención todas las de búsqueda de pago) ya la traté en otro post en este mismo blog.
El tráfico orgánico es considerado el santo grial por la mayoría de los gurús del SEO. Pero es necesario tener en cuenta que una optimización del posicionamiento natural en buscadores es una estrategia a largo plazo, si quiere hacerse bien. Por lo tanto, y para no retrasar mucho los resultados, la mejora de las campañas de búsqueda de pago es un buen punto de partida.
Optimización de los contenidos
Hoy en día, cuando hablamos de Web o Apps, los contenidos deberían optimizarse ellos solos. Quiero de decir que lo que se le muestra a los usuarios debería ser acorde a las preferecias de cada uno de ellos. Hay infinidad de herramientas que permiten adecuar dinámicamente la información que se ofrece, y que incluso determinan qué versión del contenido funciona mejor con un segmento dado. Si no se dispone de presupuesto para ese tipo de herramientas, la optimización puede ser “manual”, en cuyo caso volvemos a los mencionados tests A/B o multivariantes.
En el caso de las Redes Sociales, la optimización de contenidos pasa por determinar qué tipo de mensajes, según la naturaleza de la red que estemos usando, genera una mejor respuesta en nuestro público (tengo que escribir un post sobre la medición de la actividad en Redes).
2. Planificar correctamente todas las fases del proyecto, y asignar parte del presupuesto a lo que importa de verdad: optimizar.
3. Transmitir tranquilidad a los responsables (y esto es responsabilidad de los analistas). Es necesario hacer sesiones de formación en las que se explique en qué consiste la optimización, y más importante aún dejar claro que el proyecto de analítica es inútil si se detiene una vez terminada la implementación. Analítica no es implementar, es mejorar.
Es importante explicar que todas las acciones y experimentos se pueden mantener bajo control. Que es posible minizar el riesgo de la mayoría de las acciones atacando a un porcentaje determinado de usuarios, o circunscribiendo las acciones a un segmento muy determinado.
Por ejemplo: es normal que el responsable de comercio electrónico se eche a temblar ante la propuesta de cambios en el proceso de compra de un site o de una App (virgencita, virgencita…). Pero si es consciente de que sólo el 5% de los visitantes verán la versión nueva, y que el otro 95% verá la que él conoce, ya no tendrá insomnio. En el caso de la que nueva versión del embudo sea peor que la de toda la vida, la pérdida en conversiones es asumible.
Otro ejemplo: supongamos que vamos a lanzar 500.000 emails a nuestros suscriptores. Lo que suele ocurrir es que se lancen los 500.000 y listo, confiando en que los mensajes incluidos en el correo capten a los usuarios y los atraigan al site o a la APP.
¿Por qué no hacer un test con 1.000 o 2.000 suscriptores antes? ¿Por qué no enviar varias versiones del mail antes de decidir cuál es la que mejor funciona? 1.000 (o 2.000) suscriptores de 500.000 es un porcentaje bajo. Otra vez minimizamos los riesgos. Pero si somos capaces de dar con la mejor versión y la enviamos a los 498.000 restantes, habremos ganado mucho.
Otro aspecto esencial de la tranquilidad es dejar claro que las acciones de optimización no son una caza de brujas. La gente suele tener miedo de que se cuestione su trabajo. Diseñadores, desarrolladores, gestores de Redes Sociales, responsables de campañas, marketing… Todos pueden sentir temor a que se descrubra que una decisión determinada tomada en un momento dado no fue la mejor de las posibles.
Bueno, eso es la vida. Tomamos decisiones todos los días, y nos equivocamos muchas veces. La cuestión no es “no equivocarse nunca, sino rectificar siempre” (no sé de quién es la frase, pero se la agradezco).
Es muy importante que todos los implicados entiendan que la optimización no es un ataque a su trabajo, si no una mejora del mismo, en la que ellos participarán activamente.
4. Conseguir resultados en un plazo razonable de tiempo: es importante, cuando planifiquemos las acciones de optimización, atacar lo antes posible a un aspecto esencial del negocio. En un e-commerce suele ser el embudo de compra (por poner un ejemplo facilón, que ya llevo 2.310 palabras). Si se optimiza el embudo y se consigue mejorar unos pocos puntos porcentuales la conversión de la App o del site, habremos ganado media batalla.
La otra media la ganaremos cuando hagamos públicos esos resultados, y logremos convencer a la gente que la Analítica da frutos.
Si somos capaces de hacer esto, de convencer a los responsables que todo el trabajo hecho hasta ese momento ha valido la pena, podremos seguir avanzando, y mejorar los KPIs planteados en un comienzo.
Y entramos en la etapa 8 (Replantear los KPIs en función de los resultados de la etapa 7).
Cuando quedaron definidos los objetivos de negocio, se seleccionan una serie de indicadores que, en teoría, reflejan la medida en la que esos objetivos se están cumpliendo.
Sin embargo, hasta la misma elección de KPIs es un tema sujeto a revisión. En primer lugar, es posible seleccionar un indicador que en realidad no refleja lo cerca o lo lejos que estamos de nuestros objetivos. Si un KPI fluctúa, y no notamos grandes cambios en nuestros resultados de negocio, entonces no estamos ante un KPI.
Por otra parte, lo que hoy es un Indicador Clave, mañana puede que no lo sea. No es que hayamos elegido mal… es que nuestros objetivos van cambiando y, con ellos, deben hacerlo nuestros indicadores.
Durante el proceso de análisis e interpretación de los datos, y tras los cambios efectuados con el fin de testear nuestras hipótesis, habremos atacado aquellos elementos que se supone que se relacionan con nuestros KPIs. Deberemos comprobar que los cambios de tendencia que se registren gracias a nuestras acciones, tienen un reflejo en los resultados de negocio y, de esta forma, determinar si nuestra elección de inicial era correcta. Nadie dijo que esto fuera fácil.
Cuando ya hemos establecido la nueva lista de indicadores, el siguiente paso es replantear hipótesis y seguir testeando (etapa 9).
Idealmente llegará un momento en el que todas las acciones propuestas se han llevado a cabo, por lo que debemos volver a la etapa 6, para repetirlo todo de nuevo desde ese punto, y seguir mejorando de forma constante.
Y, en general, esta la historia amigos.
Hay varias formas de enfocar este proceso, pero con mis colegas de trabajo hemos llegado a una conclusión: los proyectos de Analítica no deben atacarse poniendo el foco en la implementación, sino en los resultados. La implementación es un mal necesario, para tener datos que nos permitan mejorar nuestros resultados de negocio.
Siempre nos encontraremos con dificultades, y las etapas técnicas son críticas, pues pueden llegar a bloquear proyectos prometedores, en los que si se hubiese llegado al final los resultados habrían sido realmente interesantes.
Es por esto que cuando las cosas se complican, o se ponen realmente feas, debemos hacerle caso a Winston Churchil: “si estás atravesando un infierno, sigue caminando“.
La recompensa valdrá la pena.
