¿Cuántos Tests A/B Deberías Hacer por Mes?
Cuántos tests A/B por mes banca tu sitio: la cuenta de capacidad a partir del tráfico, con calculadora y ejemplo trabajado.

📚 Este artículo es parte de la guía Cómo Construir una Cultura de Experimentación (2026).
La respuesta honesta a “cuántos tests A/B hacer por mes” no es un número de benchmark: es la capacidad que banca tu tráfico, y sale de una cuenta de dos líneas. La duración de cada test es el mayor valor entre la muestra necesaria dividida por el tráfico diario y un piso de dos semanas; la capacidad mensual es la cantidad de días del mes dividida por esa duración. Este artículo muestra la cuenta, explica por qué los números de Booking y Microsoft no sirven de meta para casi nadie, revela el punto en el que más tráfico deja de comprar más tests y pasa a comprar más sensibilidad, y trae calculadoras en vivo con un ejemplo trabajado de punta a punta. Forma parte de la guía de cómo construir una cultura de experimentación.
Por qué el benchmark del mercado no sirve como meta
Todo artículo sobre velocidad de experimentación cita a los mismos gigantes. Microsoft documentó públicamente el programa de experimentación de Bing, con miles de experimentos corriendo a escala (Bing Search Quality Insights, Large Scale Experimentation at Bing). Casos de empresas como Booking.com, que según relatos públicos llegó a mantener cientos de tests simultáneos, circulan como referencia de excelencia.
Esos números describen una condición que casi nadie tiene: decenas de millones de sesiones por mes, plataforma interna dedicada y equipos enteros de infraestructura de experimentación. Copiar la meta sin copiar el tráfico produce el peor resultado posible: una cadencia artificialmente alta, tests cerrados antes de tiempo para “caber en el mes” y una secuencia de decisiones tomadas sobre ruido.
La pregunta útil no es “cuántos tests hace Booking”, es “cuántos tests banca mi tráfico con rigor estadístico”. Esa segunda pregunta tiene respuesta numérica exacta.
La cuenta de la capacidad
Son tres entradas y dos operaciones:
- Muestra por variación. Depende de la tasa base de conversión, del efecto mínimo detectable (MDE) y del rigor (estándar de mercado: 95% de confianza y 80% de poder). Es el mismo cálculo de la guía de cómo hacer un test A/B paso a paso.
- Muestra total del test. Muestra por variación multiplicada por el número de variaciones (2 en un A/B clásico).
- Tráfico diario en el flujo testeado. No el tráfico del sitio entero: solo quien entra en el flujo donde corre el test.
Con eso: días por test = el mayor valor entre (muestra total dividida por el tráfico diario) y el piso de duración, y tests por mes = 30 dividido por días por test.
El piso de duración merece explicación. Aunque el tráfico cierre la muestra en tres días, cerrar un test en tres días mide solo el comportamiento de martes a jueves, y el público de fin de semana suele convertir de forma distinta. Dos semanas es el piso más común de mercado porque captura dos ciclos semanales completos. Es ese piso el que transforma la cuenta en dos fases distintas, y la segunda sorprende a mucha gente.
Cuántos tests A/B por mes banca tu tráfico
La tabla de abajo aplica la cuenta a un escenario común: conversión base del 2,5%, dos variaciones, piso de 14 días, y la ambición de detectar un efecto relativo del 20% (lo que exige 16.792 visitantes por variación, 33.584 en total).
| Visitantes por mes en el flujo | Días limitados por el tráfico | Duración real por test | Tests por mes | Cuello de botella |
|---|---|---|---|---|
| 20.000 | 51 | 51 días | 0,6 | Tráfico |
| 60.000 | 17 | 17 días | 1,8 | Tráfico |
| 200.000 | 6 | 14 días | 2,1 | Calendario |
| 600.000 | 2 | 14 días | 2,1 | Calendario |
Muestra por aproximación normal de dos proporciones (95% de confianza, 80% de poder, bilateral), 2 variaciones, piso de 14 días, mes de 30 días.
Dos lecturas importantes salen de ahí. La primera: entre 200 mil y 600 mil visitantes mensuales, la capacidad no cambia. Triplicar el tráfico no dio ningún test más, porque el piso de dos semanas ya era el límite. La segunda: el sitio de 20 mil visitantes no está condenado a 0,6 tests por mes para siempre, solo que no logra detectar un efecto del 20% en ese plazo. Buscando un efecto mayor, la misma operación vuelve a caber en el calendario.
Calcula tu capacidad real, con tu tasa base, tu MDE y tu tráfico:
Muestra por variación al 95% de confianza y 80% de poder (bilateral), según tu tasa y MDE. Ajusta los campos y mira la capacidad en vivo.
Qué hacer con el tráfico excedente
Cuando el cuello de botella pasa a ser el calendario, el tráfico que sobra tiene un uso mejor que “cerrar el test en 6 días”: comprar sensibilidad. Con más muestra dentro de la misma ventana de 14 días, el mismo test pasa a detectar efectos menores, y los efectos menores son la mayor parte de los efectos reales.
En el escenario de la tabla, el sitio de 200 mil visitantes mensuales que baja la ambición de +20% a +10% relativo pasa a necesitar 64.199 visitantes por variación. Eso estira la duración a 20 días y derriba la capacidad de 2,1 a 1,5 tests por mes. Es un canje deliberado y casi siempre bueno: menos tests por mes, pero cada uno capaz de ver mejoras que antes pasarían como empate.
| Ambición del test | Muestra por variación | Duración a 200 mil por mes | Tests por mes |
|---|---|---|---|
| Detectar +20% relativo | 16.792 | 14 días (piso) | 2,1 |
| Detectar +10% relativo | 64.199 | 20 días | 1,5 |
O sea: la pregunta “cuántos tests por mes” y la pregunta “qué tamaño de efecto logro ver” son la misma pregunta, vista desde dos lados. Fijar una define la otra.
Ejemplo trabajado: un SaaS de 60 mil visitantes por mes
Un SaaS recibe 60.000 visitantes por mes en la landing page de registro, con conversión del 2,5% en inicio de trial. El equipo quiere detectar una ganancia relativa del 20% (de 2,5% a 3,0%).
- Muestra por variación: 16.792 visitantes.
- Muestra total del test (2 variaciones): 33.584 visitantes.
- Tráfico diario: 60.000 dividido por 30, o sea, 2.000 visitantes por día.
- Días necesarios por el tráfico: 33.584 dividido por 2.000, o sea, 17 días.
- Duración real: 17 días, porque 17 es mayor que el piso de 14.
- Capacidad: 30 dividido por 17, aproximadamente 1,8 tests por mes, o cerca de 21 tests por año.
Verifica el primer paso de esa cuenta con tu propia tasa base:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Ahora la parte que cambia decisiones. Ese equipo tiene 21 tests por año de capacidad. Si aplica la proporción que Ronny Kohavi documentó para experimentos en Microsoft, aproximadamente un tercio de las ideas mejora la métrica objetivo, un tercio queda neutro y un tercio empeora (Kohavi, Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years, KDD 2015), entonces la expectativa realista es de cerca de 7 victorias por año, de las cuales varias serán pequeñas.
Ese número suele asustar, y es exactamente por eso que necesita estar en la planificación. Un roadmap que promete “vamos a aumentar la conversión un 40% este año con tests A/B” y tiene capacidad de 21 tests está prometiendo algo que la matemática no sostiene. Un roadmap que planifica 21 tests, espera 7 victorias y trata cada una como una ganancia compuesta está siendo honesto con su propia capacidad. La plantilla de roadmap de experimentación tiene la columna de duración justamente para forzar esa conversación antes del compromiso.
Paralelizar sin contaminar la lectura
La salida obvia para duplicar la cadencia es hacer dos tests al mismo tiempo, y funciona con una condición: los tests no pueden disputar el mismo público en la misma decisión. Dos experimentos en flujos independientes (uno en la página de precios, otro en el flujo de recuperación de contraseña) conviven sin problema, porque la mayor parte de los visitantes de uno nunca ve el otro.
El caso peligroso es el opuesto: dos tests en el mismo recorrido, o dos tests que mueven la misma métrica primaria. Ahí surgen tres problemas al mismo tiempo. La muestra se divide entre cuatro combinaciones en lugar de dos, lo que alarga los dos tests en vez de acelerar el programa. La interacción entre los cambios queda incorporada al resultado, y ninguno de los dos reportes logra separar el efecto propio del efecto del vecino. Y si los dos “ganan”, subir los dos cambios juntos puede entregar menos que la suma prometida, porque parte de la ganancia era la misma ganancia contada dos veces.
Dos formas de organizar esto sin renunciar a la paralelización: exclusión mutua, en la que cada visitante entra en como máximo un experimento y los grupos quedan completamente separados, o capas ortogonales, en las que la asignación de un test se sortea de forma independiente de la del otro, garantizando que las combinaciones queden equilibradas. La primera es más simple y más conservadora, la segunda aprovecha mejor el tráfico. En cualquiera de las dos, vale la regla práctica: un test por flujo, y la decisión de paralelizar tomada en la planificación, no en medio de la ejecución.
Si tu capacidad es baja
Un resultado de 0,6 tests por mes no significa “no testees”. Significa que la estrategia necesita cambiar de forma:
- Testea cambios grandes, no ajustes finos. Con poca muestra, solo los efectos grandes son detectables. Una nueva propuesta de valor tiene chance de producir un efecto del 25% o más; un color de botón, casi nunca. La guía completa de optimización de conversión cubre qué tipo de cambio suele producir un efecto lo bastante grande para ser detectable.
- Sube la métrica primaria en el embudo. Medir inicio de registro (tasa base alta) en lugar de compra concluida (tasa base baja) reduce la muestra necesaria en órdenes de magnitud. El costo es medir un proxy del resultado final, lo que necesita quedar documentado.
- Agrupa páginas parecidas en un único test. Si tres landing pages comparten la misma estructura, testear el cambio en las tres al mismo tiempo suma su tráfico y reduce la duración proporcionalmente.
- Acepta plazos mayores para menos tests. Dos tests bien dimensionados por trimestre valen más que seis tests cerrados a la mitad, que solo producen falsos positivos.
Errores comunes a la hora de definir la cadencia
| Error | Señal de alerta | Corrección |
|---|---|---|
| Copiar el benchmark de un gigante | “Booking hace miles, nosotros vamos a hacer 20 por mes” | Calcula la capacidad a partir de tu tráfico, no de la meta de los demás |
| Cerrar temprano para caber en el mes | Test detenido el día 8 porque “ya dio significancia” | Fija la duración antes de correr y respeta el piso de dos semanas |
| Contar el tráfico del sitio entero | Usó 500 mil sesiones cuando el flujo testeado recibe 40 mil | Usa solo el tráfico que entra en el flujo del test |
| Ignorar el piso de duración | Test de 4 días porque el tráfico cierra la muestra | Corre al menos uno o dos ciclos semanales completos |
| Hacer dos tests en el mismo flujo | Dos experimentos simultáneos en el checkout | Un test por flujo; usa flujos distintos para paralelizar |
| Medir velocidad en lugar de aprendizaje | Panel con “tests hechos en el mes” como KPI principal | Mide también cuántos tests tenían hipótesis defendible y qué enseñó cada uno |
Hazlo automático en Donnu
Descubrir cuántos tests caben en tu mes implica calcular muestra, dividir por tráfico real, respetar el piso de duración y reordenar el roadmap cuando la cuenta cambia. Donnu hace esa parte por ti: al configurar un test, lo dimensiona contra tu tráfico real, muestra la duración estimada antes de que empieces, y acompaña la recolección sin dejar que una mirada al panel se convierta en una decisión prematura. Planificas la cadencia con números en lugar de esperanza.
Empieza una prueba gratis de 14 días y descubre la capacidad real de tu tráfico antes de prometer resultados. Para organizar la cola que esa capacidad soporta, mira la plantilla de roadmap de experimentación.
Referencias
- Kohavi, R. Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years. Keynote, ACM SIGKDD 2015. exp-platform.com/Documents/2015-08OnlineControlledExperimentsKDDKeynoteNR.pdf.
- Bing Search Quality Insights. Large Scale Experimentation at Bing. Microsoft. blogs.bing.com/search-quality-insights/August-2013/Large-Scale-Experimentation-at-Bing.
- Kohavi, R. ExP Platform: accelerating innovation through trustworthy experimentation. exp-platform.com.
- Kohavi, R. y Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.
Lee también:
Preguntas frecuentes
- ¿Cuántos tests A/B por mes debería hacer una empresa?
- No existe un número universal: la respuesta correcta es la capacidad que banca tu tráfico. Sale de una división simple: días del mes divididos por la duración de cada test, y la duración es el mayor valor entre la muestra necesaria dividida por el tráfico diario y un piso de dos semanas para capturar el ciclo semanal completo. Un sitio con 60 mil visitantes por mes, conversión del 2,5% y ambición de detectar +20% relativo logra cerca de 1,8 tests por mes. Uno con 200 mil llega a 2,1, limitado por el calendario y ya no por el tráfico.
- ¿Hacer más tests A/B por mes significa crecer más rápido?
- Solo hasta cierto punto, y nunca por sí solo. La velocidad multiplica la calidad de las hipótesis: si la mayoría de tus tests no tiene hipótesis defendible, aumentar la cadencia solo produce más empates más rápido. Según datos publicados por Ronny Kohavi sobre experimentos en Microsoft, aproximadamente un tercio de las ideas testeadas mejora la métrica objetivo, un tercio no cambia nada y un tercio empeora. La velocidad sin calidad de hipótesis solo acelera esos dos últimos tercios.
- Mi sitio tiene poco tráfico. ¿Debo renunciar a testear?
- No, pero necesitas cambiar qué testeas. Con poco tráfico, solo los efectos grandes son detectables, así que los tests de cambio radical (nuevo layout, nueva propuesta de valor, nueva estructura de oferta) tienen más sentido que los ajustes de color de botón. También vale mover la métrica primaria a un evento más frecuente y más arriba en el embudo, como inicio de registro en lugar de compra concluida.
- ¿Por qué más tráfico, a partir de cierto punto, no aumenta la cantidad de tests?
- Porque la duración mínima pasa a ser un límite de calendario, no de muestra. Todo test debería correr al menos una o dos semanas completas para capturar la variación entre días hábiles y fin de semana. Cuando el tráfico ya cierra la muestra en tres días, el piso de dos semanas manda, y el excedente de tráfico pasa a comprar sensibilidad (detectar efectos menores) en lugar de cantidad de tests.
- ¿Puedo hacer dos tests A/B al mismo tiempo para duplicar la cadencia?
- Puedes, siempre que no disputen el mismo flujo ni la misma métrica primaria. Dos tests en páginas distintas de recorridos distintos conviven bien. Dos tests en la misma página comparten visitantes, y la interacción entre los cambios contamina la lectura de ambos, además de dividir la muestra y alargar los dos.