Calendario de experimentación trimestral.
Cuántos tests caben de verdad en un trimestre según el tráfico disponible, cómo se secuencian sin pisarse, y cómo se prioriza lo que no cabe.
Cuántos caben.
El número de tests que caben en un trimestre no lo pone la ambición del calendario. Lo pone el tráfico. Un test necesita una muestra mínima por variante para poder afirmar con confianza que lo que se ve es una mejora real y no ruido, y ese tamaño de muestra depende de cuánto tráfico elegible entra cada semana.
Cuanto más pequeña sea la mejora que se quiere poder detectar —el efecto mínimo detectable, o MDE— más muestra hace falta para verla con claridad. Detectar una mejora del 5% pide muchísima más muestra que detectar una del 30%, y esa relación no es lineal: baja el MDE a la mitad y la muestra necesaria no se duplica, se multiplica por cuatro. La fórmula exacta —con la conversión de partida, el nivel de confianza y la potencia estadística— vive en las fichas de significancia estadística y de efecto mínimo detectable del glosario; aquí importa la consecuencia práctica, no repetirla.
Y la consecuencia práctica es esta: la duración de un test es la muestra necesaria por variante, multiplicada por el número de variantes, dividida entre el tráfico elegible que llega cada día a esa página o a ese flujo. Con poco tráfico, un test necesita semanas para tener algo que decir; con mucho, puede cerrarse en días. El calendario del trimestre se construye a partir de ese número, no al revés.
| Tráfico elegible semanal | Tests bien alimentados por trimestre |
|---|---|
| Bajo (unos pocos miles de visitas) | 1-2, y solo en la parte del embudo con más tráfico |
| Medio (decenas de miles) | 3-5, repartidos por distintas páginas |
| Alto (cientos de miles) | 6 o más, con margen para tests secuenciales en la misma página |
Cómo se secuencian.
Con el número de tests que caben ya calculado, la pregunta siguiente es en qué orden y con qué solapes.
No compartir elemento
Dos tests que tocan el mismo botón o el mismo bloque de la misma página, a la vez, se contaminan entre sí: si el resultado sube, no se sabe cuál de los dos lo causó. Tests en páginas o audiencias distintas sí pueden correr en paralelo sin problema.
Semanas completas, no días sueltos
El comportamiento cambia entre un lunes y un domingo. Cortar un test a mitad de semana porque “ya parece significativo” mezcla el efecto que se busca medir con el efecto del día de la semana, y el resultado deja de ser fiable.
Un búfer entre el cierre y el siguiente test en la misma zona
Una o dos semanas de margen para analizar el resultado e implementar el ganador antes de lanzar el siguiente test sobre la misma zona de la página. Sin ese búfer, el efecto del test anterior —todavía asentándose— se mezcla con el del siguiente.
El backlog.
Casi siempre hay más ideas que plazas. La pregunta no es si sobran ideas, es con qué criterio se elige cuáles entran este trimestre.
El criterio de partida es el mismo ICE con el que se puntúa cualquier sesión de ideación —impacto, confianza y facilidad, multiplicados—, aplicado sobre el backlog de experimentos y no sobre una lista suelta de ocurrencias. Lo que queda fuera de las plazas del trimestre no se descarta: se queda en el backlog para la vuelta siguiente, con su puntuación ya hecha.
Con una salvedad importante. Si el calendario se llena solo con las ideas de mayor ICE, casi siempre gana la optimización marginal —fácil, de confianza alta, de impacto pequeño— y nunca entra la apuesta grande, de impacto alto pero confianza baja porque nadie la ha probado antes. Conviene reservar explícitamente una de cada cuatro o cinco plazas del trimestre para ese tipo de test, aunque su ICE puntúe por debajo de otras opciones más cómodas: es la única forma de que el programa de experimentación no se estanque optimizando siempre el mismo margen decreciente.
Un trimestre, repartido.
Trece semanas, con las reglas de arriba ya aplicadas: sin compartir elemento, sin cortar a mitad de semana, con búfer entre tests de la misma zona.
| Semanas | Qué corre |
|---|---|
| 1-3 | Test A en checkout (alta confianza, optimización) + Test B en home (apuesta grande, en paralelo por ser zona distinta) |
| 4 | Búfer: análisis e implementación del ganador de A y B |
| 5-7 | Test C en ficha de producto |
| 8 | Búfer: análisis e implementación |
| 9-12 | Test D en checkout, sobre la versión ganadora de A (misma zona, después del búfer) |
| 13 | Cierre del trimestre: análisis, actualización del backlog puntuado, planificación del siguiente |
Los errores.
Parar el test en cuanto «se ve significativo»
Mirar el resultado cada día y parar en el primer momento en que cruza el umbral de confianza —lo que se conoce como peeking— infla la tasa de falsos positivos muy por encima del 5% nominal. El tamaño de muestra se calcula antes de empezar, y el test corre hasta llegar a él.
Lanzar un test sin tráfico suficiente para el MDE que se busca
Un test mal alimentado no da un resultado impreciso: no da ningún resultado fiable, aunque el informe muestre un porcentaje de mejora. Es preferible probar un cambio más grande —con un MDE mayor, que pide menos muestra— que uno pequeño que nunca va a alcanzar significancia con el tráfico disponible.
Cambiar el test a mitad de camino
Ajustar el diseño de una variante mientras el test sigue corriendo invalida todo lo medido hasta ese momento. Si hace falta cambiar algo, el test se reinicia con la muestra a cero, no se continúa como si nada.
No dejar registro de lo que se aprendió al perder
Un test que no gana no es un test perdido si queda documentado por qué se esperaba que funcionara y por qué no lo hizo. Sin ese registro, el mismo tipo de idea vuelve a probarse dos trimestres después, con el mismo resultado.
Los casos.
Cada cifra corresponde a una empresa concreta y tiene su caso detrás, con el detalle de cómo se consiguió.
Glosario.
Definidos en el glosario, con su fórmula y su ejemplo. Por si hace falta llevárselos a una reunión interna.
