Ir al contenido

Blog


Afrontar los retos del desajuste de la proporción de muestras en las pruebas A/B

17 de octubre de 2023

|
Stas Sajin

Stas Sajin

Michael Zhou

Michael Zhou

Krishna Gourishetti

Krishna Gourishetti

La experimentación no es sólo la piedra angular de la innovación y la toma de decisiones acertadas; a menudo se la considera el patrón oro para la resolución de problemas, gracias en parte a sus raíces en el método científico. El propio término evoca una sensación de rigor, validez y confianza. Sin embargo, por poderosa que sea la experimentación, su integridad puede verse comprometida por detalles pasados por alto y problemas imprevistos. Uno de estos problemas es el desajuste en la proporción de las muestras, o SRM. 

El SRM representa uno de los problemas de calidad de datos más atroces en las pruebas A/B porque compromete fundamentalmente el supuesto básico de la asignación aleatoria. Por ejemplo, si se espera que dos grupos de tamaño razonable se dividan al 50/50, pero en lugar de ello muestran una división 55/45, es probable que el proceso de asignación esté comprometido. Esto significa que existe una gran posibilidad de que los resultados experimentales y las decisiones basadas en ellos no sean válidos.

En DoorDash, innovamos y experimentamos constantemente. Para hacerlo con eficacia, tuvimos que encontrar formas de reducir nuestra tasa de SRM. En este post, exploramos algunos de los ejemplos comunes de fallos de SRM que experimentamos, las soluciones que hemos implementado para resolver estos problemas y cómo hemos dado a conocer estas soluciones internamente para reducir drásticamente nuestra tasa de SRM. 

Figura 1: Si tenemos dos grupos que se espera que tengan una distribución de 50/50, esperamos que la comprobación SRM pase si se observa realmente esa división de 50/50. Sin embargo, deberíamos preocuparnos si en lugar de eso hay una división de 55/45. Sin embargo, deberíamos preocuparnos si, por el contrario, la distribución es 55/45.

Falsas ganancias y pérdidas reales: historias con moraleja

Ejemplo 1: El espejismo de los 10 millones

Imagine que su objetivo es mejorar los ingresos semanales por usuario. Después de configurar el experimento con una división al 50% entre los grupos de control y tratamiento, lo ejecuta durante una semana y comprueba que los ingresos han mejorado un 2%, lo que supone un incremento de 200.000 dólares semanales. Anualizado, esto supone más de 10 millones de dólares al año. Se chocan las manos y el equipo ya tiene la vista puesta en el próximo gran proyecto.

Afortunadamente, un experimentador más observador se ha dado cuenta de que la comprobación del MER falló. En lugar de una división 50/50 entre el tratamiento y el control, en realidad había una división 49,5/50,5, más que suficiente para provocar un fallo del SRM. Un examen minucioso muestra que la causa principal del fallo es que todos los empleados estaban expuestos al tratamiento. Casi todas las empresas orientadas al cliente tienen una práctica interna de dogfooding en la que los empleados internos reciben las últimas características por defecto. Dado que los empleados utilizan el producto con mucha más frecuencia que los usuarios externos, la contribución del ~1% a la muestra total fue suficiente para sesgar las métricas. El júbilo del equipo por haber ganado 10 millones de dólares fue trágicamente prematuro.

SegmentoGrupo experimentalNúmero de muestras7 días de ingresos/usuarioImpacto incremental notificado
Todos los usuariosControlar500,000$10
          $0
Todos los usuariosTratamiento500,000$10
EmpleadosTratamiento10000$30    $200,000

Tabla 1: En este experimento, hay un desequilibrio de 49,95/50,05 entre los grupos de control y tratamiento. El desequilibrio es accidental y se debe exclusivamente a la inclusión de los empleados en el grupo de tratamiento. Dado que los empleados se comprometen más con el producto, sesgan el impacto de los ingresos en un 2%, lo que lleva al impacto semanal de 200.000 dólares notificado. Cuando se excluye el segmento de empleados, el impacto incremental real es de 0 $.

Tenga en cuenta que un pequeño cambio en el tamaño absoluto de los grupos (1%) puede introducir un cambio muy grande en la métrica del experimento (2%), lo que significa que el tamaño del SRM no establece un límite en su impacto sobre la lectura de la métrica. Aunque el ejemplo anterior es ficticio, hemos observado que en nuestra plataforma los experimentos que tienen SRM tienen el doble de métricas estadísticamente significativas. En pocas palabras, al hacer la vista gorda al desequilibrio, los equipos podrían duplicar erróneamente su tasa de resultados "estadísticamente significativos", lo que lleva a conclusiones potencialmente erróneas. 

Ejemplo 2: El sesgo de la corrección de errores

La gestión de la corrección de errores es otra área en la que los usuarios pueden introducir inadvertidamente SRM. Imaginemos, por ejemplo, que hay un error en la implementación de un nuevo tratamiento introducido recientemente. Un ingeniero lo detecta y lo corrige a mitad del experimento. Posteriormente, ajusta la fecha de inicio del experimento para que no incluya los datos métricos recopilados antes de la corrección del error. 

Figura 2: Desequilibrio de los MER tras la corrección de un error a mitad del experimento 

La figura 2 muestra el lapso temporal del cambio de asignación de la exposición. Dado que los usuarios no olvidan el historial, el error introducido da lugar a una distribución desigual que se desvía de la proporción esperada de la muestra; es probable que los usuarios de baja intención hayan abandonado la plataforma, mientras que los usuarios de tratamiento restantes han decidido quedarse. Este desequilibrio conduce tanto a un SRM como a un sesgo preexperimental en la interpretación de los resultados de este experimento.

La solución a este problema es volver a barajar la exposición tanto para el control como para el tratamiento una vez que se haya corregido el error. El reinicio del experimento mediante la reorganización resuelve el desequilibrio y devuelve los grupos de control y tratamiento al mismo punto de partida.

Figura 3: Experimento de reorganización tras la corrección del error que resuelve el SRM

Estos son sólo dos ejemplos de cómo los MER pueden colarse en la experimentación. Por desgracia, todo el sector coincide en que los MER son fáciles de detectar, pero muy difíciles de diagnosticar y corregir, incluso para los experimentadores más experimentados. Los SRM pueden deberse a problemas de calidad de los datos, problemas de configuración de los experimentos, filtrado incorrecto al unir los datos, procedimientos inadecuados de rollouts/rollback, interacción entre experimentos, definiciones incoherentes de ConsumerIds (UUID frente a ids incrementales) y cualquier otro problema. Nuestro reto ha sido crear soluciones para ayudar a nuestros experimentadores a evitar, identificar y corregir SRM.

Soluciones desde las trincheras

En DoorDash, hemos seguido varios enfoques para reducir la tasa de SRM de la plataforma, incluida la innovación en la metodología para diagnosticar SRM, la mejora de nuestra capacidad de observación y alerta en tiempo real y el enfoque en la educación y la concienciación. 

Enfoques estadísticos para identificar desequilibrios

El enfoque más habitual para identificar los MER consiste en utilizar una prueba chi-cuadrado que puede detectar rápidamente cuando algo va mal. Sin embargo, estas pruebas no pueden ayudar a identificar por qué se ha producido un desequilibrio. Así que, como seguimiento, algunas plataformas permiten a los experimentadores realizar "estadísticas a ojo". Esto permite segmentar los datos para comprender qué atributo puede estar provocando el desequilibrio. Por ejemplo, la información recopilada y aleatorizada sobre el uso de la plataforma podría segmentarse en Android e iOS para permitir una comprobación visual de las irregularidades. 

Una mejora de esta segmentación ad hoc consistiría en realizar repetidamente una prueba chi-cuadrado en subpoblaciones de segmentos o realizar pruebas de permutación con tablas de contingencia. Este último enfoque es mejor que la prueba de ji cuadrado porque puede indicar qué segmentos de usuarios provocan el desequilibrio y proporciona estadísticas inferenciales para la toma de decisiones. Dicho esto, la realización de pruebas de permutación o de pruebas de ji cuadrado ad hoc plantea tres problemas:

  • No generan efectos ortogonales. La figura 3 muestra un ejemplo en el que los segmentos de país y plataforma se analizan por separado, lo que provoca desequilibrios en ambos. Por ejemplo, el desequilibrio podría deberse a la exposición a Android, pero como Estados Unidos tiene más usuarios de Android que otras partes del mundo, el atributo país también se marcará como desequilibrio. La falta de efectos ortogonales es la mayor desventaja de los métodos actuales. 
  • No ofrecen un buen equilibrio entre los falsos positivos y la capacidad de detectar MER. Ejecutar pruebas de permutación y chi-cuadrado contra docenas de segmentos requiere correcciones agresivas del valor p, reduciendo así la sensibilidad de la comprobación SRM.
  • Son ineficientes desde el punto de vista computacional. Ejecutar pruebas de permutación a escala con decenas de miles de comprobaciones diarias puede generar rápidamente una huella de infraestructura muy ineficiente. 

En su lugar, queríamos un enfoque que nos permitiera generar efectos ortogonales, que fuera escalable y que no sacrificara potencia.

Figura 4: Para demostrar por qué son importantes los efectos ortogonales, obsérvese que Android es la raíz del desequilibrio. Pero como EE.UU. tiene más usuarios de Android que otros países, un experimentador podría suponer erróneamente que el problema puede atribuirse al país del usuario. 

Nuestro enfoque: La regresión es todo lo que necesitamos

Cuando asignamos aleatoriamente usuarios a los grupos de tratamiento y control, suponemos que no hay nada más en el mundo que la aleatoriedad que impulsa esas asignaciones. Como se ilustra en la Figura 5, si asignáramos un estimador para comprobar cualquier relación entre los atributos de los usuarios antes de la aleatorización y la asignación, los coeficientes de correlación o regresión deberían ser nulos. 

Figura 5: Los atributos recogidos antes de la aleatorización no deberían influir en la asignación del tratamiento. 

Un estimador que nos proporciona propiedades de ortogonalización y genera estadísticas sencillas de interpretar que nos permiten verificar si algo está relacionado con la asignación al tratamiento es la regresión lineal

Utilizaremos dos dimensiones para explicar más claramente cómo utilizar la regresión lineal para identificar el desequilibrio. Supongamos que tenemos dos atributos que recogemos en el momento de la aleatorización: 

  • País: EE.UU., Canadá, Australia
  • Plataforma: Web, iOS, Android

Pondremos a prueba nuestro planteamiento con tres escenarios:

  • Sin desequilibrio
  • Desequilibrio debido al país=Australia
  • Desequilibrio debido a país=Australia O plataforma=Web

Figura 6: En el escenario 1, no hay desequilibrio. En el escenario 2, se produce un desequilibrio debido a la división 80/20 en lugar de 50/50 en Australia. En el escenario 3, existe un desequilibrio provocado tanto por el segmento de Australia como por el de Android, que también tiene un reparto 80/20.

import pandas as pd
import numpy as np
import statsmodels.formula.api as smf
def generate_data(n,
                  platforms=["iOS", "Android", "Web"],
                  countries=["USA", "AUS", "CAN"]):
    np.random.seed(42)
    expected_distribution = [0.5, 0.5]
    experiment_groups = [1, 0]
    df = pd.DataFrame(
        {
            "user_id": range(1, n + 1),
            "platform": np.random.choice(platforms, size=n),
            "country": np.random.choice(countries, size=n),
        }
    )
    # Scenario 1: No imbalance
    df["scenario_1"] = np.random.choice(experiment_groups, size=n, p=expected_distribution)
    # Scenario 2: Australia 80/20 imbalance
    df["scenario_2"] = df["scenario_1"]
    mask_2 = df["country"] == "AUS"
    df.loc[mask_2, "scenario_2"] = np.random.choice(experiment_groups, size=sum(mask_2), p=[0.8, 0.2])
    # Scenario 3: Australia or Android 80/20 imbalance
    df["scenario_3"] = df["scenario_1"]
    mask_3 = (df["country"] == "AUS") | (df["platform"] == "Android")
    df.loc[mask_3, "scenario_3"] = np.random.choice(experiment_groups, size=sum(mask_3), p=[0.8, 0.2])    
    return df

En este fragmento de código, generamos datos con tres opciones de aleatorización: una con asignación completamente aleatoria, otra en la que el sesgo de la distribución viene determinado por la plataforma y otra en la que el sesgo de la distribución viene determinado por el país o la plataforma. 

Fundamentalmente, si queremos entender qué atributos están relacionados con la asignación al tratamiento, simplemente tenemos que ajustar una regresión con la siguiente forma:

es_tratamiento ~ país + plataforma

El código siguiente nos permite ejecutar esta regresión.

def run_model(df, scenario_name):
    # center the outcome variable around expected ratio
    df['is_treatment'] = df[scenario_name] - 0.5
    formula = "is_treatment ~ 1 + platform + country"
    # fit the regression 
    m = smf.glm(formula, data=df).fit(cov_type="HC1")
    # get the p-values for the main effect using a Wald test
    wald_p_values = m.wald_test_terms(scalar=True).table
    return wald_p_values

Aquí ejecutamos una regresión para explicar si la asignación al tratamiento es función de las variables de plataforma y país. Dado que sólo nos interesan los efectos principales de esas variables, la seguimos con una prueba de Wald que pregunta ¿Está relacionado el efecto principal de un predictor concreto con la asignación al tratamiento?

Tenga en cuenta que cuando ejecutamos la regresión, nos interesan los efectos principales (por ejemplo, "¿Existe un efecto principal de la plataforma en la asignación del tratamiento?"), por lo que utilizamos una prueba de Wald para obtener los valores p del efecto principal. La figura 7 muestra el resultado de la prueba de Wald para cada uno de los tres escenarios. Podemos extraer inmediatamente estas conclusiones:

  • En el Escenario 1, ninguno de los atributos está relacionado con la asignación del tratamiento.
  • En el escenario 2, podemos ver que el país tiene un valor p muy bajo. Hay un efecto principal del país, pero aún no sabemos qué segmento específico del país es responsable del desequilibrio.
  • En el Escenario 3, podemos ver que tanto la plataforma como el país son factores de desequilibrio. 

Figure 7: The Wald test results show: In scenario 1, none of the attributes are related to treatment assignment. In scenario 2, only country is related to treatment assignment (p<0.0001) and in scenario 3 both platform and country are predictive of treatment assignment (p<0.0001). 

Tenga en cuenta que nuestra aplicación interna es más compleja. El proceso de ejemplo descrito hasta ahora sólo nos permite encontrar los efectos principales. Internamente, aplicamos un algoritmo recursivo para eliminar subconjuntos de los datos que más contribuyen al desequilibrio, de forma similar a lo que haría un experimentador en el proceso de recuperación de datos de SRM. Además, aplicamos una corrección a los valores p cuando realizamos comprobaciones múltiples y manejamos una variedad de casos límite, como cuando un segmento tiene varianza cero o la regresión no es invertible debido a una multicolinealidad perfecta. 

Optimizaciones

Como se muestra en el fragmento de código siguiente, una optimización importante que podemos hacer se basa en la regresión ponderada al realizar el cálculo. El uso de pesos en la regresión permite escalar eficientemente el algoritmo, incluso cuando se interactúa con grandes conjuntos de datos. Con este enfoque, no sólo realizamos el cálculo de regresión de forma más eficiente, sino que también minimizamos los costes y latencias de transferencia de red y podemos realizar gran parte de la agregación para obtener las entradas en el almacén de datos. 

df_aggregated = df.groupby(['country', 'platform', 'scenario_1'], as_index=False).size()
model1 = smf.glm(formula, data=df, freq_weights=df.size.df_aggregated).fit(cov_type="HC1")

En este ejemplo, agregamos los datos a nivel de plataforma, país y grupo experimental. Esta agregación nos permite reducir el tamaño de los datos de millones a cientos de filas, lo que hace que el cálculo de SRM sea muchos órdenes de magnitud más eficiente. Esta agregación se realiza en el almacén de datos.

Extensiones

Una vez descartadas todas las causas de desequilibrio, una ampliación de esta metodología consistiría en utilizar el enfoque de regresión para corregir los MER y salvar así los datos recopilados. Esto debe hacerse sólo después de haber identificado causas claras de desequilibrio. Para aplicar la corrección, basta con ajustar una regresión con esta forma:

metric_outcome ~ is_treatment + country + platform 

Añadir las dos variables regresoras no sólo corrige los resultados para SRM, sino que también podría contribuir a la reducción de la varianza porque las covariables adicionales podrían explicar parte de la varianza en el resultado métrico. 

Observabilidad

DoorDash también ha explorado formas de ofrecer a los usuarios una mejor observabilidad de las exposiciones a experimentos más allá de los métodos estadísticos mencionados anteriormente. Las exposiciones de experimentos son uno de nuestros eventos de mayor volumen. En un día normal, nuestra plataforma produce entre 80.000 y 110.000 millones de eventos de exposición. Transmitimos estos eventos a Kafka y luego los almacenamos en Snowflake. Los usuarios pueden consultar estos datos para solucionar problemas en sus experimentos. Sin embargo, hay algunos problemas con las herramientas actuales:

  1. Existe un desfase de decenas de minutos entre el momento en que se crean las exposiciones y el momento en que están disponibles para su consulta en Snowflake.
  2. Las consultas tardan mucho tiempo en ejecutarse en Snowflake, incluso después de aplicar el particionado. Ejecutar consultas complejas lleva aún más tiempo.

Queremos ofrecer a los usuarios un panel de control fácil de usar que les permita supervisar y observar las exposiciones de los experimentos en tiempo real. Esto permite a los usuarios obtener información inmediata sobre el rendimiento y la salud de sus experimentos en curso. Como ventaja añadida, el panel de control reduce nuestra dependencia de Snowflake para solucionar los problemas de los experimentos, con lo que se reducen los costes operativos generales.

Necesitábamos hacer dos cosas para crear los cuadros de mando. En primer lugar, tuvimos que agregar el flujo de exposición a través de diferentes dimensiones. Incluimos dimensiones como el nombre del experimento, la versión del experimento, la variante y el segmento, que representa el grupo de población de la muestra tal y como se definió al configurar el experimento. Para esta tarea, utilizamos Apache Flink, que admite el procesamiento de flujos y proporciona semántica de procesamiento en tiempo de eventos. Apoyado internamente en DoorDash, Flink es utilizado por muchos equipos para ejecutar sus trabajos de procesamiento en streaming de datos. Utilizamos las funciones integradas de agregación basadas en ventanas temporales de Flink en tiempo de exposición. A continuación, enviamos estos datos agregados a otro tema de Kafka. 

A continuación, teníamos que guardar los datos agregados por la ventana temporal en un almacén de datos. Queríamos un almacén de datos OLAP analíticos con baja latencia. Para ello utilizamos Apache Pinot. Pinot es un almacén de datos OLAP distribuido en tiempo real que puede recibir datos de fuentes de flujo como Kafka, escalar horizontalmente y proporcionar análisis en tiempo real con baja latencia. Nos basamos en las funciones de agregación integradas en Pinot para producir los resultados finales, que se introducen en los cuadros de mando de los usuarios para proporcionar diversas visualizaciones. La figura 8 muestra una visión general de nuestra solución:

Figura 8: Aquí resumimos nuestro procesamiento de flujos en tiempo real.

Hemos añadido otra capa de transparencia integrando estos cuadros de mando en nuestra plataforma de configuración de experimentos. Con esta herramienta, los usuarios pueden solucionar rápidamente una serie de problemas asociados a SRM, entre ellos:

  • ¿Lancé una variante de tratamiento antes que otra?
  • ¿Hay más exposiciones en un grupo que en otro?
  • ¿Existen anomalías en las series temporales de los registros de exposición?

A continuación encontrará ejemplos de gráficos de nuestros cuadros de mando.

Figura 9: Muestra la cronología del recuento de exposiciones por variante. Un usuario puede acceder a estos datos pocos minutos después de iniciar un experimento.

Figura 10: Las visualizaciones de la distribución de las exposiciones por cada variante permiten al usuario comprobar si existen irregularidades importantes. 

La información en tiempo real no sólo ayuda a diagnosticar problemas en los experimentos, sino que también genera una mayor confianza en que la implantación se está desarrollando según lo previsto.

Alerta

Para minimizar aún más el índice de ocurrencias de SRM, los usuarios pueden suscribirse a un sistema de alerta de comprobación del estado del experimento que les notifica rápidamente -a menudo en 24 horas- si se detecta un desequilibrio en su experimento. Esto permite realizar ajustes oportunos y proactivos que pueden eliminar prácticamente la necesidad de descartar datos valiosos debido a resultados invalidados.

Figura 11: Al configurar un experimento, los usuarios pueden suscribirse a nuestro sistema de alertas. 

La educación es clave: El papel de la concienciación en la reducción de los MER

En nuestro empeño por reducir la incidencia de los SRM en la plataforma, hemos explorado y aplicado diversas soluciones técnicas, desde sistemas de control en tiempo real hasta nuevos algoritmos que identifican las fuentes de desequilibrio. Aunque estos avances han sido cruciales para minimizar los SRM, hemos descubierto que la intervención humana a través de la concienciación y la educación sigue siendo indispensable y es lo que más mueve la aguja. Conscientes de esta carencia, pusimos en marcha un planteamiento educativo múltiple:

  • Sesiones de formación: Organizamos un bootcamp interno centrado en las mejores prácticas para la configuración de experimentos, destacando cómo prevenir el desequilibrio debido a problemas de configuración simples.
  • Documentación: Proporcionamos guías completas con estudios de casos que una persona sin conocimientos técnicos puede entender. Incluso cambiamos internamente el nombre de la terminología de "Desajuste de la relación de muestras", que es un trabalenguas técnico, a "Comprobación del desequilibrio".
  • Lenguaje más contundente: Hemos cambiado el lenguaje de la documentación y la forma de comunicar los fallos de los MER para que estén más en consonancia con la magnitud del impacto que tienen en la toma de decisiones. Aunque hay casos raros en los que los fallos de SRM pueden pasarse por alto, el lenguaje revisado hace hincapié en que no se puede confiar en los resultados de experimentos desequilibrados. 
  • Compromiso proactivo del usuario: La naturaleza reactiva de la resolución de problemas plantea un reto a la hora de minimizar los MER. Es posible que los usuarios no se den cuenta de la existencia de SRM hasta que se encuentran con el problema, lo que a menudo retrasa la adopción de medidas. En lugar de esperar a que los usuarios se unan a nuestra sesión de formación o abran la documentación y las herramientas de diagnóstico, los involucramos desde el principio mediante sesiones de intercambio de conocimientos específicas para cada equipo.

A veces, las mejores soluciones no consisten sólo en construir una ratonera mejor, sino en asegurarse de que todo el mundo sabe utilizar las nuevas herramientas de forma eficaz. Para nosotros, la educación y la concienciación han marcado la diferencia. Escribir este artículo es en sí mismo un intento de impulsar una mayor concienciación y educación.    

Resultados

A los seis meses de comenzar nuestro trabajo, observamos un descenso del 70% en los incidentes de SRM en la plataforma. Esto significa que cientos de experimentos que podrían haber estado plagados de conclusiones erróneas han dado lugar en su lugar a resultados legítimos. Más allá de las cifras, se ha producido un cambio palpable en la dinámica del equipo. Con una mayor concienciación, las pruebas A/B se establecen y revisan más a fondo y se ejecutan con más éxito. Los equipos ya no tienen que gastar valiosos recursos y capacidad experimental en reiniciar pruebas o conciliar resultados inesperados causados por fallos de desequilibrio.

Trabajo futuro

Aunque hemos hecho grandes progresos en la reducción de la incidencia de SRM en DoorDash, creemos que se pueden hacer aún más mejoras a través de la observabilidad en tiempo real, la corrección automática y la estandarización.

  • La observabilidad en tiempo real puede mejorarse mediante una integración más estrecha con los algoritmos utilizados en la comprobación de diagnósticos. La ejecución de pruebas de Wald y regresión ponderada en datos de recuento es poco costosa desde el punto de vista computacional, por lo que nos gustaría ejecutarla en los resultados de las consultas de Pinot siempre que un usuario examine exposiciones en tiempo real.
  • La corrección automática nos permitirá solucionar problemas comunes de SRM y ajustar los resultados de los experimentos sin obligar al usuario a tomar ninguna medida adicional. Como se ha demostrado anteriormente, si podemos identificar la fuente del desequilibrio, a menudo podemos salvar el resultado del análisis añadiendo covariables adicionales a nuestro estimador.
  • La estandarización ofrece una salvaguarda contra los errores más comunes, reduciendo así la probabilidad de que el usuario cometa errores. Por ejemplo, si un usuario corrige un error y vuelve a lanzar un experimento, nuestro sistema podría identificar proactivamente las posibles repercusiones de los cambios y ajustar en consecuencia la intensidad de las advertencias o directrices.

Gracias a estas medidas, podemos aumentar aún más la solidez y credibilidad de los resultados experimentales.

Agradecimientos

Muchas gracias a Drew Trager, Sharon Weng, Hassan Djirdeh, Yixin Tang, Dave Press, Bhawana Goel, Caixia Huang, Kevin Tang y Qiyun Pan, que han sido fundamentales en sus comentarios, ejecución y colaboración en muchas de las iniciativas descritas anteriormente. Por último, muchas gracias al equipo de Eng Enablement: Janet Rae-Dupree, Robby Kalland y Marisa Kwan por su continuo apoyo en la revisión y edición de este artículo. 

Si te apasiona crear productos innovadores que tengan un impacto positivo en la vida de millones de comerciantes, Dashers y clientes, considera la posibilidad de unirte a nuestro equipo.

Manténgase informado con las actualizaciones semanales

Suscríbase a nuestro blog de ingeniería para estar al día de los proyectos más interesantes en los que trabaja nuestro equipo.

About the Authors

  • Stas Sajin

    Stas Sajin is a Software Engineer on Experimentation Team at DoorDash. His focus is on increasing experimentation velocity and trust.

  • Michael Zhou

    Michael Zhou is a Software Engineer on Experimentation Platform team at DoorDash. His focus is on infra development and methodology execution.

  • Krishna Gourishetti

    Krishna Gourishetti works as a software engineer at DoorDash, since early 2022, and had been focused on building observability features for the experimentation platform.

Trabajos relacionados

Ubicación
Oakland, CA; San Francisco, CA
Departamento
Ingeniería
Ubicación
Oakland, CA; San Francisco, CA
Departamento
Ingeniería
Job ID: 2980899
Ubicación
San Francisco, CA; Sunnyvale, CA
Departamento
Ingeniería
Ubicación
Pune, India
Departamento
Ingeniería
Ubicación
Pune, India
Departamento
Ingeniería