¿Alguna vez te encontraste en la situación de realizar un cambio en tu sistema sin saber si iba a gustarle a los usuarios? Este es uno de los motivos por el cual A/B testing se ha convertido en una práctica popular para optimizar productos digitales.
Nuestro equipo eligió implementarlo usando Split, una plataforma que brinda distintas herramientas para hacer el proceso más sencillo. Esto nos permitió simplificar la gestión de nuestro código mientras mientras mejoramos la experiencia de usuario
En este blog vamos a hablar sobre A/B testing y nuestra experiencia implementando con Split junto con algunas cosas a tener en cuenta a la hora de implementarlo.
¿Qué es el A/B testing?
Antes de profundizar, empecemos por lo básico: ¿qué es el A/B testing?
Empecemos por el principio. A/B testing es una técnica que se usa para comparar dos versiones de un elemento con el objetivo de determinar cual produce mejores resultados a partir de una o más métricas seleccionadas. Imaginemos un escenario en el que tenemos una página con un botón rojo (Version A), y nuestro equipo quiere probar cómo cambiando el color a azul (Versión B) impacta en los usuarios. Para esto, separamos a los usuarios en dos grupos, un grupo ve la Versión A, mientras que el otro ve la Versión B. A partir de ahí se evalúa cual de las versiones tiene un mejor rendimiento a partir de la métrica definida y el resultado de la misma para ambos grupos, en este ejemplo se podría usar “porcentaje de click por vista”
Cuando un número razonable de usuarios participaron del experimento, el mismo se da por finalizado y el botón con el mayor relación “click por vista” es declarado el ganador y queda en la página
Diferencial de Split: Usualmente necesitamos probar más de dos versiones al mismo tiempo. Digamos que queremos chequear cuál de todas las opciones dentro de una lista afecta de mejor forma a nuestras métricas si la ponemos como default. Si tuviésemos que comparar una a una el proceso podría ser eterno. Por eso herramientas que te permiten comparar más de dos a la vez, como Split, aceleran los experimentos y en consecuencia permiten obtener resultados mucho más rápido.
Beneficios que van más allá de los resultados inmediatos
Aunque las pruebas A/B son conocidas por permitir tomar decisiones basadas en datos, tienen aún más ventajas que pueden no ser visibles a primera vista.
Despliegue seguro de funcionalidades incompletas
Gracias a los feature flags, podes desplegar cambios en producción y mantenerlos ocultos para los usuarios mientras los pruebas con un grupo controlado. Esto evita los usuales “no podemos desplegar esto porque no está listo” o el “necesita pasar por QA primero” y nos permiten continuar con otros releases sin esperar a que un feature este 100% listo, reduciendo así los riesgos, acelerando los ciclos de desarrollo y eliminando el estrés de los lanzamientos de última hora o de un día para otro.
Si estás desarrollando una nueva UI, cambiando la arquitectura del backend o implementando mejoras críticas, puedes activarlas solo para un grupo reducido de usuarios o incluso solo para tu equipo interno. De esta forma, puedes identificar y resolver bugs potenciales antes de que afecten a toda tu base de clientes, permitiendo trabajar en ellos sin retrasar el lanzamiento de otras funcionalidades.
Reversión inmediata en caso de fallos
Si se encuentra un error o se decide que un experimento no fue exitoso, otro gran beneficio de la herramienta es que nos permite hacer rollback inmediato sin requerir un nuevo despliegue.
Desplegar con un feature flag no es solo útil para trackear métricas, también mejora la seguridad y confianza en el sistema. Si un feature falla o el experimento no produce los resultados esperados, revertirlo es tan simple e inmediato como apagar el flag.
Gestión eficiente con Split: nos resultó más que útil generar un proceso desarrollo alineado con estos conceptos. Teníamos en cuenta cada versión del feature a medida que desarrollamos, desplegabamos el nuevo código con el flag habilitado solo para nuestro equipo, lo probamos internamente y si todo estaba bien, habilitamos esta nueva versión para que los clientes puedan usarla. A pesar de todo este proceso, hubieron varias veces que se descubrieron muchos bugs gracias a las interacciones de usuarios reales, pero resolverlas no requirió más que simplemente apagar el flag y resolver el bug al dia siguiente
El lado oscuro del A/B testing: complejidad en el código
No todo es tan perfecto. Estos beneficios también vienen con complejidad técnica, especialmente cuando se implementa a gran escala.
Durante mi experiencia trabajando en PODS, ****una plataforma donde los usuarios configuran su alquiler y transporte de containers paso a paso, lanzamos múltiples experimentos para probar como reordenando pasos, removiendo opciones o agregando nuevas, impactaba en las ventas.
Parecía simple, agregar algunos flags para mostrar diferentes versiones y analizar los resultados.
. A/B testing es una gran herramienta, pero puede complicar el código cuando se implementa a gran escala. Pero con el tiempo se volvió incontrolable. Cada cambio introducía nuevas posibles combinaciones y lo que comenzó como un plan para optimizar la experiencia de usuario se volvió un producto con un laberinto de versiones inmanejable.
Feature flags descontrolados: una receta para el caos
Uno de los principales code smells es la presencia de demasiados feature flags afectando el mismo flujo del sistema.
En nuestro caso, había flags para:
- Modificar el orden de los pasos.
- Cambiar el diseño de algunas pantallas.
- Agregar o quitar preguntas opcionales.
Cada flag afectaba la experiencia del usuario de manera diferente, lo que significaba que había varios posibles caminos dentro del mismo flujo. Lo que derivó en pruebas exhaustivas antes de cada despliegue, ya que cada cambio podía interferir en otro experimento. Quizás se puede argumentar que la estrategia de testing automatizado no fue la adecuada pero las pruebas automatizadas no fueron suficientes.
Con Split, podíamos visualizar mejor qué experimentos estaban activos para remover aquellos cuyo análisis ya había finalizado, pero siendo el proceso de limpieza más lento que el de agregar nuevos experimentos nos llevó a una cantidad excesiva de combinaciones. Como resultado, el equipo terminó utilizando más tiempo arreglando bugs y haciendo smoke testing para cada una de las variantes, que realmente analizando resultados y construyendo nueva funcionalidad.
¿Cómo identificar el exceso de experimentos?
La forma más sencilla de evitar este caos es usar feature flags solo cuando realmente aportan valor. ¿Pero cuándo son realmente necesarios? ¿Cuándo es simplemente mejor implementar un cambio en vez de realizar un experimento?
Algunas de las señales que considero importantes a tener en cuenta podrían ser:
Demasiados flags en el mismo flujo → Si cada paso de un proceso tiene múltiples versiones activas, la complejidad crece exponencialmente.
Experimentos que nunca terminan → Si una prueba lleva meses sin conclusiones claras, probablemente sea mejor tomar una decisión y avanzar.
En el caso de Pods, la solución fue simplificar los experimentos:
- Reducir la cantidad de flags activos simultáneamente.
- Eliminar pruebas que no generaban impacto en la conversión.
- Implementar una política de "limpieza de experimentos" para evitar que flags
El resultado fue un flujo de trabajo más ágil, menos errores en producción y una estrategia de experimentación más efectiva.
Split como aliado: Split facilitó este proceso al ofrecer una gestión centralizada de los experimentos. Nos permitió visualizar qué pruebas están activas, y de esta forma eliminarlas cuando ya no aportaban valor, evitando que el código se llene de flags innecesarios.
Conclusión
A/B testing es una manera efectiva de guiar tus decisiones a partir de los datos y así mejorar tus productos. Sin embargo, estas implementaciones se pueden volver complejas y difíciles de mantener. Si los experimentos se acumulan sin control, el código comienza a ser difícil de mantener, el tiempo de desarrollo se incrementa, y los beneficios esperados desaparecen
Los features flags son una gran herramienta, pero es fundamental usarlos de manera estratégica porque más experimentos no siempre significan mejores resultados. Es crucial entender cuándo es mejor realizar una prueba y cuando simplemente hacer un cambio. Balancear el experimentar con la simpleza es la clave para sacar mayor provecho al A/B testing sin caer en el caos.
Back to Explore Focused Lab