Cargando...

AB Testing con infraestructura

Realizar pruebas de AB Testing o Split Testing resulta de gran utilidad para medir el impacto de un cambio en nuestra aplicación.

Se tratan de crear una bifurcación en los usuarios para mostrar una u otra versión de forma aleatoria o pseudoaleatoria.

Generalmente esto se programa desde código, determinando el destino final del cliente, es decir, si verá el archivoA.html o el archivoB.html.

Sin embargo, podemos reducir el tiempo de implementación de una solución como esta, por medio de infraestructura.

Nginx cuenta con un módulo que permite hacer el split de clientes, por lo que, si utilizamos un docker por cada bifurcación que querramos probar, podremos hacer las pruebas sin necesidad de programar nada más allá del cambio respectivo.

Es decir, en código preparamos las variaciones distintas, y claro, como somos programadores serios, esto lo tenemos en branches separadas, por lo que cada uno de los contenedores tendrá una branch distinta.

Suponiendo que tenemos un contenedor en el puerto 8081 con la variacion A de nuestro código y otro en el puerto 8082 con la variación B, lo que tenemos que hacer es que nuestro proxy Nginx, reparta a los clientes a uno u otro.

upstream @testA { server 127.0.0.1:8081; } upstream @testB{ server 127.0.0.1:8082; } split_clients "app${remote_addr}" $test_group { 50% "A"; * "B"; } server { listen 80; server_name test.net; access_log /var/log/nginx/abtest.log; error_log /var/log/nginx/abtest.log debug; location / { proxy_set_header Access-Control-Allow-Origin $http_origin; #CORS proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarder-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; if ($test_group = "A") { proxy_pass http://@testA; } if ($test_group = "B") { proxy_pass http://@testB; } proxy_redirect off; } }

Con esto los clientes se repartiran en proporciones iguales (50%) en cada contenedor.

La repartición de este ejemplo se hace de forma aleatoria en base a la dirección del cliente (${remote_addr}), sin embargo el módulo admite variables como http_user_agent y date_gmt para hacerlo en base al navegador o la fecha/hora de su visita.

Esto en conjunto a un control como Google Analytics, arrojará la información necesaria del impacto que las modificaciones tendrán en nuestra aplicación.