浅析大小 系统的设计思路

由于公司业务需要，最近在设计大小 的判断系统，但 上几乎没有查到相关的资料。我打算把整个摸索过来的过程，总结一下，希望对后来者有所帮助。

如果你是在某平台多账 运营的人员，也可以通过产品设计思路，想办法怎么规避被识别成大小 风险。

一、适用场景

电商行业和游戏行业，为了节省运营成本；购票、医疗、银行和保险行业，为了提升用户体验；短视频行业，为了更公平的流量扶持等等。

我们来看下电商行业的新人福利和视频行业的流量扶持，两个场景下的需求。

场景一：电商行业，节省拉新成本

近两年抖音和快手通过直播卖货，在快速发展自己的电商和支付业务。如果你第一次使用抖音支付，可以 1 分钱购买价值 10 元的商品。快手基本上也是如此。

在直播带货的元年（ 2020 年），还上演一场 区团购的补贴大战，新用户 1 分钱可以购买一篮子菜。

还有被称为“民族之光”，割资本主义“韭菜”的瑞幸，新人注册即可免费喝咖啡吃轻食。

以上都属于电商行业的新人福利。

作为用户：用户心里是，免费的不搞白不搞，薅羊毛可是我们的最爱，毕竟大多数人都有两个及以上的手机 。

作为平台：希望控制拉新和留存成本，能 10 块钱搞进来的用户，为什么还要花 20 、 30 呢?

场景二：短视频行业，公平的流量扶持

这种场景没有第一种效果来的直接，但是长久下来，可以构建更良好的创作生态，产品成长的更健康。

现在有很多人选择短视频创业，在某一个细分领域进行创作，从而获得流量和影响力，以此变现。

需求和场景很明确，平台该如何设计功能呢?

二、信息收集

用户信息采集分两种：第一种是用户行为数据，第二种是用户自主维护信息。

第一种：用户行为数据

获取 APP 注册用户，在平台访问时的基本行为数据，比如最近登录时间、每日访问时长等。

哪些行为数据对判断大小 有用呢？

比如：IP 信息（注册、访问首页所使用的 IP ）、设备 （领取新人福利时记录设备 ）等。

第二种：用户自主维护信息

收集用户维护的身份信息数据，从身份信息去判断账 之间的关系。

银行卡：产品内含有支付相关的功能，并且需要绑定银行卡；

身份证：招聘软件需要让招聘者和求职者的信息更加真实，会增加实名认证的功能。银行产品、证券交易产品也都需要实名认证；

收货地址：电商产品需要维护收获地址，才能寄出包裹。

产品不同，能收集到的用户信息也不同。我们需要让开发把这些数据存储下来，用于后续分析和使用。

三、如何定义大小

根据上一篇收集到的用户信息，可以把信息分为：确定大小 和疑似大小 。

确定大小 ：通过收集到的用户信息，发现身份信息相同、设备信息相同等，能准确判断两个账 为同一个人使用。

身份信息相同：用户在实名认证时填写的身份证信息，支付或者提现时绑定的银行卡 等等。

因为身份证、银行卡的唯一性，能非常清晰的指向同一个人。

设备信息相同：登录、下单与历史的设备 做对比。

二手车、二手房交易的很多，但是 95% 以上的人不会购买别人使用很久的二手手机，绝大多数情况下手机是跟着一个人或一个家庭在使用。

不考虑极端情况，一部手机只关联一个人，同一部手机登录多个账 ，可认定为大小 。

举个栗子，在某团优选下单时，会记录下单所使用的设备 ，当你在同一个手机上换一个账 下单时，会出现下方截图的提示。

疑似大小 ：有些账 间的信息虽然相同，但是无法直接断定为大小 ，需要更多维度的信息辅助判断。比如收货地址、登录 IP 等等。

收货地址相同： 购时都需要填写收货地址，当两个用户的收货地址相同时，需要基于场景去判断。

比如很多人会把快递寄到公司，下班拿回家。也有很多快递不会送上门，需要在指定地点领取，导致用户填写的收货地址只有小区名称。

IP 相同：适用所有行业的产品，在用户注册、登录、访问首页时，获取用户的 IP 地址，辨识出相同信息。

IP 出现相同场景很容易，我们去餐馆吃饭时，为了省流量会使用餐馆的无线 。

虽然一条疑似大小 的信息无法断定，但是当有多条相同信息时，就比较容易判断。

四、可视化功能

管理后台中，需要把大小 列表与用户列表分开展示，这样功能相对干净，可拓展性强。

完成功能至少需要 4 个列表（相同账 、疑似账 、剔除相同账 、剔除疑似账 ）和一些操作。

4 个列表需要与用户信息关联，记录用户ID、注册时间、最近登录时间等等，做到方便查阅和可跳转。

列表的数据需要打标签，比如疑似账 列表中， 用户 A 因为登录时的 IP，与用户 B 相同，可以查看此 IP 下所有的相同用户。

相同账 列表作用：通过相同信息确定为大小 ，记录在这个列表，作为大小 的池子，可用于后续接入用户权限系统。

当然系统的规则判断不一定准确，还需要 “解除大小 ” 和 “加入大小 ” 的操作，人工干预增加大小 池子的灵活性。

疑似账 列表作用：命中了疑似大小 的信息，记录在这个列表，是进一步确定大小 的备用池子。

运营人员对这个列表操作会比较多，操作人员根据其他的用户信息判断是否为大小 ，列表需要有 “确认大小 ” 和 “解除疑似账 ” 的操作。

剔除相同账 和剔除疑似账 ：顾名思义被人工解除嫌疑的账 ，会流转到这个池子，是给操作人员反悔用的。

账 使用一段时间后，运营人员发现，已经被排除嫌疑的账 ，确实为大小 ，还可以再添加进来。

五、预上线

以上步骤走完，就可以投入开发。但开发完毕，就直接上线使用吗？在投入使用之前，还有一个过度环节，目的是验证大小 系统的准确性。

具体操作：

反复几次，直到通过设定的指标，就可以与用户权限系统打通，控制用户的登录、下单、领取福利等。

注意：在需求评审环节，一定要给团队预防针，告诉他们开发完毕后，需要多次调整才能正式使用。不然你的专业度会被质疑，团队士气也因此被消耗。

看完之后，是不是觉得很像警匪片中，确定嫌疑人的过程。

题图来自Unsplash，基于CC0协议