Meilleure pratique pour affecter une variation de test A/B basée sur l'adresse IP

Question

Je commence à écrire du code pour le test A/B dans une application Web Grails. Je veux m'assurer que les demandes provenant de la même adresse IP voient toujours la même variation. Plutôt que de stocker une carte de IP-> variante, est-il correct de simplement transformer l'adresse IP en un entier en supprimant les points, puis l'utiliser comme la graine pour un générateur de nombres aléatoires? Ce qui suit se passe dans un filtre Grails:

def ip = request.remoteAddr 
def random = new Random(ip.replaceAll(/\./, '').toInteger()) 
def value = random.nextBoolean() 
session.assignment = value 
// value should always be the same for a given IP address 

Je sais que l'identification des utilisateurs par adresse IP ne sont pas fiables, et je vais utiliser les variables/cookies de session ainsi, mais cela semble être utile pour le cas où nous avons une nouvelle session, et aucun jeu de cookies (ou l'utilisateur a des cookies désactivés).

Answer 1

Vous pouvez simplement prendre le nombre de 32 bits et faire ip mod number_of_test_scenarios. Ou utilisez une fonction de hachage standard fournie en rubis. Mais je sens que je dois signaler quelques problèmes avec cette approche:

1. Si votre application est derrière les proxies, l'IP sera le même pour tous les utilisateurs de ce proxy.
2. Certains utilisateurs modifieront les adresses IP assez fréquemment, plus souvent que vous ne le pensez. Peut-être (comme le dit Joel Spolsky) "Internet est cassé pour ces utilisateurs", mais je dirais que c'est un mauvais service pour vos clients si vous faites de l'Internet plus brisé pour eux, surtout d'une manière subtile, étant donné qu'ils ne sont probablement pas en mesure de faire quelque chose à ce sujet.
3. Pour les utilisateurs qui ont une nouvelle session, vous pouvez simplement affecter le cookie à la première requête et conserver les affectations en mémoire; À moins que les demandes initiales d'un utilisateur ne parviennent simultanément à plusieurs serveurs, cela devrait résoudre ce problème (c'est ce que je fais sur l'application que je gère).
4. Pour les utilisateurs avec des cookies désactivés, je dirais "Internet est cassé", et je ne me ferais pas beaucoup de mal pour soutenir cette affaire; ils seraient assignés à un seau de test par défaut et tous y vont. Si vous envisagez de prendre en charge un grand nombre de ces utilisateurs d'une manière non-brisée, vous créez du travail pour vous-même, mais c'est peut-être OK. Dans ce cas, vous pouvez envisager d'utiliser la réécriture d'URL et les redirections 302 pour envoyer ces utilisateurs vers un scénario ou un autre. Cependant, à mon avis, cela ne vaut pas le temps.
5. Si vos utilisateurs peuvent se connecter au site, assurez-vous d'enregistrer les attributions de scénarios dans votre base de données et de réconcilier les écarts de cookie/db en conséquence.