如何识别拥有多个账号的用户
邀请奖励、免费套餐和单账号限制会奖励开很多账号的人。把这些账号连在一起的关联，以及如何公平地处理一个群组。
人们为什么会开多个账号
多账号，就是一个人在一个预期“一人一号”的服务上操作多个账号。动机几乎总是：有些东西是按账号发放的：
- 免费试用和免费套餐——额度用完就重新开始。
- 邀请奖励和注册奖励——自己邀请自己，两头都拿。
- 单账号限制——用量上限、每位客户一张优惠券、每个用户一票。
- 封禁——因滥用被封后卷土重来。
并不是每个第二账号都是滥用。有人有工作号和私人号，一家人会共用笔记本。好的检测能区分这些情况，而不是把每个关联都当成罪证。
把账号连在一起的关联
每个账号单独看都很干净；暴露多账号的是它们之间的联系。以下是注册时值得记录的关联，大致从强到弱：
同一个邮箱
投递到同一收件箱的两个地址——Gmail 的点号和加号变体——是最明确的关联。规范化方法见 Gmail 点号和加号别名。
同一张银行卡
支付服务商会提供卡指纹，同一卡号在不同客户之间保持一致（Stripe 称之为 card.fingerprint）。用同一张卡验证的两个账号，极有可能是同一个人。
同一台设备
一个浏览器建过一个账号、现在又建另一个，是很强的关联——除非设备是共用的。用注册页上的脚本识别它，而不是靠 IP 地址。仅靠 Cookie 在这里很弱，因为清除 Cookie 或打开无痕窗口是多账号者做的第一件事。
同一个网络
短时间内来自同一 IP 或子网的大量账号是一种模式，但 IP 会被办公室、大学和移动运营商共享。网络只能作为辅助证据。
从关联到群组
两两之间的关联很难直接使用。把它们归组：如果账号 A 与 B 共用设备，B 与 C 共用银行卡，那么 A、B、C 构成一个群组。群组的大小和构成远比单个关联更能说明问题：
| 群组 | 可能的解释 | 合理的处理 |
|---|---|---|
| 2 个账号，同一设备，邮箱和银行卡不同 | 共用电脑，或一个人的工作号和私人号 | 允许；也许不给第二次免费试用 |
| 3–5 个账号，同一邮箱的变体 | 一个人在反复重开试用 | 复核：要求绑卡或建议登录 |
| 10 个以上账号，同一设备或子网，一次性邮箱 | 脚本化的农场 | 拦截该群组的新注册 |
一个 union-find 结构，或者一列在每次出现新关联时合并的“群组 ID”，就足以让群组以注册的速度保持更新。
公平地处理一个群组
- 针对激励下手。如果滥用的是免费试用，对策是“不给第二次试用”，而不是“不给账号”。
- 留一条出路。要求绑卡或手机号，或提供付费套餐。不要因为某人的姐妹用过同一台笔记本，就把真人逼进死胡同。
- 保留证据，而不只是结论。记录是哪些关联把账号连在一起的，方便客服解释和撤销决定。
- 遵守保存期限。在很多司法辖区，设备和网络数据属于个人信息（例如依据 GDPR 或《个人信息保护法》）；只在该用途所需的时间内保存，并在隐私政策中说明。
先观察，再执行
先让检测静默运行。大约两周后，看看最大的群组，再抽查一些两个账号的群组。大的告诉你滥用有多少；小的告诉你每条规则会误伤多少真实用户。据此设定阈值。
Attrelix 的做法
每次 Attrelix 检查都会按规范化邮箱、设备，以及（如果你传入）卡指纹，把新注册与你项目中的旧账号关联起来。响应中包含关联账号数量和群组 ID，控制台会在群组页面上把它们归在一起，关联会按阶梯增加风险分——一个、三个和十个关联账号的权重逐级加大。历史记录按你套餐的期限保存。
小结
- 多账号跟着按账号发放的激励走；先找出这些激励。
- 记录关联：邮箱、银行卡、设备、网络——从强到弱。
- 把关联归成群组，按群组的大小和形态采取行动。
- 让对策匹配激励，并始终留一条出路。