Pruebas de interfaz A/B
Introducción
Las pruebas A/B son un experimento controlado donde se comparan dos (o más) versiones de la interfaz en usuarios reales para entender qué versión resulta en mejores métricas de producto. El objetivo es reducir la incertidumbre en la toma de decisiones y mejorar la UX a través de cambios verificables en lugar de opiniones.
Cuando corresponda, pruebas A/B
Hay un objetivo medible (conversión, tiempo de acción, retención, NPS, velocidad de tarea).
El efecto esperado es inobjetable o puede variar por segmentos.
El riesgo de cambio es lo suficientemente alto como para justificar el experimento.
El tráfico permite recopilar rápidamente una muestra estadísticamente significativa.
Cuando es mejor no probar: microcopias en pantallas poco usadas, fiches con fuerte dependencia de red/social (desbordamiento de efectos), ediciones que requieren una larga formación de los usuarios.
Formulación de hipótesis
Plantilla:- Si cambiamos [X en la interfaz] para [Y-segmento/todos], entonces [Z métrica] cambiará a [dirección/magnitud] porque [causa conductual].
Ejemplo: Si se transfiere el CTA principal por encima de la línea de plegado y se reduce la forma de 6 a 3 campos, el CR de acción primaria crecerá un + 3-5% al reducir la fricción.
Métricas: objetivo y protección
Primary (principal): una clave, por ejemplo, la finalización de una secuencia de comandos/conversión de destino.
Segundo: profundidad de desplazamiento, CTR, tiempo de acción, errores, velocidad de página.
Guardrails (protectores): estabilidad de rendimiento (TTFB, LCP), devoluciones/denegaciones, quejas/revisiones, cumplimiento de los límites de notificación, disponibilidad.
Se recomienda fijar previamente el MDE (efecto mínimamente detectable), la ventana de observación y los criterios de éxito.
el Diseño del experimento
Aleatorización y unidad de análisis
Unidad de aleatorización: usuario (user_id), a veces sesión o organización (clúster).
Estratificación/bloqueo: por dispositivos/canales, si hay diferencias fuertes.
Desbordamiento (interferencia): evite cuando el comportamiento de un grupo afecta a otro (por ejemplo, listas/cintas compartidas). En tales casos, las pruebas de clúster.
Tamaño de muestreo y MDE (simplificado)
Aproximado: cuanto menor sea la conversión básica y menor sea el efecto, mayor será la muestra.
Para CR ~ 10% y MDE ~ + 5% de efecto relativo, a menudo se requieren decenas de miles de observaciones por variante.
Duración
Enfóquese en el ciclo completo de comportamiento de la semana + stock (generalmente 2-4 semanas) o hasta alcanzar la potencia programada. No detenga la prueba prematuramente.
Ramp-up (retirada gradual)
1-5% de tráfico (canario) → 10-25% → 50% → 100%, con vigilancia guardrails.
Calidad y validez de los datos
SRM (Sample Ratio Mismatch)
Compruebe que la distribución de tráfico real (A/B) coincide con la prevista (por ejemplo, 50/50). Desviaciones significativas = problema de inclusión/banderas/bots.
Identidad y dispositivo cruzado
Utilice un user_id estable; tener en cuenta los dispositivos cruzados, las cookies decay, la autorización más tarde en el embudo.
Bots y anomalías
Filtre patrones no naturales (clics de alta velocidad, agentes de usuario ausentes, referencias inválidas).
Estacionalidad y eventos
No ejecute pruebas para períodos «anormales» fuertes (vacaciones/ventas) a menos que este sea el objetivo de la prueba.
Análisis estadístico
Enfoque de frecuencia (clásico)
Fije el alfa (generalmente 0.05) y la potencia (generalmente 80%).
No «mire» cada horas sin ajustes - el riesgo de falsos positivos.
Para métricas/opciones múltiples, aplique ajustes (Bonferroni/Holm/Hochberg) o una jerarquía de métricas.
el acceso Bayesovsky
Evalúa la distribución de probabilidad de efecto y la probabilidad de superioridad de la variante.
Conveniente para monitorear en tiempo real y tomar decisiones «razonablemente bien».
CUPED/covariables
La reducción de la dispersión a través de covariables pre-testa (por ejemplo, la actividad de la semana pasada) → más rápido se alcanza la potencia.