Planteamiento y contexto
Una organización de producto ejecuta cientos de pruebas A/B cada día. La plataforma asigna usuarios, registra la exposición, calcula métricas y monitorea la calidad. En el pasado, los experimentos sufrieron de asignaciones desiguales, desbalance en la proporción muestral (sample-ratio mismatch o SRM) y conclusiones inválidas causadas por inspecciones repetidas (peeking). Diseña el sistema desde la configuración del experimento hasta la revisión de decisiones, incluyendo retraso de datos, estadísticas, alertas y permisos.
Qué está evaluando el entrevistador
- Si el candidato clarifica la unidad de experimentación, el nivel de aleatorización, los planos de exclusión mutua y las definiciones de métricas.
- Si separa los eventos de asignación, activación (trigger), exposición y resultado (outcome).
- Si diseña comprobaciones de aleatorización, detección de SRM y alertas de calidad de datos.
- Si sabe que una prueba de horizonte fijo no puede inspeccionarse libremente y puede proponer métodos secuenciales o válidos en cualquier momento (anytime-valid).
- Si las alertas, la auditoría, las reejecuciones y las compuertas de lanzamiento (release gates) forman un flujo de trabajo unificado.
Preguntas clarificadoras para hacer primero
- ¿La aleatorización es por usuario, dispositivo, sesión o solicitud? ¿Pueden los experimentos ejecutarse de forma ortogonal?
- ¿Cuántos experimentos y usuarios se ejecutan diariamente, y cuáles son la latencia de las métricas y las ventanas de retención?
- ¿Cómo se declaran las métricas primarias, los guardrails y los efectos mínimos detectables?
- Tras un SRM o pérdida de datos de exposición, ¿se debe pausar el tráfico, invalidar la prueba o reejecutarla?
- ¿Quién puede inspeccionar las asignaciones, modificar las reglas de detención y aprobar un lanzamiento?
Una respuesta de 30 segundos
“Dividiría la plataforma en configuración y aleatorización, recolección de eventos, análisis y una compuerta de decisión. La asignación utiliza un hash estable para mapear usuarios a buckets y separa experimentos mutuamente excluyentes de los ortogonales. La ruta de eventos registra los estados asignado, activado, expuesto y de resultado. Los servicios de calidad comprueban continuamente la distribución de buckets y el SRM, mientras que el análisis utiliza métodos secuenciales o válidos en cualquier momento para el monitoreo y la detención. Cada decisión incluye versiones de datos, código y auditoría; una alerta de calidad bloquea el lanzamiento en lugar de convertirse únicamente en un mensaje de chat.”
Respuesta detallada paso a paso
1. Definir los límites del experimento y la aleatorización
La configuración incluye ID de experimento, versión, unidad, división de tráfico, plano de exclusión mutua, métricas objetivo, guardrails, efecto mínimo detectable y reglas de detención. El hash utiliza una clave de unidad estable y una semilla de experimento para que un usuario no cambie de variante por solicitud. Las pruebas mutuamente excluyentes comparten un plano; las pruebas ortogonales utilizan planos separados y registran la política de colisiones.
2. Separar los eventos de asignación de los de resultado
Registrar únicamente la conversión no puede demostrar que un usuario vio la variante. Los eventos deben incluir asignación, activación, exposición y resultado con la versión del experimento, la variante, la marca de tiempo, un hash anónimo de la unidad y la fuente. Aplica control de versiones al esquema de eventos, permite eventos tardíos dentro de una ventana de recálculo y deduplica mediante una clave de idempotencia.
{
"experiment": "checkout-copy-v3",
"experimentVersion": 7,
"unitHash": "u_8f2c",
"variant": "treatment",
"event": "exposure",
"eventTime": "2026-08-01T12:00:03Z",
"schemaVersion": 2,
"idempotencyKey": "u_8f2c:checkout-copy-v3:7:exposure"
}Los eventos inmutables y los identificadores de versión conectan la asignación con el análisis, de modo que cambiar la configuración no pueda reinterpretar datos históricos.
3. Monitorear la aleatorización y el SRM
Las comprobaciones de aleatorización comparan la distribución de buckets con la esperada. Las comprobaciones de SRM comparan las muestras activadas observadas contra la proporción configurada. Inspecciona tanto el nivel asignado como el activado, ya que la elegibilidad, las versiones del cliente o la instrumentación pueden introducir sesgos solo después de la asignación. Las alertas deben distinguir entre retrasos transitorios de datos, defectos reales de asignación y cambios de tráfico, conservando a la vez segmentos de diagnóstico.
4. Manejar la observación continua y la detención
Una prueba de horizonte fijo que se revisa a diario y se detiene cuando resulta significativa infla el error de Tipo I. Utiliza métodos secuenciales por grupos, SPRT o secuencias de confianza válidas en cualquier momento, y registra límites, alfa, beta, MDE y tiempos de observación en la versión del experimento. Un product owner que observe una ventaja no puede saltarse la compuerta estadística; la falla de un guardrail o el cruce de un límite de seguridad debe detener el tráfico primero.
5. Diseñar rutas de streaming y por lotes (batch)
Una ruta de streaming consume eventos tipo Kafka y actualiza las alertas de calidad de asignación y latencia de datos en cuestión de minutos. Una ruta por lotes deduplica, repara datos tardíos, calcula segmentos y produce el informe final. Ambas comparten esquemas, versiones de experimentos y definiciones de métricas. Los resultados de streaming son provisionales; solo una marca de agua (watermark) por lotes los convierte en evidencia para el lanzamiento.
6. Conectar las decisiones con la auditoría y las compuertas de lanzamiento
Los estados del experimento incluyen borrador, en ejecución, pausado, inválido, concluido y archivado. Cambiar una semilla, métrica o regla de detención crea una nueva versión y congela el resultado anterior. El servicio de decisiones emite la marca de agua de datos, el método, el tamaño de la muestra, el estado de SRM, el estado de los guardrails y enlaces de auditoría. El lanzamiento solo acepta una versión concluida cuyas comprobaciones de calidad hayan pasado.
Respuesta de muestra de alta calidad
“Primero fijaría la unidad de aleatorización y la versión del experimento, para luego separar los eventos de asignación, activación, exposición y resultado. La aleatorización utiliza un hash estable y planos de exclusión mutua u ortogonales. La canalización de eventos utiliza versiones de esquema y claves de idempotencia para duplicados, datos tardíos y reejecuciones. Los servicios de calidad comprueban la distribución de buckets y el SRM en los niveles asignado y activado, y exponen segmentos para el análisis de causa raíz. Las pruebas de horizonte fijo no pueden verse comprometidas por inspecciones arbitrarias, por lo que el análisis utiliza métodos secuenciales o válidos en cualquier momento y registra límites y tiempos de observación. Los datos en streaming impulsan las alertas, mientras que una marca de agua por lotes genera el informe. Las decisiones portan versiones de configuración, código, datos y auditoría; un fallo de SRM, la falta de exposición o el incumplimiento de guardrails bloquean el lanzamiento.”
Errores comunes
- Almacenar solo las métricas finales → la pérdida de asignación o de exposición se vuelve invisible → conserva asignación, activación, exposición y resultado.
- Aleatorizar cada solicitud en lugar de cada usuario → un usuario ve múltiples variantes → utiliza una clave de unidad estable y una semilla.
- Revisar valores p diariamente y detener anticipadamente → el supuesto de horizonte fijo se rompe → utiliza métodos secuenciales o válidos en cualquier momento.
- Calificar el SRM como un resultado de significancia del desenlace → una proporción anormal puede invalidar la prueba → pausa las decisiones y diagnostica la asignación y la elegibilidad.
- Impulsar el lanzamiento directamente desde datos en streaming → eventos tardíos y duplicados pueden reescribir las conclusiones → exige una marca de agua por lotes y una compuerta de lanzamiento.
Preguntas de seguimiento y respuestas
¿Por qué comprobar tanto las muestras asignadas como las activadas?
La asignación puede ser uniforme mientras que solo los usuarios elegibles que llegan a la página activan la prueba. La lógica de elegibilidad, las versiones de cliente, los interceptores o la pérdida de eventos de exposición pueden distorsionar la proporción activada. Ambos niveles permiten distinguir un defecto de aleatorización de un defecto en la ruta de exposición.
¿Cómo das soporte a pruebas mutuamente excluyentes y ortogonales?
Las pruebas mutuamente excluyentes comparten un plano de tráfico y una semilla, por lo que un usuario solo entra en una prueba dentro de ese plano. Las pruebas ortogonales utilizan planos separados y pueden combinarse, pero la plataforma registra una matriz de colisiones y deshabilita combinaciones riesgosas.
¿Qué resuelve un método válido en cualquier momento (anytime-valid)?
Permite el monitoreo continuo y la detención dependiente de los datos, al tiempo que proporciona un control de errores uniforme en el tiempo. La plataforma sigue declarando el efecto objetivo, la potencia, los guardrails y la pérdida de negocio; las métricas arbitrarias y los motivos de detención discrecionales no se convierten en garantías estadísticas.
¿Debería una falla de SRM activar una reejecución automática?
Primero congela la decisión y conserva los datos sin procesar. Segmenta por tiempo, cliente, país, elegibilidad y plano para encontrar la causa. Reejecuta únicamente después de corregir la asignación o la instrumentación y de que el product owner acepte una nueva ventana de análisis; las reejecuciones automáticas no deben ocultar un experimento inválido.