Cómo Escribir una Hipótesis de Test A/B (Plantilla Gratis)

Una hipótesis de test A/B es la frase que conecta una evidencia con un cambio, un efecto esperado y la métrica que va a juzgar ese efecto. “Probemos y ya está” no es una hipótesis: es una apuesta que todavía no decidió qué está tratando de probar, ni cómo va a saber si lo probó. Esta guía entrega la plantilla exacta, dos ejemplos trabajados con números reales y el puente entre la hipótesis y el dimensionamiento del test.

Sin una hipótesis escrita, el test se convierte en un espejo: cualquier variación de número en el panel parece “confirmar algo”, porque nadie definió antes qué contaría como confirmación. Ese vacío es el que genera la mayor parte de los resultados que nadie consigue explicar seis meses después, cuando alguien pregunta “¿por qué ese cambio funcionó de verdad?” y la respuesta es solo un encogimiento de hombros.

Qué es una hipótesis de test A/B (y qué no es)

Una hipótesis sólida tiene cuatro piezas conectadas: la evidencia que motivó la idea, el cambio concreto que vas a implementar, el efecto que ese cambio debería causar y la métrica que va a decidir si el efecto ocurrió. Quita cualquiera de estas piezas y la frase deja de ser testeable.

Lo que no es una hipótesis:

• “Vamos a testear un botón más grande.” No dice por qué, ni qué cuenta como éxito.
• “Creo que el checkout está confuso.” Es un diagnóstico, no una predicción. Falta el cambio y la métrica.
• “Vamos a rediseñar toda la página y ver qué pasa.” Mezcla tantas variables que, incluso si la conversión sube, nadie va a saber qué pieza causó qué.

Si ya leíste la guía completa de test A/B, sabes que la hipótesis es el paso que separa “correr un test” de “correr un test que enseña algo”. Un test sin hipótesis escrita puede incluso declarar un ganador, pero no deja ningún aprendizaje reaprovechable para la próxima página.

La plantilla de hipótesis que funciona de verdad

La estructura más usada en equipos de CRO y producto sigue este orden: evidencia, cambio, efecto, métrica. Funciona porque te obliga a escribir la métrica primaria antes de ver cualquier dato, lo que cierra la puerta a elegir la métrica después, sobre la base de “dio victoria en algún lugar”.

Un ejemplo corto para fijar la estructura: “porque observé que el 40% de los usuarios abandona el formulario de registro en el campo de teléfono (dato), creo que hacer ese campo opcional (cambio) va a aumentar los registros completados (efecto), medido por la tasa de finalización del formulario (métrica)”. Nota que la frase ya entrega, gratis, la métrica primaria y la dirección esperada. Nadie necesita adivinar qué cuenta como victoria después de que el test termina.

Este es el mismo esqueleto usado en el pilar de test A/B y en el paso a paso de cómo correr un test desde cero, donde escribir la hipótesis es el paso 2, justo después de mapear el embudo y antes de diseñar la variación.

Los 3 ingredientes de una hipótesis sólida

Además de la estructura de la frase, una hipótesis solo es sólida si cada pieza pasa una prueba de calidad. Los tres ingredientes que separan una buena hipótesis de una vaga:

Ingrediente	Pregunta que valida	Señal de alerta
Evidencia real	¿Ese dato vino de analytics, grabación de sesión, encuesta o soporte, y no de una opinión?	“Creo que…” sin ningún número detrás
Cambio causal aislado	¿Se puede señalar exactamente qué elemento cambió, y solo ese?	Rediseño amplio, varios cambios juntos
Métrica primaria única	¿Existe una métrica, definida antes de correr el test, que decide sola el test?	Dos o más métricas “candidatas a ganadora”

Un detalle que suele pasar desapercibido: la evidencia no necesita ser un número grande de un informe de BI. Una grabación de sesión en la que cinco usuarios hacen clic en un elemento que no es clicable ya es evidencia cualitativa suficiente para justificar una hipótesis. Lo que no vale es saltar directo de la opinión a la variación, sin ningún dato en el medio.

Ejemplos trabajados: e-commerce y SaaS

Dos hipótesis completas, cada una anclada en un dato plausible para el contexto, con métrica primaria, secundaria y guardrail nombradas.

E-commerce: envío visible en la página de producto

Porque el análisis del embudo mostró que la mayor caída de visitantes ocurre entre “carrito” y “checkout”, y la encuesta de salida señala el costo de envío como motivo recurrente de abandono, creo que mostrar el valor del envío ya en la página de producto (en vez de solo en el checkout) va a reducir el abandono en esa etapa, medido por la tasa de finalización de compra.

• Métrica primaria: tasa de finalización de compra (visitantes que llegan al checkout y finalizan).
• Secundaria: tasa de adición al carrito, tiempo hasta el checkout.
• Guardrail: ticket promedio (el objetivo es convertir más, no empujar envío gratis a cualquier costo de margen).

SaaS: prueba social en el formulario de registro de trial

Porque el analytics muestra que la tasa actual de conversión de visitante a registro de trial es del 8% y la encuesta con usuarios que abandonaron cita “no sé si esta herramienta sirve para mi caso” como objeción recurrente, creo que agregar un sello con el número de cuentas activas y un testimonio corto al lado del formulario va a aumentar los registros de trial, medido por la tasa de conversión de visitante a trial iniciado.

• Métrica primaria: tasa de conversión de visitante a trial iniciado.
• Secundaria: tiempo hasta el inicio del llenado del formulario, tasa de campos abandonados.
• Guardrail: tasa de trial a pago (el cambio no puede atraer registros de baja intención que nunca convierten).

Nota que, en los dos casos, la métrica primaria es una sola cosa, escrita antes de correr cualquier test, y el guardrail existe justamente para detectar un efecto colateral que la métrica primaria sola no vería.

Dimensionando los dos ejemplos

Cada hipótesis anterior ya carga un efecto implícito, así que se puede calcular la muestra de cada una con el mismo motor de estadística de este sitio. Para la hipótesis de SaaS, con la tasa base de 8% y considerando que vale la pena detectar una mejora relativa de 20% (de 8% a cerca de 9,6%), el cálculo devuelve:

• Muestra necesaria: 4.921 visitantes por variación.
• Duración estimada: 23 días, para 3.000 visitantes por semana llegando a la página de registro.

Ya la hipótesis de e-commerce, con tasa base de 3% y un efecto relativo de 15%, necesita bastante más gente (el próximo H2 muestra la cuenta completa). La diferencia no es casualidad: tasas de conversión más bajas exigen muestras más grandes para el mismo efecto relativo, porque hay menos “eventos” de conversión para que el test vea en cada grupo de visitantes.

Priorizando tus hipótesis: ICE vs. PIE

Después de escribir varias hipótesis, no vas a testear todas al mismo tiempo. Dos frameworks ayudan a decidir el orden, dando una nota a cada eje en una escala combinada (generalmente 1 a 10) y sacando el promedio o la suma:

Framework	Ejes	Punto fuerte	Punto débil
ICE	Impacto, Confianza, Esfuerzo	Rápido de aplicar, bueno para backlog grande	Más subjetivo, depende de quién puntúa
PIE	Potencial, Importancia, Facilidad	Considera cuánto la página ya está optimizada y el volumen de tráfico	Exige más dato previo de cada página

Un ejemplo puntuado con ICE, usando las dos hipótesis anteriores más una tercera idea (rediseñar todo el checkout), cada eje de 1 a 10:

La guía completa de optimización de conversión detalla los dos frameworks con más profundidad y cuándo vale la pena cambiar de uno a otro. La regla práctica: elige un framework, aplícalo con la misma regla en todas las ideas del backlog y no recalcules la nota en medio del test solo porque el resultado parcial “parece bueno”.

Los equipos pequeños, con backlog corto, tienden a irles mejor con ICE: es rápido de llenar en una planilla y fuerza una conversación honesta sobre el esfuerzo de implementación. Los equipos con muchas páginas de alto tráfico, decidiendo dónde vale más la pena colocar la próxima hipótesis, suelen preferir PIE, porque el eje de “importancia” ya incluye el volumen de visitantes de esa página específica, y no solo cuánto la idea parece buena en el papel.

Errores comunes al escribir la hipótesis

Error	Por qué perjudica	Corrección
Hipótesis vaga	“Mejorar el botón” no dice qué cambia ni cómo medir	Escribe las cuatro piezas: evidencia, cambio, efecto, métrica
Testear varios cambios a la vez	Si el test gana, no sabes qué pieza causó el efecto	Aísla un cambio por hipótesis, o usa un diseño multivariado a propósito
Sin métrica primaria definida antes	Abre la puerta a elegir “la que dio victoria” después de ver los datos	Escribe la métrica primaria en la propia hipótesis, antes de correr el test
Escribir la hipótesis después de ver los datos	Se convierte en justificación, no en predicción; cualquier resultado “confirma” la hipótesis	La hipótesis se fija antes de que el test empiece, no después

Ese último error es el más silencioso. Equipos bajo presión de entregar resultados a veces corren el test primero y escriben la hipótesis “bonita” después, para el informe. El problema es que eso elimina lo único que la hipótesis debería hacer: forzarte a predecir un resultado antes de saber cuál fue.

De la hipótesis al test: dimensiona

Toda hipótesis carga, implícita o explícitamente, un tamaño de efecto. “Va a aumentar los registros” es vago; “va a aumentar los registros en al menos 15%” es un efecto mínimo detectable (MDE), y es ese número el que decide cuántos visitantes necesita el test. Una hipótesis sin MDE declarado tiende a correr por tiempo indefinido, sin criterio claro de cuándo parar.

Toma la hipótesis de e-commerce del ejemplo anterior: la tasa de finalización de compra actual (el dato que fundamenta la hipótesis) es del 3%, y el equipo considera que vale la pena detectar una mejora relativa de 15% (es decir, ir de 3% a cerca de 3,45%). Corriendo el motor de muestra de este sitio para ese escenario (95% de confianza, 80% de poder, test bilateral), el resultado es:

• Muestra necesaria: 24.193 visitantes por variación.
• Duración estimada: 43 días, considerando 8.000 visitantes por semana llegando a la página de checkout.

Ajusta la tasa base, el efecto que tu hipótesis promete y tu tráfico semanal para ver qué significa esto en tu caso:

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

Si el número de días parece demasiado alto para tu tráfico, tienes tres salidas honestas: aumentar el MDE (solo vale la pena testear cambios con efecto esperado mayor), aumentar el tráfico que llega a esa etapa (subiendo en el embudo), o aceptar que esa hipótesis específica va a llevar más tiempo. Lo que no vale es cerrar el test antes de la muestra calculada solo porque “ya se pudo ver una tendencia”: así es como nace un falso positivo. Para entender por qué pasa esto, mira la guía de significancia estadística en test A/B.

¿Y si el resultado confirma la hipótesis?

Vale la pena cerrar el ciclo con un número hipotético, solo para mostrar adónde lleva esa muestra. Si, al final del test de envío visible, el control hubiera convertido 960 de 12.000 visitantes (8,0%) y la variación, 1.104 de 12.000 (9,2%), el mismo motor estadístico de este sitio devolvería un valor p de aproximadamente 0,0009 y una mejora relativa de +15%, bien alineada con el efecto que la hipótesis predijo. Es ese cierre (hipótesis escrita antes, resultado leído después, sin cambiar la métrica en el medio del camino) el que transforma un test en aprendizaje reaprovechable, y no solo en otro número suelto en un panel.

Plantilla gratis y copiable de documento de hipótesis

Copia esta tabla para tu backlog de tests. Una fila por hipótesis, completada antes de que se escriba cualquier código:

Hipótesis	Cambio	Efecto Esperado	Métrica Primaria	Secundaria	Guardrail	Responsable	Inicio / Fin
Porque [dato], creo que [cambio] va a generar [efecto]	Qué exactamente cambia en la página	Dirección y magnitud mínima esperada (MDE)	La única métrica que decide el test	Lo que vas a observar, sin decidir por ello	Lo que no puede empeorar mientras la primaria mejora	Quién acompaña el test hasta el final	Fechas planificadas, definidas antes de empezar

Completar las ocho columnas antes de configurar la herramienta resuelve, de entrada, tres de los cuatro errores comunes de la sección anterior: hipótesis vaga, cambio no aislado y métrica elegida después de los hechos.

Hazlo automático en Donnu

Escribir la hipótesis es el trabajo fácil. Lo difícil es transformar esa frase en un test dimensionado correctamente, que nadie cierra demasiado pronto y que devuelve un veredicto honesto al final. Donnu conecta las dos puntas: registras la hipótesis y la métrica primaria, la herramienta calcula la muestra y la duración para tu tráfico real, recolecta con un snippet que nunca traba la página, y declara el ganador con estadística bayesiana, sin que mirar los datos antes de tiempo infle el falso positivo.

Comienza una prueba gratis de 14 días y lleva tu primera hipótesis del papel al resultado. Si todavía estás armando el embudo de test, mira el paso a paso completo de cómo correr un test A/B, y si quieres repasar los fundamentos antes, empieza por la guía de qué es un test A/B.

Lee también

• ¿Qué es un test A/B? La guía completa
• Cómo hacer un test A/B paso a paso
• Significancia estadística en test A/B
• Optimización de conversión (CRO): guía completa

¿Prefieres leer en inglés? Leer en inglés.

Referencias

• Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoyo en experimentguide.com.
• Miller, E. How Not To Run an A/B Test (por qué la métrica y la muestra deben fijarse antes de que el test empiece), 2010. evanmiller.org.
• CXL. Conversion Rate Optimization: guías y frameworks de priorización. cxl.com.
• VWO. The Complete Guide to A/B Testing. vwo.com/ab-testing.
• Optimizely. Experimentation y buenas prácticas de test A/B. optimizely.com.