Español

Diseño de Experimentos que Supera la Revisión de las Partes Interesadas

Un equipo con el que trabajé realizó el trimestre pasado un A/B test sobre el color de un banner. Tres días. Alrededor de 200 usuarios por rama. El PM miró el Dashboard, vio p = 0.07 en la tasa de clics y escribió en Slack: "positivo en dirección, enviemos". Seis semanas después, la métrica principal era plana, el modelo de personalización de ML downstream había reentrenado silenciosamente con tráfico aleatorizado a nivel de sesión para un objetivo a nivel de usuario, y cuando el VP preguntó cuál había sido la hipótesis original, nadie pudo encontrarla.

Ese experimento tenía cuatro problemas apilados: tamaño de muestra insuficiente, sin cálculo de efecto mínimo detectable, unidad de aleatorización incorrecta y una lectura anticipada el día 2 que sesgó la decisión. Cada uno por sí solo habría anulado el resultado. Juntos produjeron una decisión confiada construida sobre nada.

Esta guía es el antídoto. Es el Playbook de diseño que hace imposible repetir esa historia. Aquel donde un PM, un líder de ingeniería y un VP escéptico pueden leer el documento de resultados y llegar a la misma conclusión que usted.

La Plantilla de Hipótesis

La mayoría de los experimentos fracasan antes de que se recopile cualquier dato porque la hipótesis no es falsificable. "Mejorar la experiencia de usuario." "Hacer que el checkout sea mejor." "Aumentar el engagement." Ninguna de estas puede ser incorrecta, lo que significa que ninguna puede ser correcta tampoco.

Una hipótesis que usted puede defender tiene cuatro partes:

  • Problema: el número específico que no le gusta, hoy, con una línea base.
  • Cambio previsto: lo que va a hacer, en una oración.
  • Métrica de éxito: el único número primario con el que lo evaluará.
  • MDE: el tamaño del efecto más pequeño que cambiaría su decisión de negocio.

Completada, se ve así:

La tasa de finalización de checkout es del 38% (línea base de 90 días, n aproximado de 1.2M sesiones). Agregar una barra de progreso de 4 pasos en el flujo de checkout reducirá el abandono después del paso de dirección. Métrica principal: tasa de finalización, medida por usuario, ventana de 14 días. MDE: 1.5 puntos porcentuales de incremento absoluto (4% relativo). Cualquier valor menor no justifica el costo de ingeniería.

Observe lo que la plantilla obliga a hacer. Usted se compromete con un número de línea base, de modo que no puede argumentar después del hecho que la métrica era diferente. Se compromete con una métrica primaria, de modo que no puede cambiar a una secundaria cuando la primaria decepciona. Se compromete con un MDE, de modo que no puede afirmar que un incremento de 0.3 pp "importa". Y el MDE está fundamentado en una decisión de negocio (el incremento más pequeño que realmente cambiaría lo que hace a continuación), no en una conveniencia estadística.

Rechace las hipótesis vagas desde el principio. Si una parte interesada dice "queremos probar un nuevo diseño para ver qué pasa", su trabajo es empujar hacia atrás: ¿qué número cambia, en cuánto, y por qué ese número importa? "Veamos qué pasa" es una pregunta de investigación, no un experimento.

Matemáticas de MDE y Tamaño de Muestra

Esta es la sección que, más que cualquier otra, le salvará de desplegar basura. Las matemáticas no son opcionales.

Para una prueba de dos muestras de proporciones con α = 0.05 (bilateral) y potencia estadística = 0.80, el tamaño de muestra por rama es aproximadamente:

n ≈ 16 × σ² / δ²

Donde σ² es la varianza de la métrica y δ es el tamaño del efecto absoluto que quiere detectar (su MDE). Para una métrica binaria como la conversión, σ² ≈ p(1 - p) donde p es la tasa de línea base.

Hagamos el ejemplo de checkout de principio a fin.

  • Tasa de finalización de línea base: p = 0.38
  • Varianza: σ² = 0.38 × 0.62 ≈ 0.2356
  • MDE: δ = 0.015 (1.5 puntos porcentuales absolutos)
  • δ² = 0.000225
n ≈ 16 × 0.2356 / 0.000225
n ≈ 16,755 por rama

Es decir, aproximadamente n = 17,000 usuarios por rama, n = 34,000 en total, para detectar de manera confiable un incremento de 1.5 pp en una línea base del 38% con el 80% de potencia estadística. Si el volumen diario de usuarios elegibles es de 5,000, eso es un mínimo de 7 días de prueba. Si quiere un MDE de 1 pp en cambio, el denominador cae aproximadamente 2.25 veces y necesita n de alrededor de 38,000 por rama, es decir, una prueba de unos 16 días.

Ahora vea el A/B test del banner de la introducción: 200 usuarios por rama, tasa de clics de línea base de alrededor del 8%. Varianza ≈ 0.074. Para detectar un incremento de 1 pp con el 80% de potencia estadística, n ≈ 16 × 0.074 / 0.0001 = 11,840 por rama. Ellos tenían 200. La prueba era matemáticamente incapaz de detectar el efecto que esperaban. El p = 0.07 que citaron no era una señal cercana a la significancia estadística; era ruido aleatorio en una muestra que no podría haber señalado nada.

Algunas notas prácticas:

  • El 16 en la fórmula proviene de (z_α/2 + z_β)² × 2 para α = 0.05, potencia = 0.80. Para el 90% de potencia use aproximadamente 21. Para α = 0.01 (Bonferroni-corregido para 5 métricas, por ejemplo), la constante sube aún más.
  • Para métricas continuas (ingresos por usuario, duración de sesión), use la varianza real de la muestra y tenga cuidado con las colas pesadas. Hacer cap o transformación logarítmica de la métrica es a menudo lo correcto; hágalo antes de ejecutar, no después.
  • El tamaño de muestra escala con 1/δ². Reducir el MDE a la mitad cuadruplica la muestra requerida. Por eso "simplemente corrámoslo más tiempo si no despega" es una fantasía.

Si su calculadora de tamaño de muestra dice que necesita 38,000 usuarios por rama y el equipo solo tiene 5,000 por semana, sus opciones son: ejecutar durante 8 semanas, aceptar un MDE mayor (y admitir que no puede detectar ganancias menores), o elegir un experimento diferente. No hay una cuarta opción donde las matemáticas se doblen.

Unidad de Aleatorización: Usuario vs Sesión vs Clúster

Elegir la unidad de aleatorización incorrecta es el asesino silencioso de los A/B tests. Obtendrá un valor p limpio sobre la pregunta equivocada.

La aleatorización a nivel de usuario es el estándar para la mayoría de los experimentos de producto. A un usuario se le asigna una variante la primera vez que accede al experimento, y permanece en esa variante para siempre (o al menos durante la ventana de la prueba). Esto es correcto cuando la métrica se calcula por usuario: retención, LTV, frecuencia de compra, tasa de retorno en 7 días.

La aleatorización a nivel de sesión asigna cada sesión de forma independiente. Esto funciona para métricas sin estado de sesión única, como el tiempo de carga de página o la conversión de una sola sesión en una landing page donde los usuarios no regresan. Se rompe gravemente cuando la métrica se acumula entre sesiones. Si aleatoriza un algoritmo de recomendación a nivel de sesión y mide la retención en 30 días, acaba de mostrar a un usuario tres experiencias de recomendación diferentes durante 30 días; está midiendo el promedio de A y B, no A vs B.

La aleatorización por clúster es para efectos de marketplace, red y sociales. Si la variante cambia cómo la oferta se encuentra con la demanda (un nuevo algoritmo de ranking en un marketplace, un cambio de feed que afecta lo que otros usuarios ven), no puede aleatorizar usuarios individuales. Estos se derraman en la experiencia de los demás. Aleatorice a nivel geográfico, a nivel de marketplace, o a nivel del clúster social. El costo es que su n efectivo cae al número de clústeres, no al número de usuarios, y su cálculo de tamaño de muestra necesita usar la varianza a nivel de clúster (que generalmente es mucho mayor que la varianza a nivel de usuario).

La pregunta diagnóstica: "Si asignara al usuario A al control y al usuario B al tratamiento, ¿puede el resultado del usuario A verse influenciado por la experiencia del usuario B?" Si la respuesta es sí, tiene interferencia y necesita aleatorización por clúster o un diseño de cambio de contexto.

El error de nivel de sesión del A/B test de apertura fue exactamente este. La tasa de clics es técnicamente una métrica de sesión, por lo que la aleatorización a nivel de sesión pasó el examen superficial. Pero el modelo downstream que reentrenó con los datos necesitaba señal a nivel de usuario. La unidad de aleatorización debe coincidir con la unidad de análisis, y ambas deben coincidir con la unidad de decisión.

Métricas de Protección

La métrica primaria le dice si el cambio funcionó. Las métricas de protección le dicen si rompió algo más.

Registre previamente entre dos y cuatro métricas de protección que no deben retroceder más allá de un umbral, incluso si la métrica primaria gana. Métricas de protección estándar:

  • Latencia (carga de página p95, tiempo de respuesta del API): muchas "victorias" lo son porque la nueva variante cargó más rápido, no porque el cambio haya sido bueno.
  • Tasa de errores (errores 5xx, errores de JavaScript del lado del cliente): un tratamiento que duplica la tasa de errores está desplegando un bug, independientemente de lo que haga la conversión.
  • Ingresos por usuario: si optimiza la tasa de clics y los ingresos por usuario caen, encontró una forma de hacer que la gente haga clic en cosas de menor valor. No despliegue.
  • Tasa de tickets de soporte: los cambios de UX que confunden a los usuarios aparecen aquí, no en la métrica de conversión.

El umbral importa. Un patrón común: "la métrica de protección no debe retroceder más del 1% relativo, o el experimento falla independientemente del resultado primario". Registre previamente el umbral. De lo contrario, cuando la latencia llegue un 2% más lenta, la conversación se convierte en "¿es realmente significativo el 2%?", y estará negociando consigo mismo.

El objetivo de las métricas de protección es detectar el experimento que ganó la métrica primaria pero perjudicó el negocio. Son la herramienta más subutilizada en el trabajo de DS, y el seguro más barato que puede contratar.

El Documento de Resultados

Misma estructura, siempre. El documento de resultados que supera la revisión tiene una página, es escaneable en 90 segundos y no tiene sorpresas en el apéndice. Aquí está la plantilla:

  • Hipótesis: un párrafo, la plantilla de cuatro partes arriba, escrita antes de que comenzara el experimento.
  • Diseño: unidad de aleatorización, objetivo de tamaño de muestra, MDE, métrica primaria, métricas de protección, asignación de tráfico.
  • Fechas y muestra: fecha de inicio, fecha de fin, tamaño de muestra real alcanzado por rama.
  • Resultado primario: estimación puntual, intervalo de confianza del 95%, valor p. Una línea.
  • Métricas de protección: tabla de métricas de protección con delta, IC y aprobación/falla vs el umbral registrado previamente.
  • Cortes de segmentos registrados previamente: la misma métrica, desglosada por los segmentos a los que se comprometió con anticipación.
  • Decisión: desplegar / no desplegar / iterar, con la justificación vinculada directamente al resultado.
  • Plan de reversión: si se desplegó, ¿cómo monitoreamos en producción y qué activa una reversión?

Lo que no está en el documento de resultados: cortes de segmentos post hoc presentados como hallazgos, reencuadramientos narrativos de la hipótesis, o decisiones "direccionales". Si un corte de segmento es exploratorio, etiquételo como exploratorio en una sección claramente marcada. El revisor debería poder identificar de un vistazo qué números fueron planificados y cuáles fueron exploratorios.

La disciplina es la plantilla. Cuando todos los experimentos de la organización usan el mismo documento de una página, los revisores dejan de tener que aprender el estilo personal de cada DS y comienzan a poder evaluar el trabajo realmente.

Por qué Fracasan la Mayoría de los Experimentos

Después de suficientes documentos de resultados, los modos de falla se agrupan en una lista corta:

  • Potencia estadística insuficiente. Las matemáticas del MDE no se hicieron, o se hicieron y se ignoraron. La prueba no podría haber detectado el efecto que se estaba afirmando.
  • Hipótesis poco clara. Sin predicción falsificable, sin métrica primaria comprometida, sin MDE. El experimento "tiene éxito" sin importar lo que digan los datos.
  • Unidad de aleatorización incorrecta. Nivel de sesión para una pregunta de nivel de usuario, o nivel de usuario para una pregunta de marketplace con interferencia.
  • Sin métricas de protección. La métrica primaria ganó, el equipo desplegó, la latencia retrocedió un 8%, y tres semanas después alguien nota que los ingresos están bajos.
  • Sin plan de reversión. El código se desplegó, el experimento se declaró terminado y nadie monitoreó producción. El cambio deriva y nadie puede atribuir la deriva al lanzamiento.
  • Confundido con otro lanzamiento. El experimento se ejecutó durante una campaña de marketing o una actualización de UI que afectó ambas ramas. El efecto estimado es el experimento más el factor de confusión, y no puede separarlos.

Cada uno de estos es prevenible en la fase de diseño. Ninguno es corregible después de la recopilación de datos.

Evitar el HARKing

El HARKing (plantear hipótesis después de conocer los resultados, por sus siglas en inglés) es la forma más común de autoengaño en la experimentación. El patrón: ejecutó una prueba en toda la base de usuarios, la métrica primaria fue nula, pero la variante se ve excelente para "usuarios en iOS en EE. UU. que llegaron a través de búsqueda pagada". Entonces eso se convierte en el titular.

El problema es puramente estadístico. Si divide sus datos en 20 segmentos, esperaría que uno de ellos alcance p < 0.05 por azar solo. Elegir el ganador después de mirar los 20 y presentarlo como un resultado confirmado es, matemáticamente, un fraude. Encontraría el mismo "efecto" en el lanzamiento de una moneda si cortara con suficiente finura.

La solución es el registro previo. Antes de que comience el experimento, anote:

  1. La métrica primaria.
  2. Los cortes de segmentos exactos que reportará (por ejemplo, usuarios nuevos vs recurrentes, móvil vs escritorio, los 3 principales mercados), y solo esos.
  3. Cualquier subgrupo al que se comprometa como análisis confirmatorio.

Cualquier hallazgo posterior va en una sección claramente etiquetada como "Exploratorio", con una nota de que los valores p no están corregidos para pruebas múltiples y que el hallazgo necesita un experimento de seguimiento para confirmarse. Nunca llame "significativo" al resultado de un subgrupo post hoc. Llámelo una hipótesis para la siguiente prueba.

La solución cultural es más difícil que la técnica. Cuando una parte interesada desesperadamente quiere una victoria y el corte post hoc la entrega, la presión de blanquearlo como un resultado confirmado es real. La disciplina del registro previo (anotar antes) es lo que le da la base para rechazarlo.

Disciplina ante las Lecturas Anticipadas

Aquí hay un número que sorprende a la gente: si revisa la significancia estadística de su A/B test todos los días durante dos semanas, su tasa de falsos positivos efectiva no es del 5%. Está más cerca del 14%. Tal vez más, dependiendo de qué tan agresivo sea al detener temprano.

La razón es el problema de las pruebas secuenciales. Una prueba t o z estándar está calibrada para una única mirada a los datos, después de que se recopila una muestra precomprometida. Cada mirada adicional es otra oportunidad para que el ruido aleatorio cruce el umbral. Si mira y se detiene, está eligiendo el momento más extremo de un paseo aleatorio y reportándolo como un resultado fijo.

Tiene dos opciones claras:

  1. Comprometerse con el tamaño de muestra. Calcule n, ejecute la prueba hasta alcanzar n, luego mire el resultado una vez. Sin Dashboards diarios que impulsen decisiones de detención/despliegue. Monitorear las métricas de protección por seguridad está bien; usar la métrica primaria para llamar al experimento anticipadamente no lo está.
  2. Usar un método de prueba secuencial. mSPRT (prueba de razón de probabilidad secuencial por mezcla), diseños secuenciales grupales con funciones de gasto de alfa, o métodos bayesianos correctamente implementados con priors informativos. Estos le permiten mirar con la frecuencia que desee con inferencia válida, al costo de un tamaño de muestra requerido ligeramente mayor para compensar.

Lo que no puede hacer es ejecutar una prueba de horizonte fijo, mirar diariamente y detenerse en el momento en que p cruce 0.05. Ese es el generador de falsos positivos más común en la experimentación de la industria, y es la razón por la que las "victorias desplegadas" rutinariamente no se replican cuando se miden correctamente después.

La solución es procedimental. Escriba la regla de detención en el documento de diseño. "Ejecutaremos para n = 17,000 por rama, aproximadamente 8 días, y leeremos una vez". Si el equipo no puede resistir el Dashboard, oculte la métrica primaria de la vista en vivo y solo muestre las métricas de protección. La disciplina es el diseño.

Conclusión

El documento de resultados que supera la revisión es aquel en el que las decisiones de diseño se tomaron antes de que comenzara la recopilación de datos. La hipótesis era específica. El tamaño de muestra fue calculado. La unidad de aleatorización fue justificada. Las métricas de protección fueron registradas previamente. Los cortes de segmentos fueron comprometidos de antemano. La regla de detención fue anotada.

Todo lo demás es narrativa. Y la narrativa está bien para la sección narrativa del documento de resultados, pero no puede ser la base de una decisión de despliegue.

La batalla que gana es la que se libra antes de la recopilación de datos. Invierta la hora en el documento de diseño. Es la hora más barata que gastará en todo el trimestre, y es la que decide si su experimento supera la revisión o se une silenciosamente a la pila de pruebas "positivas en dirección" que nadie puede reconstruir seis meses después.

Aprenda Más