Jorge Saavedraexperimentacionfeature-flagsa-b-testingstatsigbuenas-practicaskotlin
Imagina esto: es viernes por la tarde, hiciste deploy de una nueva feature que llevabas semanas desarrollando. Todo se ve bien, los tests pasan, el deploy fue limpio. Te vas tranquilo a descansar. El lunes llegas y tu PM te dice que las conversiones cayeron un 15% durante el fin de semana. Tu primera reacción es revisar los logs, pero no hay errores. No hay excepciones. No hay nada roto. Simplemente... algo cambió y los usuarios dejaron de convertir.
deploy
Proceso de publicar una nueva versión del software en un servidor de producción.
conversiones
Porcentaje de usuarios que completan una acción deseada, como registrarse, comprar o suscribirse.
La pregunta obvia es: fue tu cambio el que causó la caída? O fue una coincidencia? Quizás hubo un feriado, quizás la competencia lanzó una promoción, quizás simplemente fue un fin de semana raro. Sin datos concretos, lo único que tienes son teorías. Y las teorías no convencen a nadie en una reunión de post-mortem.
post-mortem
Reunión de análisis que se realiza después de un incidente para entender qué pasó y cómo prevenirlo.
Ahora imagina el mismo escenario, pero con una diferencia: en vez de hacer deploy al 100% de los usuarios, activaste tu feature solo para el 10%. Tienes un grupo de control que no vio el cambio y un grupo de tratamiento que sí lo vio. Puedes comparar las métricas lado a lado y en cinco minutos sabes si tu cambio fue el responsable. Eso es experimentación.
En este post te voy a explicar qué es la experimentación en software, por qué debería importarte aunque no trabajes en una empresa gigante, y cómo empezar a usarla en tu día a día con herramientas que tienen tier gratuito.
Qué es la experimentación en software?
En términos simples, experimentación en software significa exponer un cambio a un subconjunto de usuarios, medir el impacto con datos reales, y tomar decisiones informadas basadas en esos datos. No es intuición, no es "yo creo que esto va a funcionar", no es "el jefe dijo que le gusta más el botón azul". Es evidencia.
La diferencia con el enfoque tradicional de "deploy y a ver que pasa" es enorme. Cuando haces deploy al 100% sin experimentación, estás apostando. Si sale bien, perfecto. Si sale mal, afectaste a todos tus usuarios y probablemente tardas horas o días en darte cuenta. Con experimentación, el riesgo está contenido: si algo sale mal, solo un porcentaje pequeño de usuarios se ve afectado, y puedes revertir en segundos.
Piensa en la experimentación como el método científico aplicado a tu software. Tienes una hipótesis ("este nuevo flujo de checkout va a aumentar las conversiones"), diseñas un experimento (A/B test con el 50% del tráfico), recoges datos, y sacas conclusiones. Así de simple, así de poderoso.
checkout
Proceso de compra en el que el usuario completa su pedido y realiza el pago.
Los pilares de la experimentación
Feature Flags
Un feature flag (o feature toggle) es básicamente un interruptor remoto que te permite activar o desactivar una funcionalidad sin necesidad de hacer un nuevo deploy. Imagina que tienes un interruptor de luz en tu oficina, pero en vez de controlar una lámpara, controla si los usuarios ven o no una feature de tu aplicación. Y lo mejor: puedes encenderlo y apagarlo desde un dashboard, sin tocar una sola línea de código en producción.
Desde el punto de vista de ingeniería, los feature flags son increíblemente útiles en situaciones críticas. Por ejemplo, imagina que tu aplicación depende de un proveedor externo de pagos. Si ese proveedor empieza a fallar, puedes tener un feature flag que actúe como kill switch: desactivas la integración y rediriges a los usuarios a un flujo alternativo, todo sin hacer deploy. Otro caso clásico es una migración de base de datos: en vez de migrar todo de golpe, usas un flag para que un porcentaje de las lecturas vayan a la nueva base de datos mientras validas que todo funcione correctamente.
kill switch
Mecanismo de emergencia para desactivar una funcionalidad o integración de forma instantánea.
La clave de los feature flags es que desacoplan el deploy del release. Puedes subir código a producción que está "dormido" detrás de un flag, y activarlo cuando estés listo. Esto te da una flexibilidad enorme y reduce drásticamente el riesgo de cada deploy.
A/B Testing
El A/B testing es probablemente la forma más conocida de experimentación. La idea es simple: divides tu tráfico en dos (o más) grupos. Un grupo ve la versión A (el control, lo que ya tienes) y otro grupo ve la versión B (la variante, tu cambio nuevo). Después de un tiempo, comparas las métricas de ambos grupos y ves cuál gana. No con opiniones, sino con datos estadísticamente significativos.
Un ejemplo clásico de producto: tu equipo quiere rediseñar el flujo de checkout. En vez de lanzar el nuevo diseño a todo el mundo y cruzar los dedos, creas un A/B test. El 50% de los usuarios ve el checkout original (grupo control) y el otro 50% ve el nuevo diseño (grupo variante). Después de una o dos semanas, comparas la tasa de conversión de ambos grupos. Si la variante convierte un 8% más con significancia estadística, tienes evidencia sólida para hacer el cambio permanente. Si no, evitaste un error costoso.
significancia estadística
Nivel de confianza matemática que indica que un resultado no ocurrió por azar, generalmente con p menor a 0.05.
Lo importante aquí es entender los dos conceptos fundamentales: el grupo control es tu línea base, lo que ya existe y funciona. La variante es el cambio que quieres probar. Sin un grupo control, no tienes contra qué comparar y cualquier conclusión que saques es básicamente una adivinanza.
Rollouts progresivos
Un rollout progresivo es exactamente lo que suena: en vez de lanzar una feature al 100% de los usuarios de golpe, la vas liberando gradualmente. Primero al 5% del tráfico, luego al 25%, después al 50%, y finalmente al 100%. En cada etapa, verificas que las métricas clave (latencia, tasa de errores, conversiones) se mantengan estables. Si en alguna etapa algo se ve mal, haces rollback y solo afectaste a un porcentaje pequeño de usuarios.
latencia
Tiempo que tarda un sistema en responder a una solicitud, medido generalmente en milisegundos.
rollback
Acción de revertir un sistema a su estado anterior, deshaciendo los cambios más recientes.
Desde el lado de ingeniería, los rollouts progresivos son esenciales para deploys de alto riesgo. Imagina que estás migrando un microservicio crítico: el servicio de autenticación. Hacer el switch de golpe sería una locura. En cambio, con un rollout progresivo envías primero el 5% del tráfico al nuevo servicio. Si la latencia se mantiene y no hay errores, subes al 25%. Y así sucesivamente hasta llegar al 100%. Si en cualquier momento algo falla, vuelves atrás en segundos.
La belleza de este enfoque es que combina lo mejor de ambos mundos: te permite lanzar features nuevas con confianza, sin el riesgo de afectar a toda tu base de usuarios. Es como probar el agua con el pie antes de tirarte a la piscina.
Casos de uso reales
Cuando la gente piensa en experimentación, muchas veces se imagina solo cambios de colores de botones o textos de marketing. La realidad es que la experimentación se usa tanto en producto como en ingeniería, y los casos de uso son mucho más amplios de lo que te imaginas.
Del lado de producto, los casos clásicos incluyen probar diferentes flujos de onboarding para ver cuál retiene más usuarios, experimentar con distintos textos y posiciones de CTAs (call to action) para optimizar conversiones, y testear diferentes estructuras de precios para maximizar el revenue. Cada una de estas decisiones puede tener un impacto enorme en el negocio, y tomar la decisión equivocada basándote en intuición puede costarte miles de dólares.
Del lado de ingeniería, los feature flags ya los discutimos, pero hay más. Los canary deployments son una variante de los rollouts progresivos donde envías tráfico a una sola instancia nueva antes de hacer deploy completo. Los kill switches te permiten desactivar integraciones con proveedores externos que están fallando. Y las migraciones graduales de bases de datos o servicios se vuelven mucho más seguras cuando puedes controlar el porcentaje de tráfico que va a cada versión.
Cómo se ve esto en la práctica? Statsig
Ahora que entiendes los conceptos, veamos cómo se implementa en la vida real. Statsig es una plataforma de experimentación que ofrece feature gates (su nombre para feature flags), experimentos A/B, y métricas automáticas. Lo que la hace particularmente atractiva es que tiene un tier gratuito bastante generoso que te permite empezar a experimentar sin gastar un centavo.
Statsig funciona así: tu aplicación se conecta al SDK de Statsig, que evalúa en tiempo real si un usuario debe ver una feature o no, basándose en las reglas que configuras en su dashboard. Además, recopila métricas automáticamente, así que no tienes que instrumentar todo manualmente. Puedes definir tus propios eventos y Statsig se encarga de calcular significancia estadística y mostrarte los resultados.
Hay otras plataformas como LaunchDarkly, Split, o Unleash, pero Statsig destaca por su combinación de feature flags + experimentación + métricas en una sola herramienta, y porque su tier gratuito es lo suficientemente amplio para equipos pequeños y medianos.
En el dashboard de Statsig puedes ver tus feature gates activos, el porcentaje de usuarios que los ven, los experimentos en curso con sus métricas en tiempo real, y el estado de cada uno (en progreso, ganador, perdedor). Es una vista centralizada de toda tu experimentación.
Veamos cómo se ve en código. Primero, un ejemplo de cómo evaluar un feature gate en Kotlin:
kotlin
// Evaluar un feature gate
val user = StatsigUser(userID = "user-123")
Statsig.initializeAsync("server-secret-key").await()
if (Statsig.checkGate(user, "new_checkout_flow")) {
// Mostrar el nuevo flujo de checkout
showNewCheckout()
} else {
// Mostrar el flujo original
showOriginalCheckout()
}Este código es lo único que necesitas en tu aplicación. La lógica de quién ve la feature y quién no se configura completamente en el dashboard de Statsig. Si mañana quieres cambiar el porcentaje de usuarios que ven el nuevo checkout, lo haces desde el dashboard sin tocar código ni hacer deploy.
Ahora veamos cómo obtener valores dinámicos de un experimento:
kotlin
// Obtener valores de un experimento
val experiment = Statsig.getExperiment(user, "checkout_redesign")
val buttonColor = experiment.getString("button_color", "blue")
val headerText = experiment.getString("header_text", "Completa tu compra")
// Usar los valores del experimento
renderCheckout(buttonColor, headerText)Aquí la magia está en que los valores (
button_color, header_text) se definen en el dashboard de Statsig como parte del experimento. Cada variante del experimento puede tener valores diferentes, y el SDK se encarga de asignar al usuario la variante correcta y devolver los valores correspondientes. Tu código simplemente los consume, sin saber en qué grupo está el usuario.Por qué no solo usar un if en tu código?
Seguramente estás pensando: "pero yo puedo hacer lo mismo con un simple
if y una variable de entorno". Y técnicamente tienes razón. Puedes meter un if (ENABLE_NEW_CHECKOUT) en tu código y listo. Pero esa solución que parece simple se convierte rápidamente en un problema a escala.Estas son las razones por las que un
if hardcodeado no escala:- Requiere un re-deploy para cambiar: si quieres activar o desactivar la feature, necesitas cambiar código, hacer PR, pasar CI, y hacer deploy. Eso puede tardar horas.
- No tiene métricas automáticas: un if no te dice cuántos usuarios vieron la feature ni qué impacto tuvo. Tendrías que instrumentar todo manualmente.
- No permite segmentación: no puedes decir "activar solo para usuarios de Chile" o "solo para usuarios premium" sin escribir lógica adicional cada vez.
- No tiene audit trail: nadie sabe quién activó o desactivó el flag, cuándo lo hizo, ni por qué. En una plataforma, todo queda registrado.
- Se convierte en deuda técnica: los ifs se esparcen por todo el código. Después de unos meses nadie sabe cuáles flags siguen activos, cuáles se pueden borrar, y terminas con un código lleno de caminos muertos.
Una plataforma de experimentación resuelve todo esto de forma centralizada. Tienes un dashboard donde ves todos tus flags y experimentos, puedes cambiar configuraciones en tiempo real sin deploy, las métricas se recopilan automáticamente, y hay un historial completo de cada cambio. Es la diferencia entre manejar con un mapa de papel y usar GPS.
La experimentación no es un lujo
No necesitas ser Google o Netflix para experimentar. Herramientas como Statsig tienen un tier gratuito bastante generoso. El verdadero costo no es la herramienta, es NO experimentar: tomar decisiones basadas en suposiciones en vez de datos. Cada feature que lanzas sin medir es una oportunidad perdida de aprender algo sobre tus usuarios.
En resumen
La experimentación no es un lujo reservado para las big tech con equipos de data science de 50 personas. Es una práctica que cualquier equipo puede adoptar, y herramientas como Statsig con su tier gratuito lo hacen accesible para startups, equipos pequeños, y proyectos personales. Lo que antes requería infraestructura propia y meses de desarrollo, hoy lo configuras en una tarde.
El cambio mental más importante que puedes hacer es pasar de "yo creo que esto va a funcionar" a "los datos dicen que esto funciona". Ese cambio de mentalidad transforma la forma en que tu equipo toma decisiones. Ya no son discusiones de opinión donde gana el que tiene el cargo más alto. Son decisiones basadas en evidencia, donde gana la mejor idea sin importar de donde venga.
Mi consejo: no intentes implementar experimentación en todo tu producto de un día para otro. Empieza con algo pequeño. La próxima vez que tu equipo tenga que decidir entre dos opciones de diseño, en vez de debatir durante una hora, crea un A/B test y deja que los usuarios decidan. Te vas a sorprender de lo seguido que la opcion "obvia" resulta no ser la ganadora. Y esa primera sorpresa es lo que te va a convencer de que experimentar vale la pena.
