A/B testing en el borde

El siguiente post está basado en la charla de Chris en Altitude, nuestra conferencia para clientes. Puedes leer el resumen completo aquí.

Cuando realizas un cambio en un sistema —ya sea a nivel de diseño, código o infraestructura—, es importante saber que estás logrando el resultado deseado. Quieres que tus decisiones de negocio se basen en datos y una de las mejores formas de obtenerlos es a través de los test A/B.

El A/B testing puede ser tan simple o complicado como quieras. Puedes construir elaborados test multivariable con frameworks o usar diversas herramientas comerciales para configurar pruebas, ya sea en el lado del servidor o en el del cliente. A veces, solo necesitas realizar un comprobación rápida para validar que un cambio no ha empeorado nada, incluso puede que lo que estás buscando detectar sea precisamente la falta de cambios. En cualquier caso, no lo sabrás con seguridad hasta que lo compruebes.

A/B testing en el borde

En Fastly nos encanta trabajar en el edge, más cerca de los usuarios, ya sea para extender al máximo tu aplicación en el borde de nuestra red o para enfocarnos hacia un futuro en el que los datos y la lógica convivirán en el edge. Realizar el test A/B más cerca de tus usuarios significa que estos no sufrirán disminución del rendimiento mientras se consulta un servicio de segmentación separado y, además, previene los retrasos en el lado del cliente cuando se vuelve a presentar la página. Para lograrlo, necesitas lo siguiente:

1. Hacer una segmentación de los usuarios en diferentes grupos

2. Persistir en esas decisiones a lo largo de todas las sesiones, para que los usuarios que regresan obtengan la misma experiencia

3. Mantener copias diferenciadas de los objetos en caché para que cada usuario obtenga de inmediato el contenido correcto

Todo esto puede hacerse en el edge, de modo que lo único que el servidor tiene que hacer es crear una copia de cada variante. Eso es todo.

Supón que estás creando dos versiones distintas de tu página de inicio: una con fondo verde y otra con fondo azul. Quieres que el 10% de los usuarios vean la del fondo verde. A continuación, monitorizarás tus herramientas de análisis para ver si el comportamiento del usuario cambia, ya sea a nivel de conversiones, tasa de rebote o cualquier otra métrica que te interese.

Segmentación

Primero, debemos situar a los usuarios en los cubos correctos. Para ello usaremos la función randombool. Luego, dependiendo de nuestra decisión, estableceremos un encabezado dirigido hacia el servidor para que este sepa qué versión debe mostrarnos.

Persistencia

Ahora tenemos que recordar esta decisión para los usuarios que regresen al sitio web, de modo que ninguno vea que el estilo de la página de inicio va cambiando aleatoriamente de la versión verde a la azul. Para esto podemos usar una cookie, comprobando y usando el valor existente si ya está creado, y estableciéndolo en caso de que no lo esté:

Mantener diferentes versiones almacenadas en caché con HTTP Vary

Deberás mantener ambas versiones almacenadas en caché para garantizar que la carga de la página sea rápida para todos los usuarios, y también para asegurarte de que cada usuario está viendo la versión correcta. De forma predeterminada, Fastly considera que un objeto es único si tiene el mismo nombre de host y dirección URL.

Esas dos páginas de inicio, la verde y la azul, parecerían el mismo objeto, por lo que necesitamos usar el encabezado HTTP Vary para mantenerlas separadas. Vary es una indicación del servidor para señalar al almacenamiento en caché qué otras propiedades debe considerar como un objeto distinto. Ten en cuenta que esto no cambia el embrollo, así que una sola purga se deshará de todas las variantes a la vez.

El servidor podría establecer ese encabezado de respuesta de la siguiente manera:

Vary: Accept-Encoding, X-Homepage

Si no quieres agregar este encabezado en tu servidor, puedes hacer que Fastly lo inserte en la respuesta del servidor. Vamos a actualizar nuestro ejemplo para añadir el encabezado Vary en la respuesta. Podemos hacerlo en la fase de recuperación de datos:

Hacer el test A/B en diferentes back-end

Puedes usar las mismas técnicas para elegir un back-end diferente, por ejemplo, si deseas enviar el uno por ciento del tráfico a una nueva versión de tu sitio.

Persistencia sin cookies (y erratas importantes)

Para terminar, quiero corregir algo que dije en mi charla sobre el test A/B en Altitude. Si deseas utilizar las mismas técnicas sin cookies, puedes crear algo único para segmentar los diferentes usuarios.

Sugerí hacer algo así para mantener la persistencia sin cookies:

set req.http.X-ClientIDHash = digest.hash_md5(client.ip req.http.User-Agent)
set req.http.X-ClientID = std.strtol(req.http.X-ClientIDHash,16)

# e.g. 9223372036854775807

if (randombool_seeded(5,100,std.atoi(req.http.X-ClientID))) {
  set req.http.X-FastAB = "B";
} else {
  set req.http.X-FastAB = "A";
}

Esto funciona la mayoría de las veces, pero una función requiere un ajuste. En algunos casos, la creación de un hash de diferentes propiedades hace que el número utilizado como valor semilla sea demasiado grande. Solo tenemos que recortarlo, así que puedes hacer lo siguiente:

set req.http.X-ClientIDHash = digest.hash_md5(client.ip req.http.User-Agent);
set req.http.X-ClientIDHash-trimmed = regsub(req.http.X-ClientIDHash, "^([a-fA-F0-9]{10}).*$","\1");
set req.http.X-ClientID = std.strtol(req.http.X-ClientIDHash-trimmed, 16); 

Sigue siendo único y suficientemente bueno para mantener la decisión de segmentación.

Algunos de nuestros clientes (como Good Eggs) han usado estas técnicas para construir lógicas muy elaboradas en el edge, incluso han creado herramientas internas para que sus usuarios puedan controlar directamente las cargas y las pruebas.

Si has usado Fastly de alguna manera interesante, nos encantaría que nos lo contaras. Dirígete a nuestro foro de la comunidad para dar a conocer tu trabajo.

Reproduce el vídeo de la charla de Chris a continuación y no te pierdas otros artículos de Altitude.