基于 IP 地址分配 A/B 测试变体的最佳实践

发布于 2024-08-27 01:30:29 字数 480 浏览 4 评论 0原文

我开始在 Grails Web 应用程序中编写一些用于 A/B 测试的代码。我想确保来自同一 IP 地址的请求始终看到相同的变化。不是存储 IP-> 变体的映射,而是通过删除点将 IP 地址简单地转换为整数,然后将其用作随机数生成器的种子,是否可以? 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

我知道通过 IP 地址识别用户并不可靠,我也会使用会话变量/cookie,但这对于我们有新会话的情况似乎很有用,并且没有设置cookie(或者用户禁用了cookie)。

I am starting to write some code for A/B testing in a Grails web application. I want to ensure that requests from the same IP address always see the same variation. Rather than store a map of IP->variant, is it OK to simply turn the IP address into an integer by removing the dots, then use that as the seed for a random number generator? The following is taking place in a Grails Filter:

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

I know that identifying users by IP address is not reliable, and I will be using session variables/cookies as well, but this seems to be useful for the case where we have a new session, and no cookies set (or the user has cookies disabled).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

匿名的好友 2024-09-03 01:30:29

您可以简单地获取 32 位数字并执行 ip mod number_of_test_scenarios。或者使用 ruby​​ 中提供的标准哈希函数。但我觉得我应该指出这种方法的一些问题:

  1. 如果您的应用程序位于任何代理后面,则该代理的所有用户的 IP 将是相同的。
  2. 有些用户会相当频繁地更改 IP,比您想象的更频繁。也许(正如乔尔·斯波尔斯基(Joel Spolsky)所说)“互联网对这些用户来说已经崩溃了”,但我想说,如果你让互联网对他们来说更加崩溃,特别是以一种微妙的方式,这对你的客户来说是一种伤害,因为他们可能没有能够对此采取任何行动。
  3. 对于有新会话的用户,您可以在第一次请求时分配 cookie,并将分配保留在内存中;除非用户的初始请求同时发送到多个服务器,否则这应该可以解决该问题(这就是我在我维护的应用程序上所做的)。
  4. 对于禁用 cookie 的用户,我会说“互联网坏了”,而且我不会费太多力气来支持这种情况;他们会被分配到一个默认的测试桶,然后全部都去那里。如果您计划以不间断的方式支持许多此类用户,那么您就是在为自己创造工作,但这也许没关系。在这种情况下,您可能需要考虑使用 URL 重写和 302 重定向来将这些用户发送到一种或另一种情况。但在我看来,这不值得花时间。
  5. 如果您的用户可以登录该站点,请确保您在数据库中记录了场景分配,并相应地协调了 cookie/db 差异。

You could simply take the 32-bit number and do ip mod number_of_test_scenarios. Or use a standard hashing function provided in ruby. But I feel I should point out a few problems with this approach:

  1. If your app is behind any proxies, the ip will be the same for all the users of that proxy.
  2. Some users will change IPs fairly frequently, more frequently than you think. Maybe (as Joel Spolsky says) "The internet is broken for those users", but I'd say it's a disservice to your customers if you make the internet MORE broken for them, especially in a subtle way, given that they are probably not in a position to do anything about it.
  3. For users who have a new session, you can just assign the cookie on the first request and keep the assignments in memory; unless a user's initial requests go to multiple servers at the same time this should resolve that problem (it's what I do on the app I maintain).
  4. For users with cookies disabled, I'd say "The Internet is broken", and I wouldn't go to much trouble to support that case; they'd get assigned to a default test bucket and all go there. If you plan to support many such users in a non-broken way you're creating work for yourself, but maybe that's ok. In this case you may want to consider using URL-rewriting and 302 redirects to send these users down one scenario or another. However in my opinion this isn't worth the time.
  5. If your users can log into the site make sure you record the scenario assignments in your database and reconcile the cookie/db discrepancies accordingly.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文