Pruebo, luego existo


Pruebo, luego existo - Sebastián Kaiser

Un A/B test representa la intención de probar un conjunto de n soluciones en paralelo para ver cuál funciona mejor. "Funcionar" representa un objetivo en particular para el test: vender más, resolver más rápido una situación, obtener más ganancia de cada venta, etc. En la industria se suele hablar de "mejorar la conversión" ante cualquiera de estos casos de éxito.

La movida fue bastante revolucionaria ya que permite encontrar una solución empírica, a un problema cuya solución no conocemos. Al menos una un poco más formal que una corazonada. Básicamente se iguala todo tipo de variables, salvo la que se quiere testear. El tiempo suele ser la clave de estas variables a igualar. El gran porcentaje de estos test tiene relación con los usuarios de nuestros sistemas, esos entes indescifrables y aleatorios que tanto nos cuesta entender, pero que tantos beneficios nos dan.

Cómo todo mundo mágico, tiene su parte oscura. Esos problemas suelen aparecer cuando vamos al código, y pasamos de la teoría a la práctica. Les presento  algunas buenas prácticas asociadas a la implementación de A/B tests en la vida real: con desarrollo continuo de historias, lleno de microservicios, time to market quemando y métricas que no dan lo esperado.

1. No es una herramienta de mitigación de riesgos

El A/B NO es una herramienta para mitigar riesgos de subida a producción. Este es quizás el error más recurrente cuando en una organización se encariñan con los A/B. Muchas veces la subida de una historia no tiene ninguna duda con respecto a su efectividad (cuando no afecta la usabilidad del sistema por parte del usuario) pero se “sube en A/B” para mitigar su impacto ante bugs. MALA PRÁCTICA! Si no confiás del todo en tu deploy, confiá en tu capacidad de hacer rollback. Y si el rollback no es algo viable en ese contexto (porque el problema explota mucho más rápido que tu capacidad de volver atrás o porque simplemente es un escenario que no tiene esa posibilidad), la asignación de tráfico parcial es válida, pero eso no es un A/B. Mi recomendación ante estos casos es resolverlo a nivel balanceo de tráfico entre diferentes apps, haciendo agnóstica a la aplicación en sí que va a recibir tráfico de forma gradual.

2. Repartir el tráfico de forma equitativa

Salvo casos contados con los dedos de una mano, los A/B tienen que repartirse el tráfico de forma equitativa entre cada rama. Es decir, que si es un A/B repartir el tráfico 50% y 50%, si es A/B/C 33%, 33%, y 33% y así. El error común acá pasa por pensar: “tengo una idea arriesgada, voy a subirla al 10% para no correr riesgos”. Lo único que logra tener un A/B corriendo con porcentajes de distribución no proporcionales es llegar a conclusiones más tarde. Si pensás que podes pifiarla fuerte en una rama, la única diferencia entre [25 y 75] y [50 y 50] es que vas a tardar el doble en darte cuenta de que las estás pifiando, pero vas a terminar “afectando” a la misma cantidad de usuarios para poder sacar conclusiones significativas. En definitiva, ¿Cuál es la diferencia entre joder a 500 usuarios en un día que a 500 en dos? Ninguna más que perder un día de estar probando otra cosa.

3. Se necesita una cantidad de tráfico determinada

Para sacar conclusiones reales, el A/B necesita una cantidad de tráfico determinada. Hay muchas herramientas por ahí dando vueltas que ayudan a calcular cuánto tráfico necesitamos para probar una determinada diferencia de conversión con un intervalo de confianza dado. Es importante obtener este número antes de empezar a desarrollar el A/B, ya que puede indicarnos que no tiene sentido hacer la prueba. Por ejemplo: si queremos probar dos posibilidades en una página con 100 visitas por día con una conversión del 6% aceptando un mínimo de mejora de conversión del 10% entre cada caso y con un intervalo de confianza del 95% (que es el standard), necesitamos más o menos 1 año y 5 meses para llegar a conclusiones significativas. Osea, no todo tiene sentido de ser probado, a menos tráfico tenés en lo que querés probar, más tenés que basarte en tu intuición y menos en datos empíricos.

4. Testear sola una app, no todo el stack

Si decidiste tener un esquema de aplicaciones inmenso que se dan servicios unas a otras (la gran, microserviciemos que igual es gratis) es importante que el A/B se realice SÓLO en la app que tiene la lógica a testear y no distribuir la responsabilidad del test entre todo el stack. El error común acá es que en un esquema de apps onda X -> Y -> Z, la app X decida por qué rama ir y que se vayan contando entre las apps sobre la decisión. X le dice a Y que necesita el caso A, Y le dice a Z que necesita el caso A y Z aplica esa lógica. ERROR! Tu hermoso stack de responsabilidades divididas y apps con bajo acoplamiento y bien cohesivas, de repente esta súper acoplado tratando de avisarse entre todos algo que podría estar centralizado sólo en la app que tiene esa responsabilidad.

5. Termina cuando borrás el código perdedor.

El A/B no termina cuando se llega a resultados significativos. El A/B termina cuando borrás el código relacionado a la rama que perdió. Si no borrás todo rastro del test tarde o temprano tu app se convierte en un cementerio inmanejable de código que no se usa. Esto lo tiene que entender no sólo el dev, sino quien pida el A/B (sea producto o comercial). Testear algo siempre es más caro que no testearlo, no importa cuan tuneado tengas tu mecanismo para probar. Y ese costo lo pagan siempre futuras historias, por el tiempo extra que cuesta probar algo y terminar el test de forma prolija, o por la pérdida de robustez, y por lo tanto más tiempo de desarrollo en el futuro.

6. Dejar registro de los resultados

No importa cuán seguro estés de que mostrar precios finales convierte mejor que mostrar el precio por unidad (por tirar un ejemplo), creeme que en un año te vas a olvidar.

7. Vender más no es el único objetivo

Aumentar la conversión no siempre implica cumplir con el objetivo último (vender en el caso de las empresas). Si, por ejemplo, estás mejorando la página donde expones tus productos con un A/B y ambas ramas venden lo mismo pero una lleva más interesados que otra a alguna fase posterior de intento de compra, eso ya es positivo y se puede decir que “convierte” más. Después habrá que ver cómo hacer para que esa gente termine comprando, pero eso ya es otro objetivo.


A pesar de todos estos puntos, los A/B test no dejan de ser una herramienta fantástica, que si la usamos con criterio nos permiten llevar el producto o servicio a un lugar mejor. Pero como dijo el tío de Peter Parker cuando le preguntaron sobre los A/B, “un gran poder, conlleva una gran responsabilidad”.

Sebastián Kaiser

Manager de equipos de tecnología con foco en arquitectura de software, metodologías de desarrollo ágiles y relaciones interpersonales. Lleva más de 7 años trabajando en Despegar.com. Es Ingeniero en Sistemas en la UTN.

Ver más notas y consejos de Sebastián Kaiser.
navigate_next Siguiente

¿Querés ser el primero en descubrir todas las novedades?

Suscribite YA y recibí información con el mejor contenido, empresas y oportunidades laborales.