Cómo elegir las métricas correctas para evaluar tus test A/B
El éxito de tu producto depende de saber qué funciona realmente, no de lo que crees que funciona.
¿cómo sabemos si estamos midiendo lo correcto? ¿Qué hace que una métrica sea realmente valiosa?
Después de analizar cientos de miles de test A/B en Microsoft, identificaron seis propiedades clave que debe tener toda buena métrica de experimentación. Las han agrupado bajo el acrónimo STEDII:
Sensibilidad (Sensitivity)
Trustworthy (Confiabilidad)
Eficiencia (Efficiency)
Depurabilidad (Debuggability)
Interpretabilidad y Accionabilidad (Interpretability & Actionability)
Inclusividad y Equidad (Inclusivity & Fairness)
Veamos en detalle cada una de estas propiedades:
Sensibilidad: Detectar cambios reales cuando existen
Una métrica sensible tiene alta probabilidad de detectar un efecto cuando realmente existe. Cuando una métrica sensible bien potenciada no muestra movimientos estadísticamente significativos, podemos confiar en que no hay un efecto real del cambio que estamos probando.
Ejemplo práctico: Imaginemos que estamos probando cambios en la interfaz de nuestra aplicación. La métrica "usuarios activos mensuales" podría tardar meses en mostrar cambios, mientras que "sesiones por usuario" podría detectar variaciones mucho más rápidamente. La segunda métrica es más sensible y nos permite iterar con mayor velocidad.
Checklist de Sensibilidad:
¿Es pequeño el coeficiente de variación de las métricas clave?
¿Hay un porcentaje razonablemente alto de pruebas A/B con un cambio estadísticamente significativo en la métrica?
Confiabilidad: Medir lo que realmente importa
Las métricas no solo se utilizan para tomar decisiones informadas sobre el producto, sino que también ayudan a determinar los incentivos y las inversiones futuras. Una métrica poco confiable puede enviar a un producto por un camino equivocado.
Ejemplo práctico: El tiempo de carga de página (PLT) suele tener una distribución muy sesgada que encaja con una distribución de Pareto (la típica Long Tail con un. 80/20). Dada esta distribución el PLT promedio es una métrica deficiente para rastrear el objetivo, ya que la media es representativa principalmente en distribuciones Normales (Lo que se conoce como una campana de Gauss), pero una métrica como el percentil 95 o 99 del PLT es más adecuada cuando tenemos una distribucion de Pareto. Mejor aún sería una métrica que estime la proporción de cargas de página donde el PLT excede un umbral determinado.
Checklist de Confiabilidad:
¿Conocemos la forma de la distribución de los datos y nuestra métrica es representativa con ese tipo de distribución?
¿La métrica tiene datos faltantes, valores inválidos, bajas tasas de unión, datos duplicados o datos retrasados?
¿La métrica se alinea con su objetivo?
¿El valor de la métrica y su movimiento son consistentes con otras señales para el objetivo?
¿Existen problemas de sesgo de selección durante la generación, recopilación, transformación o definición de datos?
Eficiencia: Calcular métricas rápidamente y a escala
A medida que la experimentación crece en una organización, necesitamos calcular métricas para un gran número de test A/B. Por lo tanto, el tiempo, la complejidad y el costo para calcular las métricas deben ser manejables.
Ejemplo práctico: Una métrica como "proporción de usuarios activos mensuales" requeriría ejecutar un test A/B durante varios meses antes de poder calcularla. Alternativas mejores son métricas que actúan como proxies, como "días activos por usuario" o "sesiones por usuario", que pueden calcularse más rápidamente.
Checklist de Eficiencia:
¿Puede escalar el cálculo de esta métrica a medida que escalan las necesidades de experimentación de la organización?
¿Las fuentes de datos subyacentes se generan rápidamente y tienen un SLA (Acuerdo de Nivel de Servicio)?
¿La iformación que aporta la métrica proporcionan un buen retorno sobre el coste del cálculo de la métrica?
Depurabilidad: Entender por qué se mueve una métrica
La depurabilidad es esencial para poder entender por qué una métrica se está moviendo en un test A/B. Si la métrica empeora, la depuración debe ayudar a identificar la causa. Si mejora, debe ayudar a entender por qué mejoró.
Ejemplo práctico: Una métrica como "tasa de fallos de la aplicación" puede desglosarse por códigos de error, creando una familia de métricas de depuración como "tasa de fallos de la aplicación con código A" para cada código encontrado. Normalmente, un tratamiento (la versión B del test) aumentará los errores de un tipo particular; por lo tanto, dicho desglose puede identificar rápidamente la causa del movimiento de la métrica principal.
Checklist de Depurabilidad:
¿Existen métricas que desglosen, segmenten y descompongan la métrica principal para depurar un movimiento de métrica?
¿Existen herramientas para diagnosticar y reproducir una regresión en una métrica clave?
¿Existen herramientas para extraer información adicional importante necesaria para depurar una métrica?
Interpretabilidad y Accionabilidad: Entender y actuar sobre los datos
Para permitir las mejores decisiones informadas sobre el producto, una buena métrica debe ser fácil de entender y fácil de actuar por parte de todos los miembros del equipo, no solo por los más expertos.
Ejemplo práctico: En lugar de representar la distribución de vistas de página en un histograma que rastree la proporción de usuarios en buckets etiquetados como 1, [2,4), [4,8), etc., sería mejor representar la distribución acumulativa con buckets etiquetados como 1, [2,∞), [4,∞), [8,∞), etc. En esta representación, la pérdida en cada bucket tendría una interpretación inequívoca; una disminución en el bucket 1 siempre sería buena, mientras que una disminución en cualquier otro bucket siempre sería mala.
Checklist de Interpretabilidad y Accionabilidad:
¿Está claro por qué el cambio en una métrica es importante para los objetivos más amplios del producto?
¿Está claro para todos los miembros del equipo cuándo un movimiento de métrica es bueno o malo?
¿Está claro qué tipo de tratamientos (versión B del test) se pueden probar con la métrica?
Inclusividad y Equidad: Considerar a todos los usuarios
Aunque puede haber un pequeño conjunto de métricas principales que indiquen el éxito de un experimento, los experimentadores deben confiar en un conjunto holístico de métricas para asegurarse de que una decisión de producto sea inclusiva y justa.
Ejemplo práctico: Para un producto con una mezcla de usuarios intensivos y livianos, una métrica de "clics por usuario" generalmente aumenta con el aumento en la participación general con el producto; pero también podría aumentar debido a un aumento en la participación de usuarios intensivos, incluso cuando hay una caída en la participación de usuarios livianos. Tener múltiples métricas que coloquen diferentes pesos en las unidades de observación y las actividades puede proporcionar más información sobre la distribución de un movimiento de métrica.
Checklist de Inclusividad y Equidad:
¿Conoces los puntos ciegos de la métrica?
¿Tienes otras métricas o medios para cubrir esos puntos ciegos?
¿Tienes métricas para detectar casos donde un tratamiento tiene diferentes impactos en diferentes unidades de observación o actividades, por ejemplo para distintos tipos de usuarios?
¿Tienes un conjunto de buenos segmentos de uso para detectar daños a los segmentos más importantes y más vulnerables?
Conclusión
El marco STEDII proporciona una estructura sólida para definir y evaluar las propiedades de una buena métrica para cualquier test A/B. Cada una de estas propiedades es esencial y, juntas, se refuerzan mutuamente para garantizar un buen conjunto de métricas que permitan un análisis adecuado y decisiones de producto acertadas.