La búsqueda de un KPI asesino
Cómo la simplificación radical de las métricas de rendimiento ayudó a una empresa a alinear el comportamiento de los empleados con los objetivos de la organización, realizar inversiones más inteligentes en el negocio y fomentar una cultura de aprendizaje y cooperación.
Las métricas de rendimiento se encuentran entre las herramientas más poderosas de los gerentes: establecer los objetivos correctos y realizar un seguimiento preciso del progreso puede ayudarlo a llevar su negocio a donde quiere que vaya. Sin embargo, para ser efectivos, los objetivos y las métricas deben ser claros y simples, y cuanto menos, mejor.
En nuestra empresa en crecimiento, hemos aprendido que la simplicidad aumenta nuestras probabilidades de lograr lo que queremos. Cuando nuestras metas eran demasiado numerosas y demasiado complejas, las decisiones de los empleados no se sincronizaban dentro de los equipos o entre ellos, lo que significaba que los grupos y las personas tiraban en varias direcciones y no lograban producir los resultados deseados a gran escala. Por lo tanto, nos propusimos identificar un único indicador clave de rendimiento que unificaría el comportamiento dentro de un grupo importante de atención al cliente, la unidad que diseña, crea y administra nuestra tienda en línea, y también podría servir como moneda compartida entre equipos, permitiéndonos hacer inversiones más inteligentes en el negocio. Pero nos dimos cuenta de que apostar por un KPI sin ponerle algún tipo de verificación podría tener graves consecuencias no deseadas. Sabíamos que cualquier objetivo principal tenía que estar limitado por una restricción, maximizar “x” y minimizar “y”.
Esta es la historia de cómo Agoda, la subsidiaria con sede en Asia del grupo de viajes en línea Booking Holdings, se abrió camino hacia un enfoque único de “KPI + restricción” que nos ayuda a administrar una buena parte de nuestro negocio. Se necesitó algo de prueba y error para llegar allí; los KPI que desarrollamos y probamos a lo largo del camino promovieron comportamientos y resultados tanto positivos como contraproducentes. Sin embargo, gradualmente encontramos nuestros principios rectores, los implementamos, mejoramos nuestros resultados comerciales y fomentamos una cultura de aprendizaje y cooperación en el proceso.
Como creemos que nuestras experiencias y conocimientos pueden ser útiles para otras empresas, tanto dentro como fuera del comercio electrónico, los compartimos aquí.
Probamos nuestro camino hacia una métrica
Desde los primeros días de la empresa, Agoda se ha centrado en mejorar continuamente su interfaz o escaparate, el sitio web y las aplicaciones móviles a través de los cuales los clientes buscan, seleccionan y compran productos de viaje, para convertir las visitas al sitio web en ventas. Al aumentar su tasa de conversión, una empresa digital puede orientar su marketing de manera más efectiva, porque los clientes existentes son más fáciles de atraer que los nuevos. Los ingresos de los clientes convertidos se pueden implementar para hacer que el marketing sea cada vez más eficiente, lo que se traduce en más conversiones.
A la luz de estos beneficios, la tasa de conversión puede parecer el KPI primario perfecto para nuestro negocio, con el retorno de la inversión como una restricción obvia. (Después de todo, ¿por qué perseguir conversiones que son extremadamente difíciles de obtener y que probablemente no valdrán la pena más tarde?) Para calcular la tasa de conversión, normalmente divide los números de tráfico por las ventas. Desafortunadamente, medir el tráfico no es tan sencillo como parece; es complicado por numerosos factores, incluidos los bots difíciles de manejar, el marketing agresivo y las muchas formas indirectas en que los clientes pueden acceder al sitio.
Aun así, sabíamos que queríamos cosechar los beneficios del aumento de las conversiones y hacerlo más rápido que la competencia. Pero, ¿cómo lo haríamos y seguiríamos nuestro progreso con precisión, dado lo imprecisos que podrían ser esos números de tráfico? Para resolver eso, comenzamos a realizar pequeños experimentos, uno tras otro, para probar los cambios de plataforma que teníamos razones para creer que aumentarían las conversiones. Utilizamos pruebas A/B, que consistían en cambiar un solo elemento (como un color, un botón, una imagen o un mensaje, como “¡Las habitaciones son limitadas!” o “¡Buena elección!”) para un subconjunto de nuestros usuarios y comparar los resultados con los de un grupo de control. Los experimentos “ganadores” (aquellos que generaron más reservas que el control) se incorporaron a nuestra codificación y se extendieron a los clientes de manera más amplia.
Encontrar esos ganadores fue difícil. A menudo, nuestras hipótesis sobre lo que mejoraría las ventas resultaron ser incorrectas. Alrededor del 80% al 90% de nuestros experimentos fueron buenas ideas de personas inteligentes, pero no mejoraron nuestro negocio; muchos en realidad empeoraron los resultados. Por ejemplo, si les decimos a los clientes: “¡Reserve ahora o esta habitación desaparecerá!” podemos motivarlos a comprar la habitación, o podemos molestarlos y hacer que abandonen el proceso de reserva. Además, hacer un cambio de software podría introducir un error del que no estábamos al tanto. Pero ese tipo de fallas fueron parte del proceso.
La experimentación nos ayudó a determinar qué iba a funcionar y qué no. Inicialmente, realizamos experimentos únicos, pero para aprender de ellos de manera más efectiva, creamos un sistema centralizado que nos permitía registrar y analizar los resultados de las pruebas en detalle y luego realizar y medir cambios en el sitio web. Este “motor” de experimentos nos brindó una forma consistente y escalable de tomar decisiones y evaluar su impacto en la conversión, y nos brindó una métrica primaria temprana con la que trabajar: la velocidad de experimentación.
Descubrimos los pros y los contras de Velocity
Dada la importancia de los experimentos para nuestras decisiones iniciales, nos dimos cuenta bastante pronto de que necesitábamos aumentar la velocidad de nuestro motor de experimentos. Así que establecimos la velocidad como un KPI principal para enfocar nuestros esfuerzos de conversión, definiéndola como la cantidad de experimentos que realizamos cada trimestre. Sabíamos que no había forma de que pudiéramos crecer a un ritmo significativo si ejecutábamos muy pocos de ellos, sin importar cuán positivos fueran los resultados para cada uno.
Al dividir nuestros experimentos con mayor precisión, probando un elemento a la vez para que pudiéramos aislar y solucionar problemas más rápido, y traer gerentes expertos en ingeniería y gestión de procesos para simplificar las cosas, pasamos de unas pocas docenas de experimentos iniciales por cuarto a más de 1,000 solo unos pocos trimestres después. Si bien este enfoque nos ayudó a identificar muchas formas de aumentar nuestra tasa de conversión, también provocó que el código de programación de nuestro sitio se deteriorara debido a la frecuencia con la que se realizaban los cambios. En resumen, la cantidad de errores explotó. Como resultado, introdujimos una restricción en el KPI: la calidad del código, medida por el número y la gravedad de los errores.
El impulso de la velocidad, con la restricción de calidad, cambió la forma en que operamos. Nos llevó a revisar nuestra arquitectura de implementación para ver cómo podíamos implementar cambios más rápido, pero no tan rápido como para causar daños. Creamos herramientas de software para unificar, automatizar y acelerar la implementación y el monitoreo de código en cientos de miles de servidores en nuestros centros de datos en todo el mundo.
Muchas empresas implementan código nuevo solo semanalmente o incluso con menos frecuencia; lo hacemos cuatro o cinco veces al día. Para apoyar ese ritmo, repensamos nuestros sistemas, personal y estructura organizacional. A medida que aumentaba la cantidad de errores, tuvimos que desarrollar mejores técnicas de control de calidad. Invertimos mucho en nuestro centro de operaciones de red, que realiza un seguimiento del rendimiento de nuestra plataforma para alertarnos cuando se producen desviaciones significativas del comportamiento normal del sitio web.
Siempre hay desviaciones, que pueden ser causadas por cambios internos o por factores externos; solo un buen dominio de las estadísticas puede ayudarlo a determinar qué desviaciones son relativamente normales y cuáles son indicaciones de problemas reales. Así que desarrollamos sistemas para encontrar cambios estadísticamente significativos, incluso en patrones menores. También construimos herramientas de monitoreo para mapear cambios de código a patrones de rendimiento para que pudiéramos analizar las causas raíz y resolver problemas más rápido. E invertimos en sistemas de datos para rastrear el tráfico en cada mercado, identificar anomalías significativas y alertar al centro de operaciones de la red, ayudándonos a ver cosas que de otro modo no hubiéramos visto y responder rápidamente.
Revisamos nuestro KPI principal
Centrarse en aumentar la velocidad cumplió un propósito fundamental: nos ayudó a realizar muchos más experimentos que impulsaron las reservas hasta cierto punto. Pero a veces creó los incentivos equivocados. Los equipos podían obtener una puntuación alta en velocidad (y ser recompensados por ello) ejecutando muchos experimentos pequeños, independientemente de si estos experimentos se correlacionaban con aumentos significativos en la tasa de conversión de la plataforma.
Para determinar qué cambios brindaron las mayores oportunidades de conversión, creamos herramientas de análisis de datos más sólidas. Gradualmente, quedó claro que para fomentar esas oportunidades más grandes, necesitábamos cambiar nuestro KPI principal.
