# Qué puede responder un A/B test y qué no

*Experimentación · Fundamentos · 17 min · Curso: Experimentación y A/B testing*

Un A/B test contesta una pregunta muy concreta y la contesta muy bien. El problema es que solemos hacerle otra. En esta lección vas a aprender a escribir la pregunta exacta que tu experimento puede responder (qué cambio, para quién, en qué métrica, durante cuánto tiempo y frente a qué), a elegir qué se sortea, a separar tu hipótesis de producto de las hipótesis estadísticas y a reconocer cuándo el test no es la herramienta.

## En 60 segundos

Un A/B test sortea a personas entre la versión actual y una nueva para estimar cuánto cambia, de media, una métrica por culpa del cambio. Importa porque es la única forma limpia de separar tu cambio de la estacionalidad o del tipo de usuario que lo elige, pero contesta una pregunta mucho más estrecha que la que suele hacerle el negocio. La idea clave: escribe la pregunta en cinco piezas (cambio, población, métrica, periodo y comparación), elige bien qué se sortea y deja por escrito lo que el test no va a responder.

## Al terminar sabrás

- Reescribir una petición vaga de negocio como la pregunta de un experimento con cambio, población, métrica primaria, periodo y comparación.
- Elegir la unidad de aleatorización de un test justificando la interferencia y la potencia que implica.
- Clasificar las preguntas de una revisión de producto entre las que un A/B test responde y las que necesitan otro método, proponiendo cuál.

## Desde cero

Un experimento controlado reparte a la gente al azar entre la versión actual de algo (control) y una nueva (tratamiento) y compara qué hace cada grupo. Como el reparto es por sorteo, la única diferencia sistemática entre grupos es la versión que vieron.

Es como una cata a ciegas de dos cafés en la oficina: si tú eliges a quién das cada taza, darás el bueno a los que ya sabes que les gusta fuerte. Si lo decide una moneda, la cata te dice qué café gusta más a esa oficina, esa mañana. No te dice por qué, ni si gustará en la oficina de al lado, ni si a los tres meses se cansarán.

## La pregunta exacta que contesta un A/B test

Martes, planning. Laura, de Ventas, entra con una petición clara: «queremos saber si el botón nuevo del checkout va a subir los ingresos». Alguien dice «lo testeamos» y la conversación sigue. Parece resuelto y no lo está, porque un A/B test no responde a esa pregunta. Responde a otra, más estrecha y más útil.

Un experimento controlado estima el **efecto causal medio** de un cambio concreto: cuánto cambia, de media, una métrica entre quienes reciben la versión nueva frente a quienes reciben la actual, para una población, un periodo y una forma de medir. Fuera de esas fronteras, el test calla. Por eso la pregunta se escribe con cinco piezas:

1. **El cambio**: qué ve exactamente el grupo nuevo. No «el botón nuevo», sino «el botón dice Pagar 34,90 € en lugar de Continuar».
2. **La población elegible**: quién entra en el sorteo. ¿Todos, solo quien llega al checkout, solo móvil?
3. **La métrica primaria**: qué número decide, con numerador, denominador y ventana.
4. **El periodo**: tres semanas de octubre no son tres semanas de diciembre.
5. **La comparación**: casi siempre, lo que hay hoy. Si comparas dos versiones nuevas entre sí, no sabrás si alguna supera a la actual.

Con las cinco piezas, la petición de Laura se convierte en algo así: «para los usuarios de móvil que llegan al checkout, ¿mostrar el importe en el botón cambia la proporción que completa el pedido en 7 días, frente al botón actual, durante tres semanas de octubre?». Han desaparecido los ingresos del año, otros mercados y el porqué. Importan, pero esta pregunta no los contesta, y decirlo antes te ahorra la discusión de después.

> Si no puedes escribir las cinco piezas en dos líneas, tienes una idea, no un experimento. Enséñaselas a quien pidió el test antes de lanzarlo: la mitad de los malentendidos mueren ahí.

## Control, tratamiento y por qué el azar hace el trabajo

El **control** es el grupo que ve la versión actual; el **tratamiento** (o variante) es el que ve la nueva. La palabra importante no es ninguna de las dos: es **aleatorización**, que la suerte, y no tú ni el usuario, decida quién cae en cada grupo.

¿Por qué tanto empeño en el azar? Imagina que activas el botón nuevo a quien lo pida desde ajustes. Los que lo piden son más curiosos y más fieles: compran más, pero ya compraban más antes. Comparar a quien elige una feature con quien no es comparar a dos tipos de personas. Eso es **sesgo de selección**, y explica por qué tantos «los usuarios que usan X retienen el doble» acaban en nada cuando alguien empuja X.

Si una moneda decide, los dos grupos se parecen en lo que puedes medir (país, antigüedad, gasto) y en lo que no (ganas de comprar, prisa). Nada se cuela de forma sistemática en un lado. Lo único que distingue a los grupos, salvo el azar, es la versión que ven.

Esa coletilla, «salvo el azar», es la que da trabajo a la estadística. Sin ningún efecto real, dos grupos sorteados nunca salen idénticos: uno tendrá un 10,2 % de conversión y el otro un 9,9 %. Las próximas lecciones miden ese ruido y deciden si una diferencia lo supera. La idea de hoy: la aleatorización convierte «¿fue el cambio u otra cosa?» en «¿fue el cambio o la suerte?», y la segunda sí sabemos contestarla.

> Comprueba primero que el sorteo funcionó. Si pediste 50/50 y el reparto se aleja más de lo esperable, hay un **SRM** (sample ratio mismatch): el resultado no se interpreta, se investiga.

## La unidad de aleatorización: qué sorteas

La **unidad de aleatorización** es lo que lanzas a la moneda: una persona, una cuenta, una sesión, una ciudad. Parece un detalle técnico y es una decisión de producto, porque define qué efecto puedes medir y qué contaminación aceptas.

| Unidad | Cuándo tiene sentido | Riesgo si te equivocas |
| --- | --- | --- |
| Usuario | La mayoría de cambios de interfaz y de flujo | Sin login, ve las dos versiones desde dos dispositivos |
| Cuenta o empresa | Features colaborativas en B2B (estilo Holded, hipotético) | Por usuario, dos compañeros ven cosas distintas |
| Sesión | Cambios invisibles de rendimiento o ranking | La misma persona ve versiones distintas |
| Ciudad o zona | Marketplaces con oferta compartida (estilo Glovo, hipotético) | Tienes 20 unidades, no 2 millones: poca potencia |
| Franja horaria (switchback) | Precio o asignación que afectan a todo el mercado | Arrastre entre franjas sin tiempo de transición |

Dos reglas. La primera: **la unidad tiene que ser al menos tan grande como la interferencia**. Si lo que haces a un usuario afecta a otro (comparten repartidores, se invitan, trabajan en la misma empresa), sortear por usuario mide un efecto que no existirá al lanzarlo a todos. La segunda: **analizas en la misma unidad que sorteas**. Si sorteaste 20 ciudades, tienes 20 observaciones aunque dentro haya dos millones de pedidos; tratar los pedidos como independientes fabrica una precisión falsa.

Y una distinción que casi nadie escribe: **asignado frente a expuesto**. Si asignas a todo el que abre la app pero solo el 15 % llega al checkout, el efecto se diluye entre un 85 % que nunca vio nada. Asigna lo más cerca posible del punto donde el cambio se ve y registra la exposición ahí.

## Hipótesis con mecanismo, y las dos hipótesis de la estadística

En experimentación conviven dos cosas que se llaman igual y no lo son. La **hipótesis de producto** es tu teoría de por qué el cambio debería funcionar: un mecanismo. Las **hipótesis estadísticas** son dos afirmaciones formales sobre la métrica que el análisis va a enfrentar.

Empieza por la de producto, que es la que enseña. Separa dolor, causa y mecanismo antes de la feature. Dolor: gente que abandona en el último paso. Causa sospechada: no sabe cuánto pagará y teme un recargo. Mecanismo: con el importe final en el botón, la duda desaparece justo cuando decide. Feature: el botón con el importe. Sin mecanismo, un positivo no se reutiliza y un negativo no dice qué falló.

Las estadísticas son más secas. La **hipótesis nula (H0)** dice que el cambio no mueve la métrica primaria: la diferencia real es cero. La **alternativa (H1)** dice que sí la mueve. El análisis mira si los datos son difíciles de explicar suponiendo H0: si lo son, la rechaza; si no, no la rechaza. Dos consecuencias:

- **Rechazar H0 no demuestra tu mecanismo.** Algo del cambio movió la métrica: tu teoría, o que el botón nuevo es más grande. Anota qué otras métricas movería tu teoría (menos vueltas al carrito, menos dudas en soporte) y míralas.
- **No rechazar H0 no demuestra que no haya efecto.** Quizá no hubo gente suficiente para verlo. «No significativo» no es «no funciona».

## Primaria y guardrails: qué decide y qué veta

La **métrica primaria** es la única que decide, pegada al mecanismo y capaz de moverse en el plazo del test: completar el pedido, no los ingresos a 90 días. Los **guardrails** pueden vetar la victoria; salen de preguntarte cómo podría el tratamiento ganar haciendo daño (un importe en el botón que no coincide con el cobro final sube las cancelaciones).

Y una tercera familia que casi nunca aparece en los briefs: las **métricas de validez**. Reparto entre grupos, proporción de exposición, errores de carga por variante. No deciden nada de producto; deciden si hay algo que leer.

## Lo que un A/B test no puede responder

La parte que más se olvida y más dinero ahorra. Las preguntas típicas de una revisión de producto:

| Pregunta | ¿La responde un A/B? | Qué usar en su lugar o además |
| --- | --- | --- |
| ¿El cambio mueve la métrica media en esta población? | Sí, para eso sirve | Dimensionar bien el test |
| ¿Por qué funciona (o no)? | Solo en parte, con métricas del mecanismo | Entrevistas y encuestas a los dos grupos |
| ¿Qué pasará en un año? | No, mide semanas | Un holdout (grupo que se queda sin el cambio) durante meses |
| ¿Qué pasa cuando lo tengan todos? | No si hay interferencia o equilibrio de mercado | Tests por ciudad, switchback, rollout por fases |
| ¿Le funciona a este cliente concreto? | No, estima efectos medios | Conversación con el cliente; datos de su cuenta |
| ¿Es la mejor idea posible? | No, compara solo lo que probaste | Discovery; un árbol de oportunidades |
| ¿Funciona mejor en tal segmento? | Solo si lo declaraste antes y tiene muestra | Un test nuevo centrado en ese segmento |
| ¿Debemos hacerlo, estratégicamente? | No | La estrategia; el test informa, no decide |

Dos escenas. Una app estilo Fintonic (hipotético) prueba enviar más avisos y la apertura sube en el test de dos semanas; tres meses después, parte de los usuarios ha desactivado las notificaciones y abre menos que antes. El test respondió bien a su pregunta y mal a la del negocio. Y un marketplace de reparto da prioridad a ciertos restaurantes: en el test venden más, pero al lanzarlo a todos los repartidores son los mismos y nadie gana. El «efecto» era tráfico robado al control.

> Antes de pedir un test: ¿qué tendría que ser verdad para que esta decisión cree valor y cómo lo sabría a tiempo? Si es «que funcione a un año» o «cuando lo tengan todos», el A/B de dos semanas no basta.

## Cuando no se puede testear

A veces aleatorizar es imposible, poco ético o inútil: un B2B con cien cuentas, una migración que no se da a medias, precios distintos a clientes comparables. Toca usar métodos con menos confianza causal y triangular:

- **Rollout por fases**: al 10 %, luego al 50 %, comparando con quien aún no lo tiene.
- **Test por ciudad** o holdout geográfico, con ciudades parecidas como control.
- **Diferencias en diferencias**: el cambio antes y después en el grupo tratado frente al de un grupo no tratado.
- **Serie temporal interrumpida**: si la tendencia se rompe justo con el cambio, descartando campañas y estacionalidad.
- **Entrevistas y fake doors** cuando necesitas saber si a alguien le importa, no cuánto.

Manda la reversibilidad. Una puerta de dos direcciones (deshacer en una tarde) admite menos evidencia. Una de una dirección (cambiar el precio a toda la base) exige más triangulación y una regla de salida escrita antes.

## Ejemplo trabajado: el botón del checkout

**Ejemplo: Una app de reparto estilo Glovo (hipotético) quiere mostrar el importe en el botón de pagar**

**Contexto.** Datos hipotéticos. De cada 100 usuarios que llegan al checkout en móvil, 62 completan el pedido. Soporte recibe muchas preguntas del tipo «¿cuánto me cobraréis al final?».

**Paso 1, la decisión.** Si el botón con importe mejora la finalización sin dañar cancelaciones, se despliega en todos los mercados el próximo trimestre; si no, se descarta.

**Paso 2, las cinco piezas.** Cambio: «Pagar 34,90 €» en lugar de «Continuar». Población: móvil, España, quien llega al checkout. Primaria: pedidos completados por usuario expuesto en 7 días. Periodo: tres semanas completas. Comparación: el botón actual.

**Paso 3, la unidad.** Usuario con sesión, asignado al llegar al checkout para no diluir. Sin interferencia razonable: tu botón no cambia el de nadie.

**Paso 4, las hipótesis.** De producto: la duda sobre el coste final frena el último clic. H0: la finalización es igual en los dos grupos; H1: es distinta.

**Paso 5, el resto de métricas.** Guardrails: cancelaciones en 2 horas y contactos a soporte por pedido. Validez: reparto 50/50 y exposición registrada al pintar el botón. Mecanismo: preguntas sobre el precio y vueltas al carrito.

**Paso 6, lo que NO responde.** Ni los ingresos anuales, ni México, ni por qué abandona un usuario concreto. Escrito en el brief, Ventas no espera otra cosa.

**La pregunta del experimento en el brief de la app de reparto estilo Glovo (hipotético), escrita dos veces.**

Versión débil: **«¿El botón nuevo sube los ingresos?»**

**Cambio:** botón nuevo en el checkout.

**A quién:** a todos los usuarios.

**Métrica:** ingresos, y ya veremos qué más.

**Duración:** hasta tener resultados.

Versión fuerte: **«¿Mostrar el importe en el botón cambia la finalización del pedido?»**

**Cambio:** «Pagar 34,90 €» en lugar de «Continuar».

**Población y unidad:** móvil, España, por usuario al llegar al checkout.

**Primaria:** pedidos completados por usuario expuesto en 7 días. **Guardrails:** cancelaciones y soporte.

**Duración:** tres semanas. **No responde:** ingresos anuales, otros mercados, el porqué.

Qué cambia de una a otra:

- La débil promete ingresos, que el test no puede medir en tres semanas; la fuerte usa una métrica pegada al mecanismo.
- «A todos» diluye el efecto; la fuerte asigna donde el cambio se ve.
- La fuerte declara lo que no va a contestar y evita la discusión del readout.

## Cómo lo piensan los referentes

**La aleatorización como fundamento de la inferencia** (Ronald A. Fisher, *The Design of Experiments*, 1935)

Fisher, que trabajaba con parcelas agrícolas, defendió que el sorteo es lo que permite calcular cuánto de una diferencia puede deberse al azar. Sin él, cualquier diferencia puede venir de cómo elegiste las parcelas; con él, el único rival de tu explicación es la suerte, que se puede medir. Cada A/B test de hoy descansa en esa idea.

Cuándo no usarlo: Cuando la unidad sorteada no es independiente de las demás (marketplaces, redes sociales, equipos), el sorteo por individuo ya no garantiza lo que Fisher prometía: tienes que subir de unidad o cambiar de diseño.

**Nuestra intuición sobre las ideas falla más de lo que creemos** (Ron Kohavi y Stefan Thomke, *The Surprising Power of Online Experiments (Harvard Business Review)*, 2017, https://hbr.org/2017/09/the-surprising-power-of-online-experiments)

Con casos de grandes tecnológicas, cuentan que muchas ideas que el equipo daba por buenas no mueven nada al probarlas, y que algunos cambios pequeños sí. Conclusión: la opinión del cargo más alto de la sala no sustituye a un experimento, y experimentar tiene que ser barato y de fiar.

Cuándo no usarlo: Su contexto es tráfico enorme. Con poco volumen, la cultura de «testearlo todo» produce tests que nunca concluyen; ahí la disciplina es saber qué no testear y aprender por otras vías.

## En el trabajo real

- **El experiment brief**: las cinco piezas, unidad, hipótesis, métricas y la línea «qué no responde», antes del primer ticket.
- **La revisión de diseño con Data**, de 30 minutos: unidad, interferencia y si cabe en el tráfico. Aquí mueren los tests que no deberían existir.
- **El registro de experimentos**: cada test con su pregunta y su resultado, también los que no salieron bien.
- **La conversación con quien pidió el test**, para pactar qué hará cada resultado antes de verlo.

## Errores comunes

- **Pedirle al test una pregunta que no contesta**: ingresos anuales a un experimento de tres semanas, el porqué a una diferencia de medias.
- **Comparar a quien elige una feature con quien no**, y llamarlo experimento. Es selección, no causalidad.
- **Sortear por usuario cuando hay interferencia**: features colaborativas, marketplaces, referidos. Mides un efecto que no existirá al lanzar.
- **Asignar y analizar a todos** cuando solo una fracción ve el cambio.
- **Saltarse el control del reparto** y leer resultados de un test con SRM.

## Junior, senior y VP: qué cambia

**Junior**
- Propone testear cualquier cosa que se discute
- Escribe «métrica: conversión» sin definirla
- Sortea por usuario por defecto
- Lee el resultado como respuesta a la pregunta original de Ventas

**Senior y VP**
- Pregunta qué decisión cambia el test y lo descarta si ninguna
- Escribe las cinco piezas y la línea de lo que no responde
- Elige la unidad por la interferencia y la potencia que puede pagar
- El VP añade cuándo hace falta un holdout largo o un método no experimental, y lo financia

## Cómo aparece en entrevistas

Pregunta tipo: «Una app de movilidad estilo Cabify (hipotético) quiere saber si mostrar el tiempo de llegada del conductor con más precisión aumenta las reservas. ¿Cómo lo testearías?».

- **Qué buscan:** la pregunta en cinco piezas, una primaria pegada al mecanismo (reservas confirmadas por búsqueda) y que detectes la interferencia: si el tratamiento reserva más, quita conductores al control.
- **La repregunta habitual:** «¿y la retención a seis meses?». Quieren oír que el test corto no la responde y que propongas un holdout pequeño durante meses.

## Cómo practicarlo

Toma el último cambio que tu equipo lanzó y escribe su pregunta en cinco piezas, con la línea de lo que no responde. Después, en el Product Gym, decide qué hacer con un test cuyo reparto no cuadra, y en el caso del CTA del checkout diseña el experimento completo.

## Puntos clave

- Un A/B test estima el efecto causal medio de un cambio concreto, en una población, una métrica, un periodo y frente a una alternativa; fuera de ahí, calla.
- La aleatorización hace que el único rival de tu explicación sea la suerte, que sí se puede medir.
- La unidad de aleatorización debe ser al menos tan grande como la interferencia, y se analiza en la misma unidad que se sortea.
- Rechazar H0 no prueba tu mecanismo y no rechazarla no prueba que no haya efecto.
- Escribe en el brief lo que el test no va a responder y cómo lo aprenderás si importa.

## Comprueba lo aprendido

**Dirección te pide «un A/B test para saber si el nuevo programa de fidelidad aumenta el valor del cliente a dos años». ¿Qué respondes?**

Que un A/B de semanas no mide el valor a dos años. Propondría un test corto con una métrica temprana pegada al mecanismo (frecuencia de compra a 30 días, por ejemplo) y, además, un holdout pequeño que se quede sin el programa durante meses para ver el efecto largo. Y lo dejaría escrito en el brief.

**Vas a probar en una herramienta B2B estilo Factorial (hipotético) un tablero de tareas compartido por equipo. Data propone aleatorizar por usuario porque «hay más muestra». ¿Qué decides?**

Aleatorizar por empresa o por equipo. Con asignación por usuario, compañeros del mismo equipo verían versiones distintas y la feature, que es colaborativa, no funcionaría como en el lanzamiento real. Pierdes potencia, así que hay que comprobar si con el número de cuentas el test puede detectar el efecto que importa; si no, rollout por fases.

**Tu test sale significativo a favor del tratamiento. Un compañero dice «queda demostrado que la gente abandonaba por miedo al precio». ¿Es correcto?**

No. Rechazar H0 dice que el cambio movió la métrica, no que tu mecanismo sea la razón. Para apoyar el mecanismo hay que mirar las métricas que esa teoría predice (menos consultas a soporte sobre el precio, menos vueltas al carrito) y, mejor, hablar con usuarios de ambos grupos.

## Glosario

- **Control / Treatment** (control / tratamiento): Grupo que ve la versión actual y grupo que ve la nueva.
- **Randomization** (aleatorización): Reparto por sorteo entre grupos, que equilibra lo que mides y lo que no.
- **Randomization unit** (unidad de aleatorización): Lo que se sortea: usuario, cuenta, sesión, ciudad o franja horaria.
- **Average treatment effect** (efecto causal medio): Diferencia media en la métrica entre tratamiento y control en la población elegible.
- **Selection bias** (sesgo de selección): Error de comparar grupos que se formaron por elección y no por sorteo.
- **Interference** (interferencia): Cuando el tratamiento de unos afecta a la métrica de otros, incluido el control.
- **Exposure** (exposición): Momento en que el usuario ve realmente el cambio; distinto de estar asignado.
- **Null hypothesis (H0)** (hipótesis nula): Afirmación de que el cambio no mueve la métrica; la que el análisis intenta rechazar.
- **Guardrail** (métrica de protección): Métrica cuyo empeoramiento veta una victoria en la primaria.
- **Holdout** (grupo reservado): Pequeño grupo que se queda sin el cambio durante meses para medir efectos largos.
- **Switchback** (alternancia por franjas): Diseño que alterna tratamiento y control por franjas de tiempo en todo un mercado.

## Fuentes

- [Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing](https://experimentguide.com/), Ron Kohavi, Diane Tang y Ya Xu, 2020 (EN)
- [The Surprising Power of Online Experiments](https://hbr.org/2017/09/the-surprising-power-of-online-experiments), Ron Kohavi y Stefan Thomke (Harvard Business Review), 2017 (EN)
- [Diagnosing Sample Ratio Mismatch in Online Controlled Experiments](https://www.exp-platform.com/Documents/2019_KDDFabijanGupchupFuptaOmhoverVermeerDmitriev.pdf), Aleksander Fabijan y otros (Microsoft), 2019 (EN)
- [SRM Checks](https://docs.statsig.com/stats-engine/methodologies/srm-checks), Statsig (documentación), s. f. (consultada en 2026) (EN)

## Relacionado

- [El reparto que no cuadra](https://productcasa.pro/app/gym/srm-reparto)
- [Un botón de checkout que gana el test y pierde dinero](https://productcasa.pro/app/casos/cta-checkout)
- [Experimentación y A/B testing](https://productcasa.pro/app/aprender/ab-testing-experimentation)
- [Desviación estándar y error estándar para PMs](https://productcasa.pro/app/aprender/desviacion-error-estandar)
- [Hypothesis testing sin humo: p-valor e intervalos de confianza](https://productcasa.pro/app/aprender/hypothesis-testing-p-valor)
- [Métricas como cadena causal](https://productcasa.pro/app/aprender/metricas-cadena-causal)
- [Experiment brief](https://productcasa.pro/app/templates/experiment-brief)

---
> Fuente: https://productcasa.pro/app/aprender/experimento-que-responde · ProductCasa, formación en product management en castellano · Actualizado: 2026-10-14