Control y variant

Descripción

Con el problema de fondo ya claro —una correlación sola no prueba causa (lección 2)—, esta lección construye el vocabulario exacto de la solución: los dos grupos que forman todo A/B test. control es el grupo que sigue viviendo la experiencia de siempre, sin ningún cambio. variant es el grupo que recibe exactamente un cambio específico —y solo ese cambio— sobre la misma experiencia base. La comparación entre lo que le pasa a control y lo que le pasa a variant, durante el mismo periodo de tiempo, es lo único que puede aislar el efecto de ese cambio específico.

Esa frase en negrita —durante el mismo periodo de tiempo— no es un detalle menor. Es, junto con la aleatorización de la lección 4, una de las dos condiciones sin las cuales un A/B test deja de ser un A/B test y vuelve a ser, disfrazado con nombres nuevos, el mismo problema de correlación de la lección anterior.

Conexión con el módulo. Esta lección define el vocabulario (control, variant) que vas a usar sin cambios el resto del módulo y de la guía: la lección 4 explica cómo se decide quién va a cada grupo (al azar), la lección 5 formaliza qué asume el experimento sobre la relación entre ambos grupos (la hipótesis nula), y la lección 6 calcula la diferencia entre sus tasas (el lift). Sin control y variant bien definidos, ninguna de esas piezas tiene sobre qué apoyarse.

Una analogía: el ensayo clínico, ahora en detalle

Retomando el ensayo clínico de la lección 1: control es el grupo placebo —recibe una pastilla idéntica en apariencia, empaque, y forma de administrarla al medicamento real, pero sin el principio activo—. variant es el grupo tratamiento —recibe exactamente el medicamento que se está probando—. Fíjate en un detalle que se pierde fácil: la pastilla placebo no es "nada". Es una intervención cuidadosamente diseñada para que sea idéntica en todo excepto en la única variable que el experimento quiere aislar. Si el grupo placebo tomara una pastilla de un color distinto, o la tomara en un horario distinto al del grupo tratamiento, el experimento ya no estaría aislando el efecto del medicamento — estaría mezclando el efecto del medicamento con el efecto del color de la pastilla o del horario.

Lo mismo aplica, con la misma exigencia, a un A/B test de producto: control no es "lo que sea que pasaba antes"; es una experiencia específica y estable, corriendo al mismo tiempo que variant, e idéntica a variant en todo excepto en el cambio puntual que se está probando. Para Mercado: control es la página de producto de siempre, sin ningún carrusel de recomendaciones. variant es exactamente esa misma página de producto, con el mismo checkout, el mismo catálogo, la misma velocidad de carga —todo igual—, excepto por una cosa: el carrusel de recommendations aparece debajo de la descripción del producto.

Ejemplo trabajado: la especificación del experimento de recommendations

Antes de correr cualquier experimento, un equipo serio escribe su especificación completa —qué es exactamente control, qué es exactamente variant, y qué se mantiene idéntico entre ambos—. Para el lanzamiento de recommendations en Mercado, esa especificación se ve así:

Elemento	control	variant
Página de producto	Igual que siempre	Igual que siempre
Checkout	Igual que siempre	Igual que siempre
Catálogo de productos	Igual que siempre	Igual que siempre
Carrusel de recommendations	No aparece	Sí aparece, debajo de la descripción
Periodo de medición	Semanas 1-6 desde el lanzamiento	Semanas 1-6 desde el lanzamiento (el mismo)
Origen de los usuarios	Usuarios nuevos que entran esa misma semana	Usuarios nuevos que entran esa misma semana

La fila que merece la atención más cuidadosa es "Periodo de medición": ambos grupos corren exactamente en las mismas seis semanas, no una tras otra. Esa simultaneidad es la que elimina cualquier explicación alternativa relacionada con el tiempo —una campaña de marketing que arrancó esa semana, una temporada de rebajas, un cambio en el clima que afecta las compras— porque, si algo así ocurriera, afectaría a control y a variant por igual, ya que ambos existen en el mismo momento.

                    Semana 1   2    3    4    5    6
control  (sin reco)  ████████████████████████████    <- corre TODA la ventana
variant  (con reco)  ████████████████████████████    <- al MISMO TIEMPO que control

                     Ambos grupos, en paralelo, mismas 6 semanas.
                     Cualquier evento externo (marketing, temporada) los afecta
                     a los DOS por igual -- no puede explicar una diferencia
                     ENTRE ellos.

Compara ese diseño contra uno defectuoso, muy tentador porque parece más simple de implementar: medir checkoutConversionRate durante las seis semanas antes del lanzamiento de recommendations, y llamar a eso control; después medir las seis semanas después del lanzamiento, y llamar a eso variant.

                    Semana -6  -5   -4   -3   -2   -1  | 1    2    3    4    5    6
"control" (antes)   ████████████████████████████      |
"variant" (despues)                                    | ████████████████████████████

                     DOS periodos de tiempo DISTINTOS, uno seguido del otro.
                     Cualquier cosa que haya cambiado entre esos dos periodos
                     (temporada, precios, competencia, clima) queda mezclada
                     con el efecto de recommendations, sin forma de separarlas.

Este segundo diseño —comparar "antes" contra "después"— no es un A/B test, aunque a veces se le llame así por error. Es exactamente el mismo problema de la lección 2, con una capa nueva de disfraz: cualquier diferencia observada entre los dos periodos podría deberse a recommendations, o podría deberse a cualquier otra cosa que haya cambiado entre esas dos ventanas de tiempo —el fin de una temporada de rebajas, un cambio en la competencia, hasta el clima—. La única forma de descartar esas explicaciones alternativas es que control y variant corran al mismo tiempo, expuestos exactamente al mismo contexto externo, y difieran solo en la única cosa que el experimento quiere medir.

Errores comunes

Comparar dos periodos de tiempo distintos (pre/post) en vez de un A/B simultáneo. Qué pasa: un equipo mide checkoutConversionRate seis semanas antes del lanzamiento de recommendations, y otras seis semanas después, y presenta esa comparación como si fuera un A/B test. Por qué pasa: un diseño pre/post es más fácil de implementar —no hace falta ninguna infraestructura de asignación al azar, solo mirar el dashboard antes y después de una fecha—, y "antes vs. después" se siente intuitivamente parecido a "control vs. variant". Cómo detectarlo: control y variant no corresponden a la misma ventana de calendario. Cómo corregirlo: como en la especificación de hoy, control y variant deben correr simultáneamente, expuestos al mismo contexto externo; solo así una diferencia entre ellos puede atribuirse al cambio específico, y no a cualquier otra cosa que haya cambiado con el paso del tiempo.

Dejar que el usuario elija si entra a control o a variant. Qué pasa: en vez de asignar a los usuarios, el equipo pone recommendations detrás de un interruptor opcional en la configuración de la cuenta, y compara a quienes lo activaron (variant, por su propia decisión) contra quienes no (control, también por su propia decisión). Por qué pasa: dar la opción de activar o desactivar un feature se siente más respetuoso del usuario, y técnicamente parece más simple que armar un sistema de asignación. Cómo detectarlo: la decisión de a qué grupo pertenece un usuario la tomó el usuario mismo, no un sistema externo al azar. Cómo corregirlo: los usuarios que activan proactivamente un feature nuevo casi siempre son, de entrada, distintos de los que no lo hacen —más curiosos, más comprometidos, más propensos a comprar de todos modos—, así que cualquier diferencia observada podría deberse a ese sesgo de auto-selección, no al feature. La lección 4 desarrolla a fondo por qué la asignación tiene que ser al azar, y nunca una elección del usuario.

Definir variant de forma vaga, sin precisar exactamente qué cambia. Qué pasa: la especificación del experimento dice solo "variant tiene la nueva experiencia de producto mejorada", sin detallar qué componente específico cambió —¿es el carrusel de recomendaciones? ¿también se rediseñó el botón de "agregar al carrito" al mismo tiempo? ¿cambió algo en el checkout?—. Por qué pasa: al equipo le resulta más natural describir la experiencia completa nueva en términos generales ("la versión mejorada") que aislar, con precisión quirúrgica, cuál es el único elemento que distingue a variant de control. Cómo detectarlo: si le preguntas al equipo "¿qué, exactamente, ve un usuario de variant que no vea uno de control?" y la respuesta menciona más de un cambio, o es imprecisa sobre cuál, la especificación está incompleta. Cómo corregirlo: como en la tabla de hoy, cada fila de la especificación —salvo la del carrusel— debe decir explícitamente "igual que siempre" en ambas columnas. Un A/B test bien definido puede resumirse en una sola frase precisa: "variant es idéntico a control, excepto por [este cambio único]".

Ejercicios

Ejercicio 1 — Encuentra el defecto del diseño. Un compañero de equipo propone este diseño para medir recommendations: "midamos checkoutConversionRate en la app de iOS (que ya tiene el carrusel, lanzado el mes pasado) contra checkoutConversionRate en la app de Android (que todavía no lo tiene, se lanza el próximo mes)". ¿Qué problema de simultaneidad tiene este diseño, aunque los dos grupos corran "al mismo tiempo" en el calendario?

Ver solución

Aunque las dos mediciones ocurren en el mismo periodo de calendario, iOS y Android no son el mismo tipo de usuario — la población de cada plataforma puede diferir sistemáticamente en edad, poder adquisitivo, comportamiento de compra, o cualquier otra característica asociada a qué sistema operativo usan. Esto es, en esencia, el mismo problema que comparar dos periodos de tiempo distintos, mudado a comparar dos poblaciones distintas: cualquier diferencia observada entre iOS y Android podría deberse a recommendations, o podría deberse simplemente a que los usuarios de iOS y Android de Mercado son, de entrada, grupos distintos de gente. La simultaneidad temporal no es suficiente por sí sola; hace falta además que ambos grupos vengan de la misma población, asignados al azar dentro de ella — el tema exacto de la lección 4.

Ejercicio 2 — Completa la especificación. Usando el formato de la tabla de "Ejemplo trabajado" de hoy, escribe la fila que falta para esta situación: Mercado quiere probar, además del carrusel de recomendaciones, si cambiar el botón de "Comprar ahora" de azul a naranja mejora la conversión. ¿Debería esa prueba correr como parte del mismo experimento de recommendations, o como un experimento separado? Justifica con el vocabulario de esta lección.

Ver solución

Debería correr como un experimento separado, con su propio par control/variant (botón azul vs. botón naranja). Si se agregara el cambio de color del botón dentro del mismo variant que ya tiene el carrusel de recomendaciones, variant dejaría de diferir de control en una sola cosa —dejaría de ser "idéntico excepto por el carrusel"—, y cualquier diferencia observada en checkoutConversionRate ya no podría atribuirse limpiamente ni al carrusel ni al color del botón: los dos cambios quedarían mezclados, sin forma de saber cuál (o si ambos, o ninguno) causó el efecto. Esta es exactamente la razón por la que la especificación de un A/B test exige aislar un único cambio por experimento.

Ejercicio 3 — Diagnostica el diseño pre/post. Un reporte de Mercado dice: "en octubre, antes de recommendations, checkoutConversionRate era 3.0%; en noviembre, con recommendations ya activo para todos, subió a 3.9%. Conclusión: recommendations sube la conversión en 30% relativo". Usando el vocabulario de esta lección, ¿qué tipo de comparación es esta, y qué explicación alternativa —no relacionada con recommendations— podría explicar la subida de octubre a noviembre?

Ver solución

Es una comparación pre/post, no un A/B test: no existe un control corriendo al mismo tiempo que variant — todo Mercado pasó de no tener recomendaciones (octubre) a tenerlas (noviembre), sin ningún grupo comparativo simultáneo. Una explicación alternativa razonable: noviembre suele incluir eventos de temporada alta de compras (por ejemplo, promociones de fin de año que muchos mercados lanzan en esa época), que por sí solos podrían subir checkoutConversionRate sin que recommendations tuviera nada que ver. Sin un control simultáneo expuesto al mismo noviembre, es imposible separar el efecto de recommendations del efecto de la temporada — exactamente el problema que este diseño no resuelve, y que un A/B test real, con ambos grupos corriendo la misma ventana de tiempo, sí resuelve.

Resumen y siguiente paso

En esta lección definiste con precisión el vocabulario central de todo A/B test: control (la experiencia de siempre) y variant (la misma experiencia, con exactamente un cambio agregado), y la condición que hace que la comparación entre ambos signifique algo: que corran simultáneamente, expuestos al mismo contexto externo. Viste, con la especificación completa del experimento de recommendations, cómo se documenta esa exigencia en la práctica, y por qué un diseño "antes vs. después" —aunque tentador por más simple— no es un A/B test.

Antes de avanzar deberías poder: definir control y variant con tus propias palabras, explicar por qué la simultaneidad es una condición necesaria (no solo recomendable), y detectar cuándo una comparación que se presenta como "A/B" en realidad es un diseño pre/post disfrazado.

Todavía falta una pieza crítica que esta lección dejó pendiente a propósito: ¿cómo, exactamente, se decide qué usuario entra a control y cuál a variant? La lección 4 contesta esa pregunta con la herramienta que hace que todo lo anterior funcione: la aleatorización.

Recursos

• Optimizely, "A/B Testing" (glosario de optimización) — optimizely.com/optimization-glossary/ab-testing. Un resumen claro del framework control/variant (a veces llamado treatment en otras fuentes) y de los componentes de un experimento bien diseñado. En inglés.
• Ron Kohavi, Diane Tang y Ya Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing — experimentguide.com. El capítulo introductorio del libro define con el mismo rigor que esta lección la diferencia entre un experimento controlado real y un diseño pre/post, con ejemplos de casos donde ese error costó decisiones importantes. En inglés.
• Ron Kohavi y Stefan Thomke, "The Surprising Power of Online Experiments" (Harvard Business Review, sept-oct 2017) — hbr.org/2017/09/the-surprising-power-of-online-experiments. Incluye ejemplos reales de por qué comparar periodos de tiempo distintos llevó a conclusiones equivocadas en experimentos de gran escala. En inglés.