Pruebas A/B aplicadas a hardware de Lyft

Este artículo fue publicado originalmente el 16 de junio de 2021 en eng.lyft.com

Autores: Garrett Drayna, CJ Chen, and Mark Schulte, traducido al español por Adriana Robles

Las pruebas A/B son experimentos controlados para medir las diferencias en el desempeño entre grupos, herramientas ubicuas para el análisis de datos y representación del estándar para la medición de lineas de negocio. En Lyft, las pruebas A/B son usadas en casi todos nuestros productos, desde medir el desempeño de los algoritmos del marketplace, en los diseños de las aplicaciones y hasta los cambios en la infraestructura. Las unidades de análisis para la mayoría de nuestras pruebas A/B son los usuarios y, en algunas ocasiones, los mercados o incluso las horas del día. En esta publicación vamos a describir el nuevo tipo de pruebas A/B que el equipo de hardware está realizando en Lyft. También ilustraremos un par de pruebas A/B donde hemos mejorado de forma segura y confiable la experiencia del usuario, disminuyendo costos y mejorando el servicio en las ciudades donde Lyft opera.

Figura 1: Primera generación de Lyft eBikes sin estación

El equipo de TBS (Transporte público, Bicicletas y Scooters [monopatines]) de Lyft es la red más grande de bicicletas compartidas en Norteamérica (incluyendo los sistemas en Nueva York, Chicago y San Francisco), y administra los scooters y productos de transporte público que están integrados en la app de Lyft. Actualmente TBS opera cuatro tipos de productos de hardware en muchas de las grandes ciudades de Norteamérica — bicicletas eléctricas y no eléctricas, scooters eléctricos y ciclo-estaciones. Lyft TBS diseña, opera y mantiene su propio hardware. Nuestros ingenieros de hardware, gestores de producto (product managers), científicos de datos y otros están constantemente buscando mejorar y refinar nuestros productos de hardware existentes y diseñar nuevos.

Figura 2: Pruebas y experimentos en el ciclo de vida del hardware

Las organizaciones que desarrollan hardware, Lyft incluida, normalmente tienen un proceso complejo de pruebas que sucede durante el diseño y manufactura del hardware, pero ahí es donde suele terminar. Ya que Lyft es tanto dueño como operador de su propio hardware y ha establecido una cultura e infraestructura para análisis de datos, cuenta con una posición única para realizar pruebas directamente en el mercado (producción), adicionalmente a las pruebas tradicionales. Por ejemplo, para responder la siguiente pregunta: ¿qué tan bien trabajan las nuevas versiones de firmware? O ¿cómo reaccionan los usuarios a los diferentes niveles de carga de nuestras bicicletas eléctricas (e-bikes) y su consumo de energía? Sin embargo, primero necesitamos definir cómo ejecutar pruebas A/B en nuestro hardware.

Las pruebas A/B que se ejecutan de forma común en Lyft son por división de usuarios (user-split) y por división de tiempo (time-split). Lyft cuenta con poderosas herramientas internas para pruebas A/B para simplificar o incluso automatizar partes del proceso de pruebas, y llevar a cabo estos tipos de pruebas A/B. Los usuarios de Lyft usan tanto el hardware como la app, entonces ¿por qué no dividir el experimento en usuarios? Las pruebas de división de usuarios son ideales para medir la reacción a las nuevas funcionalidades; ya que muchas de las respuestas se encuentran en las reacciones de los usuarios, lo más natural sería realizar estas pruebas, ¿cierto?

No tan rápido. La parte interesante aquí es que necesitamos medir tanto el desempeño del hardware en el mundo real como la reacción de los usuarios. O, podríamos interesarnos solamente en el desempeño del hardware, así como en verificar el funcionamiento y rendimiento de las nuevas versiones de firmware.

¿Contamos con los datos suficientes para hacer que esto funcione?

Actualmente Lyft opera entre 10,000–20,000 bicicletas y scooters, todos conectados por IdC (Internet de las cosas, IoT por sus siglas en inglés). Si bien esto puede parecer un número considerable, es pequeño si lo comparamos con muchas pruebas por división de usuario en Lyft, las que pueden tener millones de usuarios expuestos. ¿Acaso esto tendría el suficiente impacto estadístico?

Quizá sí es una respuesta no intuitiva, pero — hay un espectro. Muchas de las pruebas de hardware se miden por viaje (por ejemplo, conversión, calificación del viaje). La varianza en estas métricas de pruebas de hardware está dada por la variación entre viaje y viaje. Adicionalmente, el desgaste mecánico y el consumo eléctrico son determinados por el número de viajes, peso del viajero, selección de ruta, y otros elementos de UX. Esto significa que obtendremos resultados en el orden de las O(viajes) para estas métricas. Del otro lado de este espectro encontraremos fallas y errores poco comunes. Estos podrían o no ocurrir en una pequeña fracción de viajes.

Tabla 1: Efectividad de las métricas tomadas a una muestra de 2000 bicicletas, en pruebas divididas

El calentamiento: Lanzamiento de firmware con pruebas A/B

Para definir cómo implementaremos las pruebas A/B en hardware, decidimos atacar primero un problema de “calentamiento”, que es la adición de mediciones de desempeño a nuestro proceso de pruebas de firmware. Lyft emplea actualizaciones “over-the-air” (inalámbricas, OTA por sus siglas en inglés) para realizar cambios o actualizaciones del código en vehículos vía remota, sin necesitar intervención humana. Cada dos semanas integramos al código de nuestros vehículos nuevas funcionalidades, corrección de errores, refactorizaciones, etc., lo probamos y actualizamos los vehículos en producción. Hemos mejorado varios aspectos de desempeño en nuevas versiones de firmware con la realización de pruebas A/B, por ejemplo:

• Somos capaces de encontrar defectos “sólo en producción” que en pruebas en ambientes de calidad no se detectan.
• Los desarrolladores pueden verificar que los arreglos funcionan correctamente, realizando la instrumentación adecuada para intentar reproducirlos.
• Podemos medir el impacto en el negocio o usuarios provocado por los cambios y/o nuevas funcionalidades, las cuales no podemos o queremos probar aisladamente.

Esta situación fue una buena candidata para llevar a cabo la construcción y ejecución de nuestra primera prueba de división por hardware en Lyft. Durante la primera ejecución de pruebas A/B en Lyft, detectamos algunos pasos clave:

1. Configurar la plataforma de experimentación para enviar y rastrear los cambios, haciendo uso del id del vehículo y no del usuario.
2. Desarrollar un firmware de control que utiliza las variables en el servicio configurado y bajo prueba. Esto envía una nueva versión del firmware (OTA) a los vehículos dentro del grupo de pruebas.
3. Registrar exposiciones cuando el vehículo confirma que la nueva versión del firmware ya se encuentra corriendo.
4. Construir métricas adaptadas a las necesidades de cada liberación de firmware. Algunas de las métricas que definimos están en la siguiente tabla.

Tabla 2: Métricas para las pruebas A/B a firmware

Pruebas A/B de funcionalidades de hardware

La forma ‘ideal’ de realizar pruebas A/B en hardware es aislando el desempeño de cada funcionalidad. Para hacer esto, construimos un sistema para pasar variables (es decir, usamos ‘banderas’) directamente desde nuestro servicio bajo prueba al firmware. No necesitamos depender de un dispositivo corriendo exitosamente las actualizaciones del sistema operativo, o forzar valores en la versión del firmware. En cambio, podemos parametrizar las variables de interés y probar el desempeño de cada uno de esos valores.

Recordemos el por qué probamos hardware y no usuarios — porque primero necesitamos conocer el funcionamiento del hardware, y después las reacciones del usuario. En las pruebas de división por hardware, los usuarios podrían notar diferencias si toman viajes en diferentes vehículos varias veces. Entonces, ¿cómo medimos las reacciones del usuario? Ejecutamos dos experimentos consecutivos, uno dividido por dispositivos y otro sintético dividido por usuarios.

En nuestro experimento real, medimos métricas de rendimiento de hardware y de viaje como calificación por viaje y viajes cancelados. En nuestras pruebas sintéticas, utilizamos el modelado de puntaje de propensión para emparejar usuarios que observaron diferentes variantes con usuarios similares que sólo vieron el control. Con este grupo sintético de control, podemos medir métricas de usuario a largo plazo, como retención y pérdidas de usuarios. Esto nos permite tomar decisiones que impactan todo el negocio. ¿Existen cambios en el rendimiento del hardware que hagan que valga la pena realizar cambios asociados a la experiencia de usuario?

Un experimento reciente que ejemplifica estas pruebas: ¿Deberíamos de poner los seguros en modo dormido (sleep mode) cuando no se esté en un viaje?

Imagen 3: Una representación del guardabarros de una bici eléctrica sin estación, con su módulo del cable de seguridad. Poner este módulo en modo de bajo consumo energético cuando no está en marcha mejoró significativamente nuestra necesidad de instalar baterías recién cargadas en la bicicleta en una prueba A / B dividida por hardware.

El contexto de este experimento fue:

• Podemos ahorrar batería al poner el seguro de la batería y el cable de seguridad en modo dormido. Sin embargo, cuando un usuario inicia un viaje, la bicicleta hace un sonido “bip” indicando el inicio del viaje, pero el cable de seguridad tarda de 1 a 2 segundos en despertar y liberarse. Esto duplica la latencia. Necesitamos verificar los experimentos de ahorro de energía en producción y medir si la latencia extra agrega fricción en la experiencia de usuario.

Nuestra hipótesis:

• Lograremos un ahorro en el uso de energía y costos de operación, según lo predicho por las estimaciones basadas en el diseño de ingeniería, sin afectar la experiencia de usuario.

Lo que encontramos fue fascinante (la información fue alterada, pero es correlacionalmente correcta):

• Consumo de energía en reposo (mientras espera un viaje): -25%
• Número de cambios de batería: -17% (Gran ahorro en el costo de operación)
• Calificación de los viajes: -1%
• Bicicletas sin seguro puesto: +30%
• No hubo cambios en los viajes a largo plazo o en la retención de usuarios.

Este es el poder de las pruebas A/B. Validamos que el cambio ahorraría una cantidad significativa de energía y optimizaría la operación de cambio de baterías. Sin embargo, también descubrimos un error de firmware que resultó en un aumento (pequeño pero significativo) de bicicletas sin seguro puesto. Además, notamos que los usuarios pudieron haber experimentado una pequeña fricción adicional en su experiencia. Arreglamos el error y lanzamos este experimento a todas las bicicletas eléctricas sin estación. Esto no es suficiente para cambiar la frecuencia con la que usan nuestro servicio, pero queremos realizar un seguimiento cuidadoso y continuar brindando la mejor experiencia de viaje que podamos.

Con las pruebas A/B a las funcionalidades del hardware, estamos trabajando para responder a varias preguntas clave para nuestro negocio. Por ejemplo: el eAssist (apoyo inteligente al pedaleo mediante un motor eléctrico) ha cambiado por completo los desplazamientos en bicicleta, y nuestros usuarios prefieren en gran medida las bicicletas eléctricas a los pedales cuando se les da la opción. Pero hay matices en esta decisión:

• ¿Qué cantidad de eAssist es la cantidad adecuada para nuestros usuarios?
• ¿Deberíamos proporcionar motores de alta potencia y alto esfuerzo de torsión que brinden una buena patada pero que sean pesados ​​y consuman más energía?
• ¿O es mejor proporcionar una asistencia gradual para evitar que los usuarios suden, reduciendo la carga utilizada y manteniendo nuestra operación más sostenible desde el punto de vista medioambiental y económico?

Hemos realizado múltiples simulaciones del sistema de propulsión, pero necesitamos confirmar cómo funciona en el mundo real. También esperamos ver las características del vehículo y la experiencia de usuario, la optimización del mantenimiento y muchas más variables. Con las pruebas A/B para hardware, podemos entregar los mejores vehículos para nuestros usuarios, al mejor precio y con el mejor rendimiento para nuestras ciudades.

Si estás interesado en unirte a un equipo en Lyft, ¡estamos contratando! Revisa nuestra página de bolsa de trabajo para más detalles.