La experimentación permite a empresas como DoorDash probar nuevas funciones entre un grupo limitado de usuarios para evaluar su éxito. Por ejemplo, podríamos probar a mostrar recomendaciones personalizadas de restaurantes en formato de cuadrícula en lugar de en formato de lista en nuestra aplicación. Si los datos muestran que a nuestro grupo experimental de clientes les gusta el formato de cuadrícula, podríamos extender esa función a toda nuestra base de usuarios. Estos experimentos también pueden realizarse en aspectos de la aplicación que no estén orientados al consumidor. Por ejemplo, experimentamos con diferentes algoritmos para asignar entregas a los Dashers y elegimos el mejor algoritmo basándonos en nuestras métricas internas, como el tiempo de entrega (tiempo que se tarda en completar una entrega) o el número de entregas completadas.
En un esfuerzo por obtener datos de la mayor calidad posible a partir de estos experimentos, hemos desarrollado Curie, nuestra nueva plataforma de análisis de experimentos. Curie estandariza nuestros procesos y resultados de análisis de experimentos y pone los datos a disposición de todas las partes interesadas.
Construido sobre una combinación de SQL, Kubernetes y Python para sus componentes principales, llamamos a Curie en honor a la famosa científica Marie Curie, en honor a sus experimentos en radiactividad. Curie está diseñada para estandarizar nuestros procesos de análisis de experimentos, incluidas las pruebas A/B, las pruebas Switchback y el análisis Diff-in-Diff. Esta plataforma nos ayudará a tomar decisiones basadas en datos a partir de los resultados de los análisis, validando la significación estadística (valor p) y los efectos del tratamiento en las métricas de interés.
Retos de la experimentación antes de Curie
Antes de Curie, los científicos de datos de DoorDash analizaban sus experimentos en su entorno local mediante consultas SQL o secuencias de comandos ad hoc. Este proceso llevaba mucho tiempo y era propenso a errores. También carecía de estandarización, ya que cada uno utilizaba diferentes métodos de análisis, lo que puede afectar a la calidad y precisión de los resultados. Al carecer de una plataforma centralizada, los resultados de los experimentos se dispersaban en forma de documentos o correos electrónicos.
Dados los diferentes tipos de experimentos que realizamos y la escala a la que crecían nuestros datos, era difícil encontrar una única herramienta que satisficiera todas nuestras necesidades. También queríamos aprovechar las herramientas de código abierto e integrarlas con nuestros datos y herramientas internas, incluidas las ACL y los flujos de trabajo.
Para hacer frente a los problemas anteriores, decidimos construir nuestra propia plataforma de análisis de experimentación para disfrutar de todas las ventajas del análisis automatizado. Diseñamos la plataforma para mejorar la precisión de los resultados de los experimentos utilizando metodologías estándar y científicamente sólidas propuestas por nuestro grupo de trabajo de experimentación. La plataforma de análisis también proporcionaría un entorno centralizado para mostrar los resultados de los experimentos y facilitaría compartirlos en toda la empresa. Los resultados de los experimentos se precalcularían y estarían disponibles para que los científicos de datos no tuvieran que esperar a que se completaran consultas de larga duración.
El ciclo de vida del experimento en DoorDash
Antes de entrar en detalles sobre Curie, veamos cómo se utilizará durante el ciclo de vida de un experimento en DoorDash. Como plataforma de análisis, Curie ingiere datos de los experimentos que hemos llevado a cabo y realiza análisis científicos de las métricas, un proceso que antes se realizaba mediante secuencias de comandos ad hoc, como se muestra en la Figura 1, a continuación:
La siguiente secuencia explica el ciclo de vida de un experimento A/B aleatorio sobre usuarios:
- El experimentador calcula el tamaño de la muestra necesaria para un experimento introduciendo la potencia deseada y el Efecto Mínimo Detectable (MDE). En este caso, el tamaño de la muestra será el número de usuarios, ya que estamos experimentando con usuarios. En este paso, el experimentador define la asignación de los usuarios entre el grupo de control (los usuarios que no ven la nueva función) y el grupo de tratamiento (los usuarios que están expuestos a la nueva función) en función de un criterio específico, como el país o el tipo de dispositivo. Inicialmente, empezamos con un pequeño número de usuarios en el grupo de tratamiento y, en función de los resultados preliminares del experimento, aumentamos gradualmente la asignación del tratamiento hasta que asignamos completamente a todos los usuarios al grupo de tratamiento.
- El experimentador también establece la configuración de análisis del experimento en la interfaz Curie basada en web (WebUI). Esta configuración incluye la lista de métricas que deben analizarse para este experimento.
- Cuando un usuario abre la aplicación DoorDash, se le agrupa aleatoriamente en la variación de control o de tratamiento en función de la proporción de asignación especificada en el primer paso.
- A continuación, nuestra infraestructura de instrumentación registra en el almacén de datos esta asignación de cubos junto con cierta información contextual (que denominamos eventos de exposición al experimento).
- Curie realiza el análisis utilizando las exposiciones y los datos métricos del almacén de datos y almacena los resultados en el almacén de datos.
- Los resultados del análisis estarán ahora disponibles en la WebUI de Curie. El experimento se ejecutará durante un periodo de tiempo hasta que alcancemos el tamaño de muestra necesario. El experimentador puede supervisar el análisis continuamente en Curie para confirmar que el experimento no tiene ningún efecto negativo en las métricas importantes.
Los componentes de Curie
Analicemos ahora la arquitectura de Curie. Curie es un sistema integral en el que varios componentes, como la interfaz de usuario web, los trabajadores, el motor de estadísticas y las definiciones métricas, funcionan conjuntamente para analizar experimentos y devolver los resultados al usuario, como se muestra en la Figura 2:
Definiciones métricas
Curie proporciona la máxima flexibilidad a los científicos de datos, permitiéndoles definir sus propias métricas. Los científicos de datos utilizan plantillas de consultas SQL para definir sus métricas en el repositorio de Curie, como se muestra a continuación:
with
exposures as (
SELECT
exp.BUCKET_KEY as user_id,
MIN(exp.RESULT) as bucket,
FROM PRODUCTION.EXPERIMENT_EXPOSURE exp
WHERE exp.EXPERIMENT_NAME = {{experiment_name}}
and exp.EXPOSURE_TIME::date between {{start_date}} and {{end_date}}
AND exp.EXPERIMENT_VERSION = {{experiment_version}}
group by 1
having count(distinct exp.RESULT) = 1
order by 1
),
SELECT exposures.*,
metric1,
metric2,
FROM exposures exp
LEFT JOIN metric_table metrics
ON metrics.user_id = exp.user_idGeneramos dinámicamente la consulta utilizando plantillas JinjaSQL vinculando los parámetros SQL con los valores de la configuración del experimento. El fragmento anterior representa la estructura de las plantillas SQL utilizadas para el análisis. Obtiene las exposiciones del experimento, es decir, el cubo asignado a los usuarios y las métricas de esos usuarios.
Como puede verse en la plantilla, todos los detalles del experimento, incluidos el nombre del experimento, la versión del experimento y el intervalo de fechas del experimento, están parametrizados y se sustituirán por los valores de la configuración de Curie. La parametrización de los detalles específicos del experimento en las definiciones de métricas permite a los científicos de datos reutilizar una única consulta SQL para múltiples experimentos ejecutados por su equipo, ya que la mayoría de los equipos supervisan un conjunto similar de métricas para todos sus experimentos.
We consider use of these templates as the first step in centralizing all the company's important metric definitions. There is currently an ongoing effort to standardize these metric definitions and create a metrics repository that can allow data scientists to create and edit individual metrics and reuse them across different experiments and teams.
Trabajadores de Curie
Tenemos un conjunto de trabajadores, cada uno compuesto por un pod de Kubernetes con las restricciones de recursos necesarias, que ejecutan el análisis real de todos los experimentos. Todas las mañanas se programa una tarea cron que activa estos trabajadores añadiendo las tareas a la cola de tareas (como se muestra en la figura 2).
Una vez que un trabajador recibe una tarea, obtiene las exposiciones del experimento y los datos métricos necesarios para el análisis del almacén de datos y realiza el análisis utilizando nuestro motor de estadísticas Python. A continuación, los resultados se almacenan en un almacén de datos PostgreSQL con la indexación adecuada para su visualización en la WebUI de Curie.
También ofrecemos flexibilidad para que los usuarios activen el análisis del experimento en cualquier momento, lo que resultó ser una característica muy útil, ya que los usuarios no querían esperar a que el programa cron validara sus resultados. Por ejemplo, si había un error en la consulta SQL utilizada por el cron, el usuario podía querer corregir la consulta y ver los resultados inmediatamente.
Motor de estadísticas en Python
Disponemos de una biblioteca de estadísticas en Python desarrollada por nuestros científicos de datos para analizar las métricas de los experimentos. Esta biblioteca analiza diferentes tipos de métricas:
- Métricas continuas, que tienen un valor numérico continuo, por ejemplo, el tiempo total de entrega.
- Métricas proporcionales con un valor binario (0/1), por ejemplo, la conversión de la compra del usuario, que dice si un usuario completó una compra después de haber sido expuesto a un experimento.
- Ratio Metrics, que es un ratio de dos métricas continuas diferentes, por ejemplo, número de tickets de soporte por entrega, donde el numerador es el recuento de tickets y el denominador es el recuento de entregas.
Based on different factors, including metric type and sample size, the library applies different methodologies, such as linear model, bootstrapping, and delta method to compute the p-value and standard error. Clustering is very common in DoorDash's experiments. For example, all deliveries from a particular store form a cluster. We use multiple methods to adjust the standard error to avoid false positives due to data clustering, such as the Cluster Robust Standard Error (CRSE) method in linear model, delta method, and cluster bootstrapping. We selectively apply variance reduction methods to reduce the noise in the results and improve the power of the experiments. The library also runs imbalance tests to statistically detect imbalance in the bucket sizes for A/B tests.
Explorar la WebUI de Curie
La interfaz de usuario de Curie, construida sobre React, se utiliza para establecer la configuración de análisis de experimentos y visualizar los resultados de los análisis. Esta interfaz está respaldada por un servicio gRPC y una capa BFF (Backend-For-Frontend) para interactuar con el almacén de datos.
Conclusión
An experiment analysis platform is very important for automation and faster iteration on new features. It acts as the data scientist's best friend, analyzing the experiments for them so they can focus their efforts and time on other crucial aspects of experimentation. DoorDash data scientists are adopting Curie to improve their experimental velocity and more quickly determining which new features best serve our customers. Currently, we are working on converting this MVP into a more stable platform with features such as standard metrics, results visualization, and advanced statistical methodologies.
Creemos que nuestra plataforma emplea una arquitectura y unas tecnologías modernas que la hacen muy útil para nuestros científicos de datos y ampliable de cara al futuro. Curie puede servir de ejemplo para otras empresas que desarrollen una práctica de experimentación para mejorar sus propias aplicaciones y ofertas.
Agradecimientos
Gracias a Yixin Tang y Caixia Huang por sus contribuciones a esta plataforma, y a Sudhir Tonse, Brian Lu, Ezra Berger y Wayne Cunningham por sus constantes comentarios sobre este artículo.