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

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.

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.

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.

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:

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.

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

Cómo lo piensan los referentes

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

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.