Feature Flags vs Test A/B: la Diferencia Real
Feature flags vs test A/B: qué resuelve cada uno, cuándo usar solo uno, y cómo combinar rollout controlado con rigor estadístico real.
📚 Este artículo es parte de la guía Feature Flags: la Guía Completa.
Los feature flags y los tests A/B responden preguntas distintas, aunque se mencionen todo el tiempo como si fueran lo mismo. Un feature flag es un mecanismo de entrega: un interruptor en el código que decide, sin necesidad de un nuevo deploy, quién ve qué versión de una funcionalidad. Un test A/B es un método de medición: divide a un público en grupos comparables y usa estadística para decir si un cambio mejora genuinamente una métrica, o si la diferencia observada es solo azar. Confundir los dos es un error común y caro: los equipos activan una flag al 50% del tráfico, miran el panel de analítica a ojo, deciden que el número “se siente” más alto, y publican para todo el mundo sin haber corrido nunca un test de verdad.
Esta guía mantiene los dos conceptos separados: qué hace cada uno por su cuenta, cuándo usar solo una flag, cuándo usar solo un test, y cómo combinarlos, el patrón que LaunchDarkly, PostHog, Statsig y Optimizely describen en su propia documentación de producto, sin perder el rigor estadístico en el camino.
Feature flags y tests A/B, en una frase cada uno
Un feature flag (o feature toggle) es una condicional en el código que enciende o apaga un comportamiento en tiempo de ejecución, sin necesitar un nuevo deploy. Un artículo de referencia muy citado sobre el tema, publicado en el sitio de Martin Fowler, describe los feature toggles como “una técnica poderosa que permite a los equipos modificar el comportamiento del sistema sin cambiar código”. Una flag responde: ¿quién ve qué, ahora mismo?
Un test A/B es un experimento controlado: divide el tráfico aleatoriamente entre una versión de control y una o más variaciones, mide una métrica primaria en cada lado, y aplica una prueba estadística (un valor p, un intervalo de confianza, o una probabilidad bayesiana) para decidir si la diferencia es real. Un test responde: ¿este cambio realmente funciona, o fue coincidencia?
| Feature flag | Test A/B | |
|---|---|---|
| Pregunta que responde | ¿Quién ve qué, ahora mismo? | ¿Este cambio realmente funciona? |
| Naturaleza | Mecanismo de entrega (deploy/release) | Método de medición (estadística) |
| Se decide por | Regla de negocio, riesgo, permiso | Significancia estadística o probabilidad bayesiana |
| ¿Necesita muestra calculada? | No | Sí |
| ¿Puede existir sin el otro? | Sí (rollout, kill switch, permisos) | Sí, aunque normalmente se entrega mediante alguna forma de división de tráfico |
La diferencia central: controlar exposición vs medir efecto
La forma más directa de retener la distinción: una flag controla exposición, un test A/B mide efecto. Una flag puede exponer una funcionalidad al 5%, al 50% o al 100% de los usuarios sin que eso, por sí solo, diga nada sobre si esa funcionalidad es buena. Un test A/B puede medir el efecto de un cambio incluso sin ninguna infraestructura de flag involucrada, el clásico test A/B de marketing cambia elementos directo en una página sin ninguna capa de flag por debajo. Son dos ejes distintos, y un proyecto puede necesitar uno, el otro, o los dos a la vez.
Decidir cuál de los dos necesita realmente un cambio, antes de escribir cualquier código, vale la pena hacerlo como un primer paso deliberado en vez de una idea de último momento. El diagrama de flujo de abajo recorre las dos preguntas que importan: si el cambio carga riesgo técnico real, y si su efecto sobre una métrica es genuinamente incierto.
Cuándo usar solo un feature flag
Usa un feature flag sin ningún test A/B detrás cuando la pregunta es sobre riesgo de entrega, no sobre efecto en una métrica. El propio glosario de Optimizely sobre feature flags nombra los mismos tres casos recurrentes:
- Rollout progresivo (canary release). Libera la funcionalidad al 1%, luego al 10%, luego al 50% de los usuarios, observando errores y performance en cada etapa antes de avanzar. La pregunta aquí es “¿esto rompe algo?”, no “¿esto convierte más?”
- Kill switch. Un interruptor que apaga una funcionalidad al instante si algo sale mal en producción, sin necesitar un rollback de deploy. Optimizely describe esto como una capa final de seguridad: si una funcionalidad se comporta mal, apagas la llave y vuelves a la versión estable de inmediato, sin esperar un nuevo build.
- Permisos. Controlar quién tiene acceso a una funcionalidad por plan, región o segmento, una funcionalidad exclusiva para enterprise, una beta cerrada para un grupo específico de clientes. Este tipo de flag tiende a vivir mucho tiempo, a diferencia de las flags de rollout, que deberían retirarse tan pronto la funcionalidad se estabiliza.
Ninguno de estos tres casos necesita un tamaño de muestra calculado, significancia, ni un grupo de control. La decisión es binaria y operacional: “¿esto es seguro?” o “¿esta persona puede verlo?”, no “¿este cambio mueve la métrica?”
Cuándo usar solo un test A/B
En la dirección opuesta, usa un test A/B sin apoyarte en infraestructura de feature flag cuando la pregunta es sobre efecto en una métrica que importa, y el riesgo técnico del cambio en sí es bajo. El caso clásico es el test de marketing y CRO: un titular, el texto de un botón, el layout de un formulario, un precio mostrado. Ninguno de estos cambios amenaza la estabilidad del sistema; el único riesgo es de conversión, y eso es exactamente lo que el test mide.
La señal de que necesitas rigor estadístico real, no solo una flag, es esta: la decisión sale cara si te equivocas (precio, checkout, onboarding), la diferencia esperada es lo bastante pequeña como para confundirse con ruido, o vas a tener que defender la decisión con números más adelante. En esos casos, saltar directo a “lo pusimos en 50% y el gráfico se ve mejor” es exactamente el error que PostHog señala en su propia documentación: sin un experimento real, no controlaste la significancia estadística, y la diferencia que parecía real podría ser solo ruido.
Si estás montando este tipo de test desde cero, vale la pena calcular la muestra antes de lanzarlo: mira la guía paso a paso para correr un test A/B para el proceso completo y la calculadora de tamaño de muestra.
Cuándo necesitas ambos
El patrón más maduro, y el que LaunchDarkly, PostHog y Statsig describen en su propia documentación de producto, es usar la flag como mecanismo de entrega y colocar el test A/B como capa de experimentación por encima. La flag controla quién recibe qué variante; el test A/B, atado a esa misma división, mide si la variante gana. En la práctica de producto, esto suele seguir los mismos patamares de un rollout progresivo, con un paso formal de medición agregado en el medio antes de avanzar al 100%:
Este es exactamente el modelo que Statsig documenta para combinar feature gates y experimentos: los gates son buenos pre-filtros para dirigirse al público correcto, y luego los experimentos cuantifican el lift entre métricas para ese público, con la asignación topada en 50/50 para que la comparación se mantenga justa. LaunchDarkly describe el mismo patrón en su propia documentación de experimentación: conectas una flag a las métricas que importan para ella, y LaunchDarkly muestra intervalos de confianza que indican cuánta evidencia respalda cada variación, lo que es justamente lo que después justifica ampliar el rollout al resto de la base.
Ejemplo práctico: e-commerce y SaaS
E-commerce. Una tienda quiere reemplazar su checkout de tres pasos por una versión de una sola página. El riesgo técnico es real, un checkout roto es ingreso perdido al instante, así que el cambio se publica detrás de un feature flag, liberado primero al 5% del tráfico solo para confirmar que nada se rompe. Una vez confirmado que es estable, la misma flag empieza a alimentar un test A/B real: 50% de los visitantes ven el checkout nuevo, 50% ve el antiguo, con asignación estable por visitante y la tasa de finalización de compra como métrica primaria. Solo cuando el test declara significancia, la flag avanza al 100%.
SaaS. Un equipo de producto quiere probar un flujo de onboarding nuevo que pide menos información al registrarse. El riesgo técnico es bajo, no toca facturación ni datos sensibles, pero el efecto en la métrica que importa (activación a 7 días) es genuinamente incierto y podría ir para cualquier lado. Aquí la flag existe sobre todo por conveniencia de despliegue, ingeniería puede fusionar código incompleto en la rama principal sin afectar producción, más que por miedo a romper algo; es el test A/B, dimensionado por adelantado a partir del volumen semanal de nuevos registros, el que decide si el onboarding nuevo se queda.
Leyendo el resultado con rigor, aunque venga de una flag
Una vez que una flag entrega ambas versiones y el test corre en una etapa estable (el punto del 50% en el ejemplo del checkout de arriba), la lectura estadística es la misma que para cualquier test A/B: compara visitantes y conversiones en cada lado. Reutilizando un ejemplo ya validado en el motor estadístico de este blog, con el control registrando 210 conversiones sobre 4.200 visitantes y la variación registrando 273 sobre 4.200:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Corriendo esos números en la calculadora de arriba, la tasa del control es 5,0%, la de la variación es 6,5%, el valor p bilateral queda cerca de 0,003, y el intervalo de confianza de la diferencia no cruza el cero. Dicho de otra forma: aunque estos datos vinieron de una flag sentada en 50% de rollout, la diferencia es estadísticamente significativa, no ruido, y solo en ese punto tiene sentido avanzar la flag al 100%. Para el desarrollo completo de esa matemática, mira cómo declarar significancia estadística sin engañarte.
Un detalle que vale la pena reforzar: los datos recolectados mientras el porcentaje del rollout todavía estaba cambiando (de 1% a 10%, de 10% a 50%) no deberían entrar en ese cálculo. Cada cambio de etapa puede alterar quién está siendo expuesto, los equipos que corren rollouts progresivos suelen variar el criterio de segmentación en cada fase, y mezclar cohortes distintas en el mismo análisis estadístico es una forma silenciosa de contaminar el resultado. Trata cada meseta estable como su propia ventana de recolección.
Feature flags vs test A/B, lado a lado
| Criterio | Feature flag | Test A/B |
|---|---|---|
| Objetivo | Controlar riesgo de release | Medir efecto sobre una métrica |
| Unidad de decisión | Regla de negocio (plan, región, % de rollout) | Estadística (valor p, IC, o probabilidad bayesiana) |
| Vida útil típica | Corta para rollout (días a semanas); larga para permisos | Duración fija, calculada a partir de muestra y tráfico |
| Quién decide | Ingeniería/producto, por criterio de riesgo | El resultado estadístico, definido antes de empezar el test |
| Herramientas de referencia | LaunchDarkly, Split/Harness, Flagsmith, Unleash, Statsig | Donnu A/B, VWO, Optimizely, GrowthBook |
| Error común si se usa sola | Asumir que “está en producción” significa “está comprobado que funciona” | Correr un cambio técnico de alto riesgo sin ninguna red de seguridad detrás |
Errores comunes al mezclar los dos
- Declarar un ganador observando el rollout, sin test. La flag llega al 50%, el número en el panel “se ve” mejor, y el equipo avanza al 100% sin haber calculado nunca significancia. Este es precisamente el patrón que PostHog señala como el error más costoso: la diferencia observada puede ser enteramente ruido.
- Mezclar datos de distintas etapas del rollout en el mismo análisis. Combinar la semana en que el rollout estaba en 10% con la semana en que estaba en 50% distorsiona la comparación, porque el público expuesto cambia en cada límite de etapa.
- Dejar la flag viva después de que el test terminó. Las flags de rollout y de experimento son transitorias por naturaleza. El artículo de referencia de Martin Fowler señala exactamente este riesgo: los toggles olvidados acumulan deuda técnica y hacen que el código sea cada vez más difícil de entender. Una vez que el test decide, gana, pierde o se descarta, la flag debería eliminarse, no dejarse “por si acaso”.
- Correr un cambio técnico de alto riesgo como test A/B sin ninguna flag detrás. Probar una reescritura grande de checkout directamente, sin un kill switch disponible, te quita la capacidad de revertir al instante si algo se rompe en producción.
Hazlo automático en Donnu
Combinar rollout controlado con una lectura estadística honesta es trabajo manual cuando cada pieza vive en una herramienta distinta, y el modo de falla más común es exactamente el que recorre esta guía: un equipo publica más allá del 50% porque el panel “se veía” mejor, sin haber calculado nunca si esa diferencia era real. Donnu A/B se encarga de la mitad de medición de esa combinación: defines la hipótesis y la división de tráfico, el snippet liviano nunca bloquea la página de tu producto, y el motor de estadística bayesiana declara un ganador con el mismo rigor descrito en esta guía, no un vistazo al panel con una flag sentada en 50%.
Comienza una prueba gratis de 14 días y mide tu próximo cambio con estadística real, no solo con una flag al 50%. Para la base estadística detrás de cualquier test, lee la guía completa de test A/B; para decidir dónde debería ocurrir técnicamente la división de tráfico, mira test A/B client-side vs server-side.
Lee también: Feature flags: la guía completa · ¿Qué es un test A/B? La guía completa · Test A/B client-side vs server-side
Referencias
- Fowler, M. (con Hodgson, P.). Feature Toggles (aka Feature Flags). martinfowler.com/articles/feature-toggles.html.
- Statsig. When to Use Feature Gates vs. Experiments. docs.statsig.com/guides/featureflags-or-experiments.
- Optimizely. Feature Flags. optimizely.com/optimization-glossary/feature-flags.
- PostHog. What is a Feature Flag? Feature Flags vs Remote Config vs A/B Testing. posthog.com/blog/what-is-a-feature-flag.
- LaunchDarkly. Experimentation. launchdarkly.com/docs/home/experimentation.
Preguntas frecuentes
- ¿Feature flags y tests A/B son la misma cosa?
- No. Un feature flag es un mecanismo de entrega: un interruptor en el código que decide quién ve qué versión, sin necesidad de un nuevo deploy. Un test A/B es un método de medición: divide aleatoriamente a un público en grupos comparables y usa estadística para decir si un cambio realmente mueve una métrica, o si la diferencia es solo ruido. Uno controla exposición, el otro mide efecto. Statsig marca esta distinción con claridad en su propia documentación: un feature gate es binario (pasa o no pasa) y su división de tráfico puede llegar hasta 99% contra 1%, mientras que un experimento compara múltiples variantes y su asignación queda topada en 50/50 para que la comparación siga siendo estadísticamente justa.
- ¿Puedo usar un feature flag para decidir si un cambio funcionó?
- No solo mirando un panel a ojo mientras una flag expone el 50% del tráfico. Ese enfoque no controla la contaminación entre grupos, no fija una muestra por adelantado, y no calcula un intervalo de confianza ni un valor p, así que cualquier diferencia que notes puede ser aleatoria. PostHog traza exactamente esta línea en su documentación: los feature flags controlan releases, y solo un test A/B real, con asignación aleatoria y cálculo de significancia, mide qué funciona. Si la decisión tiene un costo real, conecta la flag a un experimento de verdad corriendo por detrás.
- ¿Cómo leo los resultados de un rollout por etapas que pasó por varios porcentajes (1%, 10%, 50%)?
- Solo es válido para una lectura estadística el período en que la división de tráfico se mantuvo estable, aleatoria, y ligada a una unidad de asignación fija (el mismo usuario siempre cae en el mismo grupo). Los datos recolectados mientras el porcentaje del rollout estaba cambiando activamente, de 1% a 10% por ejemplo, tienden a mezclar cohortes distintas y distorsionar la comparación, porque el público expuesto en cada etapa rara vez es idéntico. Trata cada meseta estable del rollout como su propia ventana de medición, y solo calcula significancia dentro de esa ventana.
- ¿Un feature flag sustituye la necesidad de una herramienta de test A/B?
- No. La flag responde "cómo entrego esto con seguridad": rollout gradual, kill switch, permisos. El test A/B responde "esto realmente funciona": asignación aleatoria, una muestra calculada, un valor p o una probabilidad bayesiana. Las plataformas maduras de feature flag difuminan esta línea a nivel operativo (LaunchDarkly y Statsig permiten conectar un experimento directo a una flag y leer métricas contra ella), pero por debajo siguen siendo dos capas separadas con dos trabajos separados, no una sustituyendo a la otra.
- ¿Cuándo no necesito ni feature flag ni test A/B?
- Cuando el cambio es una corrección de bug obvia, un arreglo sin ambigüedad, o algo demasiado pequeño para cargar riesgo real: un error de tipeo, un enlace roto, un ajuste de texto que nadie va a discutir. Envolver una corrección de una línea en una flag y un experimento controlado es sobreingeniería, simplemente publícalo. Los feature flags y los tests A/B existen para los casos con riesgo técnico genuino (el trabajo de la flag) o incertidumbre genuina sobre el efecto (el trabajo del test), no para cada cambio que va a producción.