Cómo configurar un entorno experimental para el desarrollo de productos basados en datos

Como propietario de un producto, es común enfrentarse a la pregunta de si proceder con la opción A o la opción B. O, ¿qué versión de la pantalla se debe implementar para lograr mejores resultados? Tomar tales decisiones puede ser un desafío, especialmente cuando tiene plazos ajustados con recursos limitados. Además, tales decisiones se toman con base en el juicio personal o copiando el enfoque de un competidor, lo que puede conducir a resultados subóptimos.

La buena noticia es que uno puede evitar tales trampas configurando un entorno de experimento simple que requiere un esfuerzo relativamente bajo. En este artículo, describiremos cómo puede lograr esto.

Tabla de contenido

• Por qué es importante configurar un entorno de experimentación.
• mitos
• Configuración del entorno de su experimento
  • Definición del objetivo de su futuro experimento
  • Diseño de la arquitectura de su entorno de experimentación
  • Análisis e interpretación de los resultados.
  • Ampliación de la opción preferida.
• Conclusión.

¿Por qué es importante configurar un entorno experimental?

Configurar un entorno de experimento es importante por dos razones:

• En primer lugar, le permite asegurarse de que una vez que implemente una nueva funcionalidad, elija la mejor opción en función de un enfoque basado en datos.

  
  

• En segundo lugar, le permite mejorar continuamente la funcionalidad existente de su producto al comparar las opciones 'tal cual' con las hipotéticas 'futuras' y hacer un análisis de 'qué pasaría si'.

mitos

Antes de continuar con el enfoque, desacreditemos algunos de los mitos que suelen confundir a los propietarios de productos:

Necesito muchos recursos para configurar un entorno complejo que permita hacer experimentos y pruebas A/B

Incorrecto : el enfoque descrito requiere menos de una semana de los recursos de su ingeniero de software.

Necesito un proceso de recopilación de datos bien establecido y un seguimiento detallado de eventos

Incorrecto : puede confiar en una base de datos existente que almacena información sobre el ciclo de vida de la entidad principal de su producto. Por ejemplo, los estados de los pedidos si es un servicio de entrega.

Necesito un equipo dedicado de analistas que manejará mis solicitudes diariamente

Incorrecto : una vez que comprenda el enfoque y las métricas de su experimento, puede extraer datos usted mismo con regularidad mediante una consulta SQL simple.

Acercarse

Para configurar el entorno de su experimento, se recomienda seguir estos pasos:

1. Defina el objetivo de su experimento futuro, comprenda las opciones y elija métricas

Antes de comunicarse con su diseñador de productos, defina los objetivos y las métricas que se medirán como parte de su experimento. En el caso de una pregunta clásica de 'Opción A u Opción B', generalmente es sencillo lo que desea lograr al implementar un cambio. Por ejemplo, podría estar abordando una parte específica del embudo.

Para fines ilustrativos, supongamos que está trabajando en una empresa de entrega y actualmente se enfoca en el formulario de creación de pedidos. Desea dirigirse a un porcentaje relativamente bajo de usuarios que proporcionan su dirección de envío y luego seleccionan un método de envío. Además, imagina que tienes dos nuevas versiones del viaje:

1. Versión actual : una pantalla requiere ingresar direcciones y mostrar el mapa con un pin basado en la dirección proporcionada. La siguiente pantalla permite seleccionar un método de envío basado en la dirección proporcionada.

   
   

2. Nueva versión : la pantalla única requiere ingresar la dirección y seleccionar el método de envío allí.

El objetivo es determinar cuál de las opciones conduce a una mayor proporción de usuarios que proporcionaron su dirección y seleccionaron un método de envío. Las métricas son bastante sencillas: % de los usuarios que proporcionaron su dirección y seleccionaron un método de envío.

De hecho, hay 2 formas de medir estos datos :

1. Basado en los datos que ya están disponibles por el diseño de su backend . Por ejemplo, considere una base de datos que tenga información sobre el ciclo de vida del pedido. Su pedido podría tener estados o estados como:

   
   

   1. Borrador creado

   2. Intento de encontrar métodos de envío

   3. Opciones de envío encontradas/ Opciones de envío no encontradas

      
      

2. Seguimiento de eventos : esto no es algo que funcione de inmediato y, por lo tanto, requiere un esfuerzo adicional para implementarlo. Sin embargo, el seguimiento de eventos le permitirá realizar un análisis más granular, por ejemplo, el tipo de dispositivo y el nombre del navegador se pueden pasar como parámetro de sus eventos.

En las próximas secciones de este artículo, nos centraremos en el primer enfoque, es decir, la arquitectura de datos existente, sin seguimiento de eventos.

2. Diseñe la arquitectura de su entorno de experimentación

Se deben completar 2 pasos principales dentro del flujo del experimento:

• Crear un experimento con parámetros seleccionados
• Defina una etapa del viaje del usuario en la que el usuario debe ser asignado a cualquiera de los grupos y asegúrese de que se muestre la interfaz de usuario relevante como resultado

Crear un experimento:

La idea es crear un marco de prueba A/B liviano que sea lo más simple posible y que le permita crear experimentos con los siguientes parámetros:

• Identificación del experimento
• Muestra máxima
• Número y nombres de cada grupo
• Probabilidad de caer en cada grupo

Poder configurar estos parámetros le permite establecer un límite de muestra y elegir los candidatos para el experimento de forma aleatoria hasta alcanzar el tamaño de muestra deseado.

Tanto el cliente como el servidor necesitan cambios para esto: el servidor debe rastrear la cantidad de candidatos por experimento y el backend decidirá si el usuario actual debe ser parte de un experimento o no. El backend decidirá si el usuario autenticado debe ser parte del experimento en función del tamaño de la muestra actual y de una probabilidad fija. Además, el backend debe mantener una colección de usuarios que forman parte de un experimento determinado para proporcionar experiencias consistentes a los usuarios y calcular correctamente los resultados del experimento.

Así es como podría verse el punto final para la configuración del experimento:

POST /api/your-service/experiment-create

Pedido:

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

Respuesta:

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Decidir cuándo y cómo se debe asignar el usuario a los grupos experimentales:

Necesitará un punto final separado que será responsable de asignar un usuario específico al experimento y al grupo correspondiente. Llamémoslo experiment-enrollments .

Al diseñar todo el entorno, debe comprender claramente en qué etapa del recorrido del usuario se debe llamar al extremo de experiment-enrollments . Además, puede darse el caso de que no todos los usuarios deban participar en el experimento. Es por eso que también sería útil proporcionar un token de autenticación de usuario en un punto final.

En nuestro ejemplo, si queremos centrarnos solo en los nuevos usuarios que están haciendo su primer pedido, user-auth nos permitirá determinar qué tipo de usuario es y si uno debe inscribirse en el experimento. Además, asegúrese de que una vez que se llame al punto final, toda la información necesaria esté disponible y considere los detalles de su viaje y ciclo de vida.

El punto final experiment-enrollments se describe a continuación. Se puede llamar en una etapa específica del viaje (por ejemplo, antes de aterrizar en la pantalla que solicita la dirección de envío) para tipos específicos de usuarios (por ejemplo, solo usuarios nuevos que aún no han proporcionado la dirección) y calculará si el usuario actual debe participar en un experimento dado o no:

POST /api/your-service/experiment-enrollments , se requiere token de autenticación de usuario

Pedido:

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Respuesta:

 {200, enrolled: true/false, group_name: group_1,}

Para ilustrar cómo se vería el flujo de datos teórico, suponga el mismo ejemplo de flujo de creación de pedidos en la empresa de entrega. Estás seleccionando entre 2 opciones de pantalla de creación de pedidos.

Los siguientes puntos finales se mencionan en el siguiente diagrama, es decir:

• /crear-pedido-borrador (paso 3)

• /buscar-método-de-envío (paso 16)

• /enviar-pedido (paso 20)

  
  

se proporcionan para respaldar el ejemplo ilustrativo y no son partes necesarias del entorno del experimento

Además, a continuación se proporciona la arquitectura ilustrativa y simplificada de las bases de datos.

Hay 3 tablas principales:

1. Experiments set : contiene todos los experimentos que creó anteriormente. La base de datos se actualiza cada vez que llama al punto final /experiment-create .

   
   

2. Experiments database : contiene todos los registros asociados con cada inscripción de un usuario específico. La base de datos se actualiza cada vez que llama al extremo experiment-enrollments

   
   

3. Order lifecycle database : se proporciona para respaldar el ejemplo ilustrado de cómo se pueden almacenar los datos relacionados con el experimento. El punto es que esta tabla (o cualquier tabla similar que corresponda a las especificaciones de su producto) le permitirá ver si la entrada (por ejemplo, la creación del pedido) fue exitosa o no para el usuario específico inscrito en uno de los grupos experimentales que usted he establecido. En nuestro ejemplo, podemos confiar en el estado Método de envío seleccionado que permite concluir que el usuario proporcionó correctamente los detalles de envío y luego seleccionó uno de los métodos de envío sugeridos.

   
   

   
   

Descripción general del enfoque de diseño e implementación

Ventajas:

1. La muestra resultante es heterogénea.
2. El tamaño de la muestra se conoce por adelantado.
3. Los resultados se pueden calcular rápidamente, dependiendo de la probabilidad de muestreo fija

Contras:

1. Requiere cambios de frontend y backend
2. El cálculo de los resultados se basará en varias bases de datos, algunas de las cuales no pudieron diseñarse inicialmente con fines analíticos.

Tareas y estimaciones indicativas:

• [ ] undefined [Backend] Crear un modelo y exponer el punto final del contador de recuperación: ~2 puntos de historia
• [ ] undefined [Backend] Expone el punto final del contador de incrementos: ~2 puntos de historia
• [ ] undefined [Backend] Exponer puntos finales para obtener e incrementar el contador: ~1 punto de historia
• [ ] undefined [Frontend] Puntos finales de contador de llamadas para cambiar entre flujos de registro: ~3 puntos de historia

Una vez que haya diseñado su backend, alinee con su equipo de frontend sobre la mejor manera para que reciban la información y en qué etapa del flujo.

Tenga en cuenta y mitigue las principales dependencias :

• Asegúrese de que sus equipos estén alineados en un contrato por adelantado para que la parte frontal se pueda implementar en paralelo con el backend.
• Trate de evitar que su interfaz sea bloqueada hasta que todo el backend esté terminado
• Independientemente del entorno del experimento, todas las opciones de la interfaz de usuario deben implementarse de todos modos.

3. Análisis e interpretación de los resultados

Una vez que su experimento ha estado funcionando durante un tiempo suficiente, es importante analizar e interpretar los resultados para sacar conclusiones significativas.

Defina la lista de campos que necesita para calcular el impacto en las métricas en las que decidió centrarse anteriormente.

Del ejemplo ilustrativo anterior, las fuentes de datos serían 2 tablas:

• Experiments database :

  • Entrada : ID de experimento para el que está buscando resultados

  • Salida : lista de todos los ID de usuario que son participantes de un experimento específico, el grupo al que se asignó cada usuario y la marca de tiempo cuando se asignó el usuario

    
    

• Order lifecycle database
  • Entrada : lista de usuarios que están dentro del alcance de su experimento y marca de tiempo cuando se inscribieron para experimentar
  • Salida : estados finales de todos los pedidos que están asociados con estos usuarios y se procesaron después de que el usuario se inscribió para experimentar

En función de estos datos, puede calcular el porcentaje de pedidos creados con éxito para cada uno de los grupos de experimentos.

Al analizar sus resultados, es importante mirar más allá de los números en bruto. También querrá buscar la significación estadística para asegurarse de que cualquier diferencia que observe entre sus grupos de prueba no se deba solo al azar. No me centraré demasiado en esta parte porque ya veo muchos artículos relacionados con este tema en este y otros recursos en línea. De todos modos, no se requiere un conocimiento excesivo aquí: en mi opinión, sería suficiente poder aplicar Z-Test o T-Test para verificar la importancia de la diferencia entre los 2 grupos.

Sin embargo, una vez que haya determinado que sus resultados son estadísticamente significativos, puede comenzar a sacar conclusiones sobre qué opción de su producto funcionó mejor.

4. Ampliación de la opción preferida

Después de ejecutar con éxito un experimento y obtener un grado suficiente de confianza con respecto a la mejor opción, el siguiente paso es ampliar los cambios en todo el producto. Puede haber varios enfoques:

• La más fácil es ajustar la configuración de su experimento para que el 100% de los usuarios se ubique en el grupo que muestre mejores resultados . Deberá reservar algo de tiempo para limpiar el código en el futuro, de modo que la visualización de esta parte específica de la interfaz de usuario sea independiente del entorno del experimento.

  
  

• La menos sencilla es si su producto está disponible en múltiples plataformas. Tenga mucho cuidado al suponer que los resultados de los experimentos en el flujo web se aplican al flujo de la aplicación móvil (y viceversa). A veces es mejor prevenir que lamentar y ejecutar un experimento separado de manera similar, pero en otra plataforma.

Para concluir

Tener su propio entorno de experimentación es una herramienta muy útil para cualquier gerente de producto. Independientemente de en qué etapa de madurez se encuentre su producto actual, la creación de un entorno experimental no debería llevar demasiado tiempo. Pagar un costo único bastante bajo para que funcione le mostrará con bastante rapidez el retorno de la inversión.

Finalmente, aquí hay algunos consejos para asegurarse de que los resultados del experimento tengan sentido:

• En primer lugar, comprenda qué métricas se verán afectadas (si las hay) al implementar el cambio que está considerando.
• Defina claramente sus objetivos y métricas antes de comenzar su experimento
• Mantenga su experimento lo más simple posible, centrándose en un cambio clave a la vez
• Tenga cuidado al considerar la extrapolación de los resultados de su experimento en otras plataformas u otros servicios similares
  

Al seguir estas prácticas recomendadas, puede configurar un entorno de experimentación efectivo que puede ayudarlo a tomar decisiones basadas en datos e impulsar sus tasas de conversión a lo largo del tiempo.