Este año hemos redoblado los esfuerzos por aumentar el número de experimentos que realizamos en Liftshare.com (habitualmente, A/B tests multivariante), habiendo diseñado e implementado decenas de ellos. En este post me gustaría compartir algunas de las lecciones aprendidas…
1/ Definir el problema en primer lugar, las soluciones después. A menudo podemos caer en la trampa de pensar directamente en la solución, en vez de prestar atención al problema que queremos resolver. Por ejemplo, si queremos mejorar la tasa de respuesta de nuestros usuarios a mensajes procedentes de otros usuarios (definición del problema), puede que encontremos posibles soluciones provenientes de diferentes áreas (implementar push notificacions si disponemos de una app, mejorar los emails que se envían con cada mensaje, crear un espacio de notificaciones cuando los usuarios acceden a su cuenta, etc.). Una correcta definición del problema al que nos enfrentamos nos permitirá testar diversas soluciones de un modo sistemático, sin obcecarnos con ninguna en particular.
Organizar reuniones periódicas de tipo brainstorming en las que abordar problemas y enunciar experimentos potenciales puede ser recomendable.
2/ Disciplina. Es fácil realizar uno o dos experimentos y luego olvidarse de ellos. En nuestro caso, tenemos un número mínimo de experimentos a realizar cada en cada trimestre, como objetivo trimestral. Esto nos ha obligado de alguna manera a incorporarlos dentro de nuestro proceso habitual de trabajo (en este caso, la metodología ágil conocida como Kanban). Lo importante no es tanto que consigamos experimentos de éxito, sino comprometernos a realizar un determinado número de experimentos pase lo que pase. Si cada vez que desarrollas una nueva característica de producto, ésta contiene una variante A y otra B, el aprendizaje acerca de esa nueva funcionalidad será notablemente superior. Pero, claro, desarrollar así requiere de disciplina y de un cierto cambio de mentalidad: lo importante no es solo cumplir con los entregables lo más rápido posible, sino aprender lo máximo posible sobre la conducta del usuario.
3/ Aprender de los experimentos que no arrojan conclusiones o que suponen regresión. No hay que desesperar cuando nuestros experimentos no consiguen mejorar la conversión como nos gustaría. En efecto, como señalan desde Optimizely, el 60% de los experimentos resultan inconcluyentes, mientras que el 10% implican un retroceso o empeoramiento del nivel de conversión inicial. En otras palabras, solo el 30% de los experimentos van a arrojar un resultado de éxito. Esto significa que aprender del restante 70% es imprescindible. En muchos casos, gracias a ello descubriremos determinados comportamientos del usuario que nos llevarán a diseñar nuevos experimentos ganadores.
4/ ¿Cuándo alcanzamos relevancia estadística? Hace unas semanas conocimos a Benjamin Mitchell, que había sido product manager en bbc.com, donde contaban con en torno a un millón de visitas al día. En su caso, en cuestión de horas podían emitir conclusiones precisas sobre un determinado experimento. No obstante, en webs de tráfico medio o bajo puede que necesites varias semanas para evaluar los resultados. A veces, dependiendo del experimento en cuestión y de la calidad del tráfico, o dependiendo del modelo de negocio (por ejemplo, en escenarios B2B), puede que este análisis pueda ser concluyente con decenas y no miles de visitas.
5/ Producir información públicamente contrastable para el resto de la empresa. Con frecuencia la toma de decisiones puede seguir el modelo de “la persona más importante”, sin que la opinión de aquélla esté fundamentada en números. Los experimentos ofrecen la oportunidad de utilizar datos precisos con los que rebatir creencias y opiniones (que al final no dejan de ser meras hipótesis, quizás erróneas). Encontrar espacios para comunicar las principales conclusiones derivadas de nuestros experimentos al resto de departamentos es una forma de demostrar su valor.
6/ Kanban específico para experimentos. Dar relevancia concreta a los experimentos y tener un sistema para gestionar su evolución puede tener sentido (recurriendo a herramientas como Trello o Jira). Por ejemplo, nosotros tenemos un kanban de desarrollo y otro para experimentos; mientras que este último alude a cada experimento en cuestión, el kanban de desarrollo contiene las tareas necesarias para poner tal experimento en producción, de modo que no hay duplicidades.
Asimismo, y aunque conlleva más tiempo, elaborar un breve informe sobre cada experimento ayuda a cubrir los diversos aspectos a tener en cuenta y, sobre todo, nos permite volver sobre experimentos pasados y asegurar que el aprendizaje puede ser consultado por cualquiera y en cualquier momento.
7/ Recurrir a diversas fuentes de análisis si es necesario. Una única fuente o herramienta estadística puede no ser suficiente para comprender la repercusión de un experimento (lo conveniente, en todo caso, es establecer de antemano qué KPIs tendremos en cuenta para medir su resultado). Por ello, puede que tengamos que acudir a un conjunto de fuentes, como pueden ser eventos de Google Analytics, nuestra propia base de datos, análisis de cohortes y embudos, etc. No contrastar las diversas fuentes puede hacer que se nos escapen aprendizajes valiosos sobre el comportamiento del usuario. Tampoco hay que olvidarse de hablar con los usuarios en primera persona, o de herramientas como Usertesting.com o, incluso, Amazon Mechanical Turk.
