Cómo diseñar un A/B test que no te mienta: significancia, potencia y MDE

Estudios académicos y data de plataformas como Optimizely y VWO muestran que entre el 40% y el 60% de los A/B tests declarados como ganadores nunca se replican en producción. Es decir: el equipo declaró un ganador, lo implementó, y la conversión no mejoró.

Las razones son siempre las mismas: tests subdimensionados (muestra muy chica), tests detenidos cuando "se ve un ganador", tests con MDE poco realista, tests con segmentos mezclados, y tests donde la métrica primaria no se definió antes.

Esta guía cubre los 5 conceptos críticos para que un A/B test sea válido:

1. Significancia estadística: ¿el resultado es atribuible al cambio o pudo ser azar? 2. Potencia estadística: ¿el test tiene suficiente sensibilidad para detectar un efecto real? 3. MDE (Minimum Detectable Effect): ¿qué tamaño de efecto puedes detectar con tu tráfico? 4. Tamaño de muestra: ¿cuántos visitantes necesitas por variante? 5. Duración mínima: ¿cuánto tiempo debe correr antes de declarar ganador?

No es teoría académica. Si no respetas los 5, tu test es ruido caro disfrazado de data. Decisiones de producto y marketing basadas en tests inválidos producen rediseños que no mueven la aguja y consumen meses de equipo.

Definición operativa: la significancia estadística (p-value) responde "¿qué probabilidad hay de que la diferencia observada entre A y B sea por azar?". Un p-value de 0.05 significa 5% de probabilidad de que la diferencia sea casual.

El umbral estándar de la industria es 95% de confianza (p < 0.05). No es mágico, es convención. Significa que aceptamos correr el riesgo de 5% de falso positivo.

Qué significa "95% significativo" en la práctica:

• Si corres 20 tests donde realmente no hay diferencia entre A y B, 1 de ellos saldrá significativo solo por azar.
• Si tu equipo declara "ganador" cada vez que ve 95% significancia, el 5% de las veces se equivocará y rediseñará algo que no debía.

Por qué 95% es problemático en CRO real:

1. El equipo mira el test todos los días. Cada vez que mira, hay chance de pillar un "falso ganador". Si miras 10 días seguidos, la probabilidad acumulada de falso positivo es muy superior al 5% nominal.

2. Múltiples métricas se miden simultáneamente. Si miras conversión, revenue, AOV, signups, todos al mismo tiempo, aumentas la probabilidad de pillar algo significativo por azar.

3. Tests se detienen cuando hay "ganador visible". Esta práctica (peeking) invalida la estadística. El cálculo de p-value asume que el tamaño de muestra estaba definido antes.

Buenas prácticas:

• Definir métrica primaria antes del test, no después.
• Aumentar umbral a 99% si vas a hacer muchos tests pequeños.
• Usar correcciones para múltiples métricas (Bonferroni, Holm-Bonferroni) cuando aplique.
• No mirar el test hasta que haya corrido el tamaño de muestra calculado.

Regla operativa simple: si no tienes background estadístico, contrata herramienta que maneje esto (Optimizely, VWO, Convert, Statsig) y respeta sus tiempos. No declares ganador antes.

Definición operativa: la potencia estadística responde "si realmente hay una diferencia entre A y B, ¿qué probabilidad tengo de detectarla con este tamaño de muestra?". Estándar de industria: 80% (algunas usan 90%).

80% de potencia significa que si la versión B realmente es 10% mejor, el 80% de las veces el test lo detectará y declarará significativo. El 20% de las veces, B será mejor pero el test dirá "no hay diferencia" (falso negativo).

Por qué importa:

Sin potencia suficiente, un test que dice "no hay diferencia" no significa "A y B son iguales". Significa "este test no tuvo sensibilidad para detectar la diferencia". Son cosas distintas.

Ejemplo concreto: tienes 1.000 visitas/mes y haces un test con 500 a cada variante. La versión B en realidad mejora conversión de 3% a 3.5% (mejora relativa 16.7%). El test corre 1 mes. Resultado típico: no significativo. Conclusión equivocada: "no funciona". Conclusión correcta: "no tuviste muestra suficiente para detectar la mejora".

Cómo calcular el tamaño de muestra para tener 80% de potencia:

Necesitas saber: - Tu conversión actual (baseline). Ej: 3%. - MDE objetivo (qué tamaño de efecto quieres poder detectar). Ej: detectar mejora del 20% sobre baseline (de 3% a 3.6%). - Significancia deseada. Ej: 95% (alpha = 0.05). - Potencia deseada. Ej: 80% (beta = 0.20).

Fórmula simplificada o calculadoras online (Evan Miller's calculator es estándar). Con esos parámetros: necesitas ~5.000 visitas por variante, total 10.000. Si tu tráfico es 1.000/mes, este test necesita 10 meses para ser válido. No 1 mes.

Regla operativa: si tu tráfico es bajo, tienes 3 opciones: 1. Solo testear cambios grandes (MDE alto, requiere menos muestra). 2. Combinar variantes en un solo test multivariado bien diseñado. 3. Aceptar que no puedes hacer A/B testing serio con tu tráfico y usar heurísticas + best practices.

Definición: el MDE es el tamaño mínimo de mejora que tu test puede detectar dado tu tamaño de muestra. Es la palanca central del trade-off entre tiempo del test y sensibilidad.

Trade-off fundamental:

• MDE bajo (ej: detectar mejora del 5%) requiere muestra grande y test largo.
• MDE alto (ej: detectar mejora del 30%) requiere muestra chica y test rápido.

Para un test con baseline 3%, MDE 5%, 95% sig, 80% potencia: ~50.000 visitas por variante. Para mismo baseline, MDE 30%: ~1.300 visitas por variante.

Cómo elegir MDE realista:

1. MDE muy chico (<5%): solo posible si tu tráfico es >100k visitas/mes. Para PYMEs típicas, MDE 5% es irreal.

2. MDE razonable PYME (10-20%): detectable con 5.000-15.000 visitas por variante. Realista para landings con tráfico medio.

3. MDE grande (25-40%): detectable con 1.000-3.000 visitas por variante. Realista para PYMEs chicas. Solo testear cambios drásticos.

Errores comunes con MDE:

• No definirlo antes del test. El equipo "espera ver qué pasa" y termina con tests subdimensionados sin saberlo.
• Pretender detectar efectos pequeños sin tráfico. "Quiero saber si esto mejora 5%" cuando tienes 2.000 visitas/mes es imposible matemáticamente.
• Confundir MDE con "mejora real esperada". Son distintos. El MDE es lo mínimo que el test puede detectar, no lo que la versión B realmente va a mover.

Regla operativa:

Antes de cada test, calcular: "con mi tráfico actual y duración tolerable, ¿qué MDE puedo detectar?". Si el MDE resultante es 30% pero las mejoras realistas son del 10%, el test no vale la pena. Mejor invertir en otra cosa (mejorar mensaje, segmentación, producto) que en testear sin sensibilidad.

Regla 1: definir tamaño de muestra antes del test.

Usa calculadora estándar (Evan Miller, Optimizely sample size calculator, AB Testguide). Inputs: baseline conversion, MDE, significancia (95%), potencia (80%). Output: muestra mínima por variante.

Una vez definida, NO mires el test antes de completar esa muestra. "Peeking" invalida estadística.

Regla 2: duración mínima de 1 ciclo de negocio completo.

Incluso si la muestra se completa antes, deja correr el test al menos 1 semana completa, idealmente 2.

Razón: el comportamiento varía por día de la semana. Tu tráfico de lunes es distinto del de viernes. Tu tráfico de fin de mes es distinto del medio. Si el test corre 3 días que coinciden con un patrón, captura sesgo de día.

Regla 3: duración máxima de 4-6 semanas.

Más largo introduce sesgo de cookie expiration, cambios estacionales, eventos externos, evolución natural del producto. Si tu tamaño de muestra requiere más de 6 semanas, el test está mal dimensionado para tu tráfico.

Regla 4: no detener tests antes ni después de lo planeado.

Detener antes "porque ya hay ganador" invalida estadística. Detener después "a ver si se afirma" baja calidad estadística por peeking continuado.

Regla 5: split traffic correctamente (50/50 o 33/33/33).

Splits desbalanceados (90/10) son válidos estadísticamente pero requieren mucha más muestra y son raramente justificados. Default 50/50.

Ejemplo aplicado: una PYME con 8.000 visitas/mes, baseline conversion 4%, quiere testear cambio en hero. Calcula muestra: para detectar MDE 20% necesita 4.500 por variante. Con 50/50 split y 8.000 visitas/mes, eso son 9.000 visitas total. El test debe correr ~5 semanas. Si lo detiene a las 2 semanas, la conclusión es falsa.

1. Cambiar el test mientras corre. El equipo "mejora" el copy a mitad del test, o modifica la versión B porque "ahora se ve mejor". Cualquier cambio durante el test reinicia la muestra desde cero. Ningún resultado previo es válido.

2. Métrica primaria definida después del test. Si corres test, miras 5 métricas, y eliges como "primaria" la que salió ganadora, estás haciendo data dredging. La estadística requiere que la métrica primaria se defina ANTES.

3. Segmentos mezclados con baseline distinto. Si testeas en mobile + desktop juntos, y la versión B en realidad solo mejora en desktop, el resultado global puede ser ambiguo o engañoso. Mejor segmentar tests por device o por fuente desde el inicio.

4. Cookie problems / contaminación. El usuario en variante A entra el lunes desde Chrome, el martes desde Safari, ve variante B, se confunde, abandona. Esto es contaminación y baja la validez. Soluciones: identificar usuario por login si aplica, configurar herramienta de testing correctamente, evitar dispositivos múltiples si tu producto lo permite.

5. Externalities no controlados. Lanzaste el test el mismo día que el competidor bajó precios, o que tu equipo de ads cambió la campaña. Cualquier cambio externo simultáneo invalida el test. Mantener "freeze" de otros cambios mientras corre un test crítico.

Bonus: error 6. Testear cambios demasiado pequeños. Cambiar el color del botón de azul a verde es poco probable que mueva conversión 20%+, que es el MDE realista para la mayoría de las PYMEs. Mejor testear cambios grandes (rediseño de sección hero, value prop completo, estructura de pricing) donde el efecto esperado es grande.

Reglas para evitar los 6 errores:

• Documento de pre-registro del test antes de empezar: hipótesis, métrica primaria, MDE objetivo, duración planeada, criterio de ganador.
• Freeze de cambios externos durante el test.
• Plataforma de testing seria (Optimizely, VWO, Convert) que maneje cookies y stats correctamente.
• Equipo con conocimiento básico de estadística o consultor que valide diseño antes de correr.

A/B testing no es siempre la respuesta correcta. Hay situaciones donde otras herramientas son superiores.

Situaciones donde NO hacer A/B test:

1. Tráfico bajo (<3.000 visitas/mes a la página). El test va a requerir 3-6 meses, los cambios externos van a contaminarlo, y al final no vas a tener confianza estadística. Mejor: aplicar best practices y heurísticas validadas, después medir antes/después con cohort comparison.

2. Cambios obvios. Si tu landing tiene errores claros (typo en CTA, formulario roto, copy ilegible), no testees. Arregla. El test consume tiempo y muestra que podrías invertir en cambios con impacto mayor.

3. Cambios drásticos de mensaje o posicionamiento. A/B testing es bueno para optimizar dentro de un mensaje. No es bueno para validar mensajes completos. Para eso: customer interviews, surveys, landing pages independientes con paid traffic dedicado.

4. Productos en early stage sin product-market fit. Optimizar conversión de un producto que no funciona es desperdicio. Primero PMF, después optimización.

Alternativas a A/B testing:

1. Heatmaps y session recordings. Hotjar, Microsoft Clarity (gratis). Te muestran qué ven y dónde abandonan los usuarios. Útil para diagnóstico.

2. Customer interviews. 5-10 conversaciones de 30 min con usuarios reales descubren más insights que 10 A/B tests.

3. Cohort analysis. Comparar usuarios pre vs post-cambio. Menos riguroso que A/B test pero útil cuando A/B testing no es viable.

4. Multivariate testing. Si tu tráfico es muy alto (>50k visitas/mes), MVT permite testear múltiples cambios simultáneamente. Más eficiente que A/B sequencial.

5. Bandit algorithms. En lugar de tener split fijo, el algoritmo asigna más tráfico a la variante que va ganando en tiempo real. Útil para optimizar conversion en flujos críticos donde cada visita cuenta.

Regla operativa para PYMEs: A/B testing serio requiere mínimo 5.000-10.000 visitas/mes en la página testeada. Si tienes menos, invierte tu tiempo en customer research y best practices. Cuando crezcas en tráfico, empieza con A/B testing serio.