Velocidad de Experimentación: cómo calcularla (plantilla)
Plantilla gratis para calcular tu velocidad de experimentación: techo estadístico, tiempo de ciclo real, aprovechamiento y los 4 indicadores que importan.
📚 Este artículo es parte de la guía Cómo Construir una Cultura de Experimentación (2026).
Velocidad de experimentación es cuántos experimentos válidos concluye tu equipo por año, medidos de punta a punta. Casi todo el mundo calcula esto mal, porque cuenta solo los días en que el test estuvo en producción e ignora los días de construcción, de espera y de resultado parado esperando a que alguien decida. El resultado es un programa que cree tener capacidad de 26 tests por año y entrega 11. Este artículo trae la plantilla completa para calcular los dos números que importan, el techo estadístico que tu tráfico permite y la velocidad real que tu proceso entrega, más el indicador que sale de la razón entre ellos y dice exactamente dónde está goteando el programa. Forma parte de la guía de cómo construir una cultura de experimentación.
Los dos números que forman la velocidad de experimentación
Velocidad de experimentación no es un número, son dos, y la diferencia entre ellos es el diagnóstico.
Techo estadístico. Cuántos tests aguanta tu tráfico por año, si el proceso fuera instantáneo. Sale de la muestra necesaria dividida por el tráfico diario, respetado el piso de duración de dos semanas. Es un límite físico: ningún proceso, por mejor que sea, lo supera.
Velocidad real. Cuántos tests concluye efectivamente el equipo por año, contando el ciclo completo de cada uno. Sale de 365 dividido por el tiempo de ciclo medio.
Aprovechamiento. La razón entre los dos. Es donde la conversación se vuelve útil, porque dice si la próxima ganancia viene de comprar tráfico o de arreglar el proceso. Un aprovechamiento del 40% significa que el 60% del potencial de tu tráfico se está desperdiciando en fricción, y ningún aumento de audiencia recupera eso.
Paso 1: calcula el techo estadístico
El techo sale de tres entradas: la tasa de conversión base del flujo, el efecto mínimo detectable que quieres alcanzar a ver y el tráfico diario en ese flujo. Conviene recordar que es el tráfico del flujo probado, nunca el del sitio entero.
Córrelo con tus números:
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.
Un detalle del techo sorprende a casi todo el mundo la primera vez: por encima de cierto punto, ser más ambicioso en el MDE no compra más tests. En el ejemplo trabajado de abajo, con 90.000 visitantes por mes, dimensionar para +15% relativo y dimensionar para +25% relativo dan exactamente la misma capacidad, porque en los dos casos manda el piso de dos semanas. La ambición extra se convierte solo en pérdida de sensibilidad, sin ninguna ganancia de cadencia.
Paso 2: mide el tiempo de ciclo de verdad
El tiempo de ciclo es el reloj que empieza cuando la hipótesis se aprueba y para cuando la decisión queda registrada. Tiene cuatro pedazos, y tres de ellos no recogen ningún dato.
| Etapa del ciclo | Qué cuenta | Señal de que esa etapa es tu cuello de botella |
|---|---|---|
| Construcción | De la hipótesis aprobada hasta la variación en producción | La cola de tests listos para correr está siempre vacía |
| Recogida | Del inicio al fin de la ventana fijada | El test corre menos que el piso de dos semanas |
| Lectura y decisión | Del fin de la recogida hasta la decisión registrada | Resultados listos esperando una reunión |
| Espera | Días entre la decisión y el inicio del próximo test | El hueco queda vacío mientras se discute la próxima variación |
Anota los cuatro para cada test concluido. Tres o cuatro tests bastan para que la media sea informativa, y el patrón aparece rápido: en la mayoría de los programas iniciales, construcción y espera juntas superan a la recogida.
Un cuidado de medición que cambia el resultado: la etapa de espera es la más fácil de olvidar, porque nadie es responsable de ella. No aparece en ningún ticket, no tiene dueño y por eso raramente entra en la cuenta. Es también, con frecuencia, la mayor de las cuatro.
Paso 3: la plantilla rellenable
Copia la tabla de abajo a tu hoja de cálculo. Las tres primeras líneas son entradas, el resto es cálculo.
| Campo | Cómo rellenarlo | Ejemplo |
|---|---|---|
| Visitantes por mes en el flujo | Solo quien entra en el flujo probado | 90.000 |
| Tasa de conversión base | Métrica primaria del flujo | 3,5% |
| MDE objetivo | Efecto relativo que vale detectar | +15% |
| Muestra por variación | Salida de la calculadora | 20.622 |
| Muestra total (2 variaciones) | Muestra por variación por 2 | 41.244 |
| Tráfico diario | Visitantes por mes dividido por 30 | 3.000 |
| Días de recogida | Mayor valor entre muestra total dividida por el tráfico diario y el piso | 14 |
| Techo estadístico anual | 365 dividido por los días de recogida | 26,1 |
| Días de construcción (media) | Medido en los últimos tests | 8 |
| Días de lectura y decisión (media) | Medido en los últimos tests | 4 |
| Días de espera (media) | Medido en los últimos tests | 8 |
| Tiempo de ciclo | Suma de las cuatro etapas | 34 |
| Velocidad real anual | 365 dividido por el tiempo de ciclo | 10,7 |
| Aprovechamiento | Velocidad real dividida por el techo | 41% |
| Tests con hipótesis registrada | Proporción en el trimestre | anotar |
| Resultados documentados | Proporción en el trimestre, incluyendo empates | anotar |
Las dos últimas líneas no entran en el cálculo de velocidad y están ahí a propósito. Velocidad sin calidad de hipótesis es solo producir empates más rápido, y un número de cadencia exhibido solo se convierte en meta perversa en cuestión de semanas.
Ejemplo trabajado: un SaaS de 90 mil visitantes por mes
El flujo de registro recibe 90.000 visitantes por mes, convierte el 3,5% en inicio de prueba, y el equipo dimensiona para detectar +15% relativo con 95% de confianza y 80% de poder.
- Muestra por variación: 20.622 visitantes.
- Muestra total (2 variaciones): 41.244 visitantes.
- Tráfico diario: 90.000 dividido por 30, es decir, 3.000 visitantes por día.
- Días exigidos por el tráfico: 41.244 dividido por 3.000 da 13,7, redondeado hacia arriba en días enteros de recogida, es decir, 14 días.
- Duración real: 14 días, empatando con el piso.
- Techo estadístico: 365 dividido por 14, aproximadamente 26 tests por año.
Comprueba la muestra 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 el otro lado. Midiendo los últimos cuatro tests de ese equipo: 8 días de construcción, 14 de recogida, 4 de lectura y decisión, 8 de espera hasta el inicio del siguiente. Tiempo de ciclo de 34 días.
- Velocidad real: 365 dividido por 34, aproximadamente 10,7 tests por año.
- Aprovechamiento: 10,7 dividido por 26,1, aproximadamente 41%.
El equipo está dejando 15 tests por año sobre la mesa, y ninguno de ellos exige un visitante más. Vale notar lo que la cuenta dice sobre la alternativa más cara: si ese mismo equipo duplicara el tráfico del flujo a 180.000 visitantes por mes, el techo seguiría en 26 tests por año, porque la recogida ya está en el piso de dos semanas. El tráfico extra compraría sensibilidad (la posibilidad de ver efectos menores), lo que es valioso, pero no compraría ningún test más. La cadencia solo mejora atacando los 20 días fuera de la recogida.
Qué hacer con cada cuello de botella
| Cuello de botella | Palanca | Coste real |
|---|---|---|
| Construcción larga | Mantener la próxima variación lista antes de que el hueco se libere | Exige decidir la cola con antelación |
| Construcción larga | Estandarizar los cambios más frecuentes en componentes reutilizables | Inversión inicial de ingeniería |
| Recogida por encima del piso | Subir la métrica primaria en el embudo o aumentar el MDE objetivo | Pierde sensibilidad o mide un proxy |
| Lectura lenta | Escribir la regla de decisión antes de correr | Exige acordar el criterio cuando nadie sabe el resultado |
| Espera entre tests | Paralelizar en flujos independientes | Solo funciona si los flujos no comparten público |
| Espera entre tests | Reservar el hueco en el calendario antes de que acabe el test anterior | Exige tratar el hueco como recurso, no como intención |
La palanca más subestimada es la regla de decisión escrita antes del test. Acorta la etapa de lectura porque elimina la discusión más cara del ciclo, que es decidir el criterio después de conocer ya el resultado. Como efecto colateral, también protege contra el cambio de métrica primaria, que es uno de los caminos silenciosos para inflar la tasa de victoria del programa. El coste estadístico de decidir después de ver los datos está detallado en el problema del peeking en tests A/B.
Una advertencia sobre paralelizar: correr dos tests al mismo tiempo aumenta la velocidad real sin tocar el ciclo individual, pero solo cuando los dos flujos no disputan el mismo público y la misma métrica primaria. Dos tests en el mismo recorrido dividen la muestra entre cuatro combinaciones, alargan los dos e incorporan la interacción en el resultado de ambos. La regla práctica es un test por flujo.
Cuánto cuesta un aprovechamiento del 41%
La discusión de proceso suele perder contra la discusión de medios porque el coste de la fricción nunca se expresa en número. En este caso es fácil de expresar.
El equipo del ejemplo deja 15,4 tests por año sobre la mesa (26,1 de techo contra 10,7 de velocidad real). Aplicando la proporción que Ronny Kohavi documentó para experimentos en Microsoft, aproximadamente un tercio de las ideas probadas mejora la métrica objetivo (Kohavi, KDD 2015), esos 15,4 tests no corridos equivalen a cerca de 5 mejoras por año que el equipo nunca va a encontrar, más otros 5 cambios malos que no va a descubrir a tiempo de evitar.
El tercer bloque es el más fácil de olvidar y suele ser el más caro. Los tests que no corren no dejan el cambio parado: el cambio sube igual, sin medición, y el perjuicio aparece meses después como una caída de métrica que nadie consigue atribuir.
Dos trampas al acortar el ciclo
Acortar el ciclo es la palanca correcta, pero dos formas de acortarlo destruyen el programa en lugar de acelerarlo.
Acortar la recogida. Es la tentación obvia, porque la recogida es la mayor porción contigua del ciclo. También es la única porción que produce dato. Cortar la recogida de 14 a 8 días aumenta la cadencia en el papel y derriba el poder del test, lo que aumenta la tasa de victoria aparente mientras reduce la proporción de victorias reales. Las otras tres etapas pueden comprimirse sin coste estadístico ninguno; esa no.
Construir antes de aprobar la hipótesis. Mantener la próxima variación lista es buena práctica, pero solo después de que la hipótesis, la métrica primaria y la duración estén escritas. Construir antes de eso invierte el orden: el equipo pasa a elegir la hipótesis que justifica la variación que ya existe, y el roadmap se convierte en una cola de cosas listas en lugar de una cola de preguntas.
Cómo hacer seguimiento sin volverlo una meta perversa
La velocidad es un indicador de medio, no de fin, y exhibirlo solo en un panel produce el comportamiento equivocado en pocas semanas: tests acortados para caber en el mes, hipótesis flojas para llenar el hueco, empates reclasificados como victoria. Tres cuidados lo evitan:
- Repórtalo siempre en par. Velocidad junto a la proporción de tests con hipótesis registrada antes de correr. Un número sube a costa del otro cuando el programa empieza a apurarse.
- Mide por año, no por mes. Con pocos tests en la ventana, un solo resultado mueve la media entera. La lectura anual es la única estable para quien corre menos de 20 tests por período.
- Separa techo de velocidad en el reporte. Son problemas diferentes con dueños diferentes: el techo es una conversación sobre tráfico y ambición de MDE, la velocidad es una conversación sobre proceso. Mezclar los dos hace que el equipo pida medios cuando el problema era la cola.
Para ordenar la cola que esa capacidad soporta, la plantilla de roadmap de experimentación ya trae la columna de duración estimada, que es el puente entre este cálculo y la planificación. Y para saber qué esperar de los tests que quepan, vale leer la tasa de victoria en tests A/B y lo que muestran los datos, porque cadencia multiplicada por una expectativa irreal de acierto produce una promesa que la matemática no sostiene.
Hazlo automático en Donnu
La mitad de esta plantilla es cuenta que la herramienta debería hacer sola. Donnu dimensiona cada test contra tu tráfico real y muestra la duración estimada antes de que empieces, lo que ya entrega el techo estadístico sin hoja de cálculo, y mantiene la duración fijada para que la etapa de recogida no se acorte a mitad de camino por una mirada al panel. Lo que le queda al equipo por medir son los días fuera de la recogida, que es exactamente donde está la ganancia de velocidad que nadie compra con medios.
Empieza una prueba gratis de 14 días y mira la duración de cada test antes de comprometer el trimestre. Para dimensionar la cadencia que tu tráfico aguanta, mira cuántos tests A/B deberías hacer por mes.
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.
- Thomke, S. Building a Culture of Experimentation. Harvard Business Review, marzo-abril 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
- 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.
- 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.
Lee también:
Preguntas frecuentes
- ¿Qué es la velocidad de experimentación?
- Es cuántos experimentos válidos concluye el equipo por unidad de tiempo, medida de punta a punta y no solo por el tiempo en que el test estuvo en producción. La distinción importa porque la mayor parte de la lentitud de un programa no está en la recogida de datos: está en los días de construcción, de espera por aprobación y de test terminado que nadie leyó. Un programa que corre tests de 14 días y entrega 10 experimentos por año tiene un problema de proceso, no de tráfico.
- ¿Cómo calcular la velocidad de experimentación?
- Son dos números y una división. El techo estadístico es 365 dividido por la duración de cada test, donde la duración es el mayor valor entre la muestra necesaria dividida por el tráfico diario y el piso de dos semanas. La velocidad real es 365 dividida por el tiempo de ciclo completo, que suma los días de construcción, de recogida, de lectura y de espera. El aprovechamiento es la razón entre las dos, y casi siempre queda muy por debajo del 100%.
- ¿Cuál es una buena velocidad de experimentación?
- La referencia útil no es un número absoluto, es tu propio techo. Un equipo que aprovecha el 70% de la capacidad que el tráfico permite va bien, incluso corriendo 12 tests por año; un equipo que aprovecha el 35% de un techo de 26 está perdiendo la mitad del programa en fricción que ningún aumento de tráfico resuelve. Compárate con tu techo antes de compararte con cualquier empresa.
- ¿Qué hacer cuando el cuello de botella es el tiempo de construcción y no el tráfico?
- Atacar la cola, no la duración de los tests. Las palancas que funcionan: mantener una variación ya construida esperando el hueco libre, estandarizar los cambios más frecuentes en componentes reutilizables, y separar la decisión de subir del fin de la recogida, definiendo la regla de decisión antes de empezar. Ninguna de ellas exige más tráfico, y las tres acortan el ciclo sin acortar el test.
- ¿Aumentar la velocidad de experimentación siempre aumenta el resultado?
- No. La velocidad multiplica la calidad de las hipótesis, así que duplicar la cadencia de un programa con hipótesis débiles 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 probadas mejora la métrica objetivo, un tercio queda neutro y un tercio empeora. Acelerar sin mejorar el origen de las hipótesis acelera principalmente los dos últimos tercios.
- ¿Con qué frecuencia recalcular la plantilla de velocidad?
- Una vez por trimestre para el techo estadístico, porque el tráfico y la tasa base cambian despacio, y en cada test concluido para el tiempo de ciclo, que es donde aparecen las mejoras. Registrar el tiempo de ciclo test a test es lo que transforma la plantilla de un diagnóstico único en un indicador que se puede seguir.