Pruebas A/B con poco tráfico: lo que sí puedes medir

Alguien de tu equipo lanzó una prueba A/B en la página de precios. A las tres semanas, la versión nueva "gana" con 95% de significancia y ya hay una diapositiva que dice que las solicitudes de demo subieron 40%. Antes de publicarla, pregunta cuántos visitantes necesitaba esa prueba para detectar un efecto real. En una página con unos pocos miles de visitas al mes, la respuesta puede superar el tráfico de todo un año.

Eso no es motivo para dejar de experimentar. Es motivo para calcular la muestra de cada prueba antes de lanzarla.

¿Cuántos visitantes necesita una prueba A/B?

El tamaño de muestra depende de cuatro datos: tu tasa de conversión base, la mejora más pequeña que vale la pena detectar (el efecto mínimo detectable o MDE), el nivel de significancia y la potencia, que es la probabilidad de detectar un efecto real de ese tamaño. Lo estándar en la industria es 5% de significancia y 80% de potencia.

Con esos valores, Ron Kohavi, Alex Deng y Lukas Vermeer proponen una regla práctica en "A/B Testing Intuition Busters", su paper de KDD 2022. Cada variante necesita unos 16 * p * (1 - p) / d^2 usuarios, donde p es la tasa base y d es el cambio absoluto que quieres detectar. Su ejemplo: con una conversión de 3.7% y una mejora relativa de 10% (de 3.7% a cerca de 4.07%), hacen falta 41,642 usuarios por variante. La prueba detrás del ejemplo tuvo unos 80 usuarios por variante, cerca de 3% de potencia para esa mejora, y reportó un alza de 337%.

Fíjate en el cuadrado: para detectar la mitad de la mejora, necesitas cuatro veces el tráfico.

¿Cómo se ve eso en una página B2B?

Ahora, una página parecida a la tuya. Es aritmética, no el resultado de ninguna empresa. Supón que tu página de precios recibe 3,000 visitas al mes y que el 2% pide una demo. Divididas en dos, son 1,500 visitas por variante al mes.

Una mejora de 10% (de 2.0% a 2.2%) necesita unas 78,000 visitas por variante: más de cuatro años. Si cortas la prueba a los seis meses, tendrías más o menos una probabilidad en seis de detectar una mejora real.
Una mejora de 30% (de 2.0% a 2.6%) necesita unas 8,700 por variante: unos seis meses.
Una métrica más arriba en el funnel cambia las cuentas. Si el 20% de los visitantes hace clic para ir al formulario de demo, una mejora relativa de 20% en ese clic (de 20% a 24%) necesita unas 1,600 por variante: unas cinco semanas.

Las tres cifras usan la misma regla práctica; un cálculo más estricto de dos proporciones da hasta 12% más. La guía del paper de KDD: las pruebas A/B sirven cuando tienes por lo menos miles de usuarios activos, idealmente decenas de miles.

¿Qué sale mal si haces la prueba de todos modos?

Los ganadores de pruebas con poca potencia suelen ser falsos o exagerados. El paper de KDD recopila tasas de éxito publicadas (la proporción de ideas que mejoraron la métrica objetivo): desde cerca de un tercio en Microsoft hasta 8% en Airbnb Search. Los autores las llaman estimaciones aproximadas, y vienen de empresas con muchísimo más tráfico que la tuya. Según sus cálculos, con 20% de potencia y una tasa de éxito de 10%, como la de Booking.com o Netflix, más de la mitad de los resultados estadísticamente significativos serían falsos positivos, y los efectos reales que alcanzan significancia en pruebas con poca potencia tienden a salir exagerados. Una mejora de 40% con 3,000 visitas al mes debería hacerte sospechar más, no menos.

Revisar el resultado antes de tiempo rompe la estadística. Un valor p (p-value) estándar supone que fijaste el tamaño de muestra de antemano. Si detienes la prueba la primera vez que el dashboard dice "significativo", los falsos positivos suben. En "How Not To Run an A/B Test", un ensayo de 2010, Evan Miller calcula el peor caso: si un cambio que no hace nada se revisa después de cada visitante hasta llegar a 150, la prueba declara un ganador el 26.1% de las veces, no el 5%. Ramesh Johari, Leo Pekelis y David Walsh, en un paper de arXiv (2015, revisado en 2019), advierten que con monitoreo continuo los valores p estándar no son confiables en absoluto. Sus valores p "siempre válidos" permiten revisar sobre la marcha y se usaron en una gran plataforma comercial de pruebas A/B en cientos de miles de experimentos.

¿Cómo experimentar con poco tráfico?

Cinco tácticas, en el orden en que las probaríamos.

Prueba cambios más grandes. Si solo puedes detectar una mejora de 30%, prueba solo ideas que puedan producirla: un formulario de demo más corto, una nueva estructura de precios, un onboarding rehecho, un rediseño real de la página. Cambiar el color de un botón no alcanza. Como referencia, el paper de KDD considera grande una mejora de 10% en un solo experimento, y cuenta que en Bing la mejora mensual de ingresos, sumando muchos experimentos, solía quedarse en unos pocos puntos porcentuales.
Mide más arriba en el funnel. Clics al formulario de demo, pasos completados del onboarding, una función clave usada en la primera semana. Con tasas base más altas, la muestra necesaria baja muchísimo. La condición: una métrica proxy solo sirve si se mueve junto con el resultado que te importa, así que compruébalo primero con tu historial. Una solicitud de demo tampoco es pipeline, como explicamos en el post de generación de demanda.
Asigna por cuenta en las pruebas de producto. Los usuarios de una misma cuenta cliente comparten pantallas, configuración y opiniones. Si divides a un equipo entre dos flujos, los grupos pueden contaminarse entre sí. Asignar cuentas completas lo evita. Es un razonamiento de diseño, tema de los capítulos 14 ("Choosing a Randomization Unit") y 22 ("Leakage and Interference between Variants") del libro Trustworthy Online Controlled Experiments, de Kohavi, Tang y Xu (2020). El costo: tu muestra ahora son cuentas, no usuarios.
Reduce la varianza con datos previos al experimento. CUPED, un método que investigadores de Microsoft publicaron en WSDM 2013, ajusta el resultado de cada usuario con datos previos a la prueba, normalmente la misma métrica medida antes. En Bing redujo la varianza cerca de 50%: la misma potencia con la mitad de usuarios o la mitad del tiempo. La ganancia depende de qué tan bien el periodo previo predice la prueba: rinde mucho con el uso de producto de usuarios con sesión iniciada y, con visitantes nuevos, no tiene con qué trabajar. Nunca uses una covariable que el cambio pueda afectar: el paper muestra una que invierte un resultado conocido.
Define la regla de detención antes de lanzar. Un tamaño de muestra fijo que esperas a completar, o un método secuencial diseñado para revisar sobre la marcha. Nunca "ya veremos".

¿Cuándo conviene no hacer la prueba A/B?

Cuando la aritmética dice años, la prueba es puro teatro. Haz el cambio con criterio e investigación con usuarios, escribe qué esperas que pase y sigue la métrica, sabiendo que una comparación de antes y después no separa tu cambio de la estacionalidad. Un "lo decidimos" honesto vale más que un falso "los datos lo probaron".

¿Qué debe incluir un plan de prueba?

Una página, aprobada antes de activar el feature flag:

Métrica principal y su evento, definidos una sola vez y registrados en tu data warehouse igual en ambas variantes.
Tasa base, con al menos un mes de historial.
Efecto mínimo detectable, significancia y potencia, y por qué ese efecto le importa al negocio.
Tamaño de muestra y duración, redondeados a semanas completas para que cuenten días hábiles y fines de semana.
Unidad de asignación y regla de detención.

Un plan que responde "dos años" hizo su trabajo.

Menos pruebas, pero más grandes

La mayoría de las ideas que un equipo B2B quiere probar son de Marketing y Studio: landing pages, la página de precios, el onboarding. Build implementa los feature flags que asignan las variantes, y Data calcula la muestra antes de lanzar la prueba y la interpreta después. Hacer menos pruebas, pero más grandes, es una decisión de planificación entre las cuatro prácticas, no un ajuste de configuración. Y si tus herramientas no coinciden en el conteo de conversiones, arregla primero los números.

Relacionados: El modern data stack sin hype → · Atribución sin cookies → · Por qué tus números no cuadran →