Pruebas A/B

Las pruebas A/B o técnica de implementación de valores controlados permiten a los desarrolladores experimentar con dos o más variantes de una página web. Las variantes se muestran aleatoriamente a los usuarios y, a continuación, se utiliza un análisis estadístico para determinar qué variante funciona mejor para un objetivo empresarial determinado. Por ejemplo, se puede probar una variante de la interfaz de usuario de una página de producto con el objetivo de aumentar las ventas del producto.

Las pruebas A/B pueden aplicarse de distintas maneras en función de los requisitos técnicos y empresariales. Una de las principales decisiones técnicas es dónde ejecutar la lógica de selección de variantes: en el cliente, en el servidor de periferia (por CDN) o en el servidor de origen.

Selección de variantes en el servidor de origen. En este enfoque, la selección A/B se ejecuta directamente en el servidor de origen que aloja la aplicación web. Aunque este enfoque es independiente de la CDN, es incompatible con el almacenamiento en caché de la CDN o con el alojamiento de archivos estáticos. Es una opción para aplicaciones web renderizadas en el servidor que son completamente dinámicas.

Selección de variantes en el servidor de periferia. En este enfoque, se toma la decisión de selección de variantes en la CDN. Para este enfoque, los cambios en la aplicación son mínimos o nulos y es compatible con el almacenamiento en caché de la CDN. En CloudFront, puede implementar la lógica de las pruebas A/B mediante funciones periféricas. Una función de periferia puede utilizar los atributos de la solicitud (país, cookie, etc.), además de la API de pruebas A/B externa para seleccionar una de las variantes y hacer que CloudFront la entregue desde la caché.

Selección de variantes del cliente. En este enfoque, el frontend hace primero una solicitud a una API de pruebas A/B para decidir qué variante se debe servir y, a continuación, en función de la respuesta, descarga la variante y la renderiza en el navegador. Con este enfoque, las pruebas A/B son independientes de la CDN, pero están estrechamente vinculadas a la aplicación e introducen latencia adicional debido a los pasos adicionales en el cliente. Recuerde también que no siempre es una opción, como en el caso de las pruebas A/B de sitios generados estáticamente (SSG). Para implementar pruebas A/B del cliente, puede utilizar CloudWatch Evidently. Proporciona el SDK de cliente y la interfaz de usuario para controlar los experimentos de pruebas A/B. Para un tutorial práctico sobre CloudWatch Evidently, considere este taller.

Centrémonos en las pruebas A/B del servidor de periferia. Para diseñar la mejor implementación para su negocio, tenga en cuenta las siguientes preguntas:

• ¿Necesita fidelidad (por ejemplo, que el mismo usuario obtenga siempre la misma variante)? La fidelidad suele implementarse mediante cookies.
• ¿Qué parámetros se utilizan para seleccionar una variante para un usuario? País, ID de usuario, etc.
• ¿Con qué frecuencia se hacen pruebas A/B? El uso intensivo de pruebas A/B con muchos experimentos ejecutados en paralelo por diferentes equipos, requiere una implementación más sofisticada en comparación con las pruebas A/B más sencillas y ocasionales.

Para conocer algunas de las implementaciones del servicio de periferia de las pruebas A/B mediante las funciones de periferia de CloudFront, considere este taller práctico. En la siguiente sección, compartiremos dos implementaciones comunes de pruebas A/B con CloudFront, del taller mencionado anteriormente.

Para necesidades ocasionales de pruebas A/B, como la mejora trimestral del diseño de un sitio web institucional, considere una solución basada en CloudFront Functions durante el experimento. La solución se basa en dos funciones configuradas según el comportamiento de la caché que coincide con la página para la que desea ejecutar las pruebas A/B:

• Una función de solicitud del espectador que inspecciona el valor de la cookie experimental de las solicitudes entrantes y, en función de ella, reescribe la URL en la variante de página seleccionada. Si la cookie no está presente, la función selecciona la variante utilizando tu lógica personalizada, por ejemplo, un 60 % para la variante A y un 40 % para la variante B, solo para las solicitudes procedentes de Francia.
• Una función de respuesta del espectador, que establece la cookie en el cliente en función de la variante seleccionada, si la cookie aún no estaba presente. La cookie de experimento se usa para garantizar que un solo usuario reciba siempre la misma variante de la página para evitar interrumpir su experiencia web.

Para cambiar el registro de selección de variantes, por ejemplo, para aumentar el porcentaje de la variante B, es necesario actualizar el código de función del evento del visor, que normalmente tarda unos segundos en completarse. Cuando haya terminado con el experimento de pruebas A/B, puede eliminar las funciones periféricas para ahorrar costes.

Si practica continuamente las pruebas A/B en su sitio web y realiza experimentos a diario, puede seguir utilizando la solución anterior basada en CloudFront Function. Sin embargo, se recomienda desvincular los parámetros de selección de variantes (por ejemplo, los pesos de las variantes) del código de la función. Puede usar un KeyValueStore de CloudFront para almacenar dichos parámetros, fuera del código de función. El KeyValueStore es ideal como lectura global (cada PoP) y de baja latencia,
almacén de datos de valor clave a escala (millones de solicitudes por segundo).

Tenga en cuenta que su caso de uso debe respetar las cuotas de KeyValueStore, como el tamaño máximo (5 MB) o el límite de velocidad de cambio de unas pocas llamadas a la API por segundo.

Considere una solución basada en Lambda@Edge si una solución basada en CloudFront Function no satisface sus necesidades de pruebas A/B, por ejemplo, si las cuotas de KeyValueStore son limitadas para su caso de uso. Este puede ser el caso si está operando un gran sitio web de comercio electrónico, con muchos equipos que ejecutan experimentos simultáneos en diferentes partes del sitio web a gran velocidad.  En este escenario, utilice Lambda@Edge en lugar de CloudFront Function, con un origen de datos externa (por ejemplo, tablas globales de DynamoDB) para almacenar los parámetros de las pruebas A/B. Las herramientas de administración de características, como LaunchDarkly, proporcionan integraciones con DynamoDB para mantener los parámetros de las pruebas A/B.

• Taller: pruebas A/B del cliente con Evidently
• Taller: taller de pruebas A/B del servidor periférico mediante funciones de periferia de CloudFront
• Caso práctico de TrueCar: pruebas A/B del servidor periférico mediante Lambda@Edge, DynamoDB y LaunchDarkly
• Caso práctico de Ryanair: pruebas A/B del servidor periférico mediante Lambda@Edge, DynamoDB y LaunchDarkly