接着上一篇 —— 大小号设计思路（上），继续与大家分享，大小号的设计思路（下）。
大小号的讲述目录：如何定义大小号——可视化功能——预上线。（觉得内容较干的小伙伴，建议搭配蜜雪冰城阅读）
01如何定义大小号
根据上一篇收集到的用户信息，可以把信息分为：确定大小号和疑似大小号。
确定大小号：通过收集到的用户信息，发现身份信息相同、设备信息相同等，能准确判断两个账号为同一个人使用。
身份信息相同：用户在实名认证时填写的身份证信息，支付或者提现时绑定的银行卡号等等。
因为身份证、银行卡的唯一性，能非常清晰的指向同一个人。
设备信息相同：登录、下单与历史的设备号做对比。
二手车、二手房交易的很多，但是 95% 以上的人不会购买别人使用很久的二手手机，绝大多数情况下手机是跟着一个人或一个家庭在使用。
不考虑极端情况，一部手机只关联一个人，同一部手机登录多个账号，可认定为大小号。
举个栗子，在某团优选下单时，会记录下单所使用的设备号，当你在同一个手机上换一个账号下单时，会出现下方截图的提示。
疑似大小号：有些账号间的信息虽然相同，但是无法直接断定为大小号，需要更多维度的信息辅助判断。比如收货地址、登录 IP 等等。
收货地址相同：网购时都需要填写收货地址，当两个用户的收货地址相同时，需要基于场景去判断。
比如很多人会把快递寄到公司，下班拿回家。也有很多快递不会送上门，需要在指定地点领取，导致用户填写的收货地址只有小区名称。
IP 相同：适用所有行业的产品，在用户注册、登录、访问首页时，获取用户的 IP 地址，辨识出相同信息。
IP 出现相同场景很容易，我们去餐馆吃饭时，为了省流量会使用餐馆的无线网。
虽然一条疑似大小号的信息无法断定，但是当有多条相同信息时，就比较容易判断。
02可视化功能
管理后台中，需要把大小号列表与用户列表分开展示，这样功能相对干净，可拓展性强。
完成功能至少需要 4 个列表（相同账号、疑似账号、剔除相同账号、剔除疑似账号）和一些操作。
4 个列表需要与用户信息关联，记录用户ID、注册时间、最近登录时间等等，做到方便查阅和可跳转。
列表的数据需要打标签，比如疑似账号列表中， 用户 A 因为登录时的 IP，与用户 B 相同，可以查看此 IP 下所有的相同用户。
相同账号列表作用：通过相同信息确定为大小号，记录在这个列表，作为大小号的池子，可用于后续接入用户权限系统。
当然系统的规则判断不一定准确，还需要 “解除大小号” 和 “加入大小号” 的操作，人工干预增加大小号池子的灵活性。
疑似账号列表作用：命中了疑似大小号的信息，记录在这个列表，是进一步确定大小号的备用池子。
运营人员对这个列表操作会比较多，操作人员根据其他的用户信息判断是否为大小号，列表需要有 “确认大小号” 和 “解除疑似账号” 的操作。
剔除相同账号和剔除疑似账号：顾名思义被人工解除嫌疑的账号，会流转到这个池子，是给操作人员反悔用的。
账号使用一段时间后，运营人员发现，已经被排除嫌疑的账号，确实为大小号，还可以再添加进来。
03预上线
以上步骤走完，就可以投入开发。
但开发完毕，就直接上线使用吗？
在投入使用之前，还有一个过度环节，目的是验证大小号系统的准确性。
具体操作：
1. 开发完毕上线后，只做数据采集和打标签，收集 1 周左右的数据；
2. 重点关注“相同账号列表”，抽样验证，系统判定为大小号的用户是否正确，需要设定一个通过指标，比如系统判定错误率小于 5%；
3. 根据结果进行优化（一般控制都是太死了，误杀了部分用户），把之前判断为“相同账号”的数据，变为“疑似账号”的数据等。
反复几次，直到通过设定的指标，就可以与用户权限系统打通，控制用户的登录、下单、领取福利等。
注意：在需求评审环节，一定要给团队预防针，告诉他们开发完毕后，需要多次调整才能正式使用。不然你的专业度会被质疑，团队士气也因此被消耗。
看完之后，是不是觉得很像警匪片中，确定嫌疑人的过程。
