分辨多个用户之间是否是分身的算法？

[Grocker]

我有一个需求是为了分辨多个用户之间是否是分身（需求背景是为了防止新注册用户薅羊毛，优惠力度挺大的，是分身的用户只要一人享受了优惠，其他人不能再次享受）， 所以我要将多个用户之间人为的去关联，比如用户 A 关联了 B ，A 和 B 互为分身；用户 B 再关联了 C ，B 和 C 互为 分身，C 和 A 也互为分身，因为有中间人 B ，以此类推，中间人的层级不限，这种用推荐使用什么算法实现呢？

我自己想到的是多存数据将这种层级平铺：

当用户 A 直接关联用户 B 时，我们在 associations 表中插入两条记录：

associations 表结构：user_id 关联用户 ID ，associated_user_id：被关联用户 ID ，is_direct：是否是直接关联

INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (A 的用户 ID, B 的用户 ID, TRUE);
INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (B 的用户 ID, A 的用户 ID, TRUE);

当用户 B 再直接关联用户 C 时，不仅插入 B 和 C 之间的直接关联记录，还插入 A 和 C 之间的间接关联记录：

INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (B 的用户 ID, C 的用户 ID, TRUE);
INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (C 的用户 ID, B 的用户 ID, TRUE);
INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (A 的用户 ID, C 的用户 ID, FALSE);
INSERT INTO associations (user_id, associated_user_id, is_direct) VALUES (C 的用户 ID, A 的用户 ID, FALSE);

需要用到的场景有： 取消关联某两个用户之间的关联 查询给定用户的所有分身

[murmur]

别需求了，现在只能实名制，有多少黑产专门卖抹指纹的手机

我看到的下面都是不知所云

最核心的用户特征辨别方法都没有

[Grocker]

@murmur 辨别方法是线下，因为业务人员知道哪些人之间存在关联关系

[murmur]

@Grocker 你最好在仔细想一下常见，设备指纹、实名制，这两个最常用的方法你不用

那你有没有想过线下业务推广人员勾结撸公司羊毛

你这需求我真看不懂。。。

[Grocker]

@murmur 我们场景不一样，是线下教育机构

[TArysiyehua]

楼上说的对，其实光实名都不太行，之前我待的一家公司就是，实名+手机号才能过的账号，也被黑产刷了一大波。关键就是黑产手上有无数个号。
后来不得不限定只有用户我们的产品才能薅羊毛（就是你必须有类似于购买或者消费记录），这样来说这样的用户是肯定能满足的。
不过这一套又不能用在拉新身上，因为新人他是不会有任何购买或者消费记录的，这样就不得不再设计一套类似于现在很多 app 这样，可以让你信号注册领羊毛，但是变现不了，只能用于消费。（类似于朴朴，淘宝这样的拉新）

当然如果你的优惠是针对虚拟的东西，这又不一样了。。。

总之一个铁律：不能提现，变现。最好能跟产品商品绑定，优惠下来，哪怕不挣钱，甚至亏一点点，但是产品还是卖了，也不亏。

[Grocker]

所有用户事先都已实名了，比如有个宝宝，用他妈妈的账号注册了，去买了个低价课，上完后，又用他爸爸的账号注册了再去买了个低价课，就是为了避免这种情况

[veni2023]

技术上能实现的话,用户体验肯定非常差

[wuud]

@Grocker #6 如果这个宝宝用他妈妈的手机和身份、他爸爸的手机和身份，这个应该怎么分辨。同好奇，有答案麻烦踢一下

[Grocker]

@wuud 其实分辨不是这个问题的重点，主要是问算法 😄

我们的业务模式是线下，上课的娃始终没变，自然知道哪些账号之间是存在关联的了

[hi909]

用树形结构，在数据库中加个 path 字段，例如 A/B/C/D ，就表示 D 的上级是 C 。就和文件夹一样。

[Unicornvic]

@Grocker 如果“上课的娃始终没变”，那么签协议的时候设置一下主体，判断一下唯一可行吗

[hi909]

或者可以增加一个 customer group ，每个上课的人都需要有一个 group 。 他爸妈的账号也要关联在这个 group 里。

[meilicat]

并查集

[saberlove]

填写娃儿的身份证

[zizon]

你想想面向对象编程里子类和父类的关系.

[wangxiaoer]

感觉图数据库很合适拿来用用。

[xabcstack]

你需要的是账号遗传 DNA 的算法

[Crit]

保留 associations 表，同时使用另一个表来记录每个用户的所属分量。遍历 associations 表中的用户，有直接关联的两个用户属于同一分量，通过并查集将他们合并到同一个合集。这样可以吗？

[docx]

同一设备，同一手机号，同一实名，同一支付方式满足其一即为同一用户

照着那些办羊毛活动的来准没错，他们都是被薅过有经验的

[alphaControler]

楼主，你搜搜并查集算法。有树的路径压缩

[alphaControler]

@alphaControler 如果需要权重，那就搜带权并查集

[null113]

并查集，求连通分支数，数据库的话就想办法生成一个唯一 id

[xiangyuecn]

研究什么算法，直接一条一条查完事，查 100 次也不是什么事

[MoYi123]

并查集的删除不太好做. 还是用 sql 的递归来实现 dfs 硬查吧, 看起来数据量不会很大.

[snailya]

@hi909 我觉得你说的对

[tianhehechu]

看了一圈，V 友们给出的方案要么太麻烦，要么达不到效果。用我这个方案就行了。
我的方案很简单，换个思路。不要去想着防止同一个人用多个账号登录，你要先假设系统中所有账号都是同一个人（未识别账号）。
接下来要做的就是从这些未识别账号中，识别出不是同一个人的。其余的一律提示：活动尚未对您开放。
如何识别出不是同一个人的账号呢，分事先预防和事后校验。
事先预防，就是注册账号时，用户名必须是有意义的字符串，只需要这一条，剩下的不需要。
事后校验，就是提现时要求输入信用卡号和 CVC 、校验人脸。信用卡信息不符、人脸校验不通过直接封 IP 、封设备指纹（并撤销同 IP 、同设备指纹所有用户的参与资格，已获得且未提现的归零，此操作只需把这些用户一并归入未识别用户）。未识别用户登录时，若此前已体现但资格被撤销，则要求从信用卡扣款返还费用方可继续使用。对于同一设备指纹的其他用户，也作相同提示：该设备中有欺诈用户尚未返还非法所得，已禁止当前设备所有用户使用，返还非法所得后将解除限制。

[Grocker]

@hi909 我觉得这种也是最简便的，比如 A 关联 B ，group 是 1 ，B 关联 C ，查询到他有 customer group 了，把它也放在 group 1 就行了

[dyllen]

你这个数据库设计相当于把账号关联穷举存在了数据库。删除两个数据，需要把直接或者间接的也全找出来删掉，这那里是什么算法，分明是个数据库设计和查询问题，照你这设计穷举写入，删除也穷举查询呗。

[Grocker]

@dyllen 如果数据库设计能满足场景，那他就是个数据库设计和查询问题，如果设计的不满足，就演变成算法问题了 😄

[clf]

都是线下了，做成发码的机制呗。业务员发码，一个 手机设备识别号 或 实名信息 只能使用一次。

额外的需要线下登记宝宝的身份证号，只允许登记 XX 周岁以下的身份证信息

但这种反正就是无法避免业务员和客户之间勾结

[allenpu666]

@Grocker #6 这种建议不要去重。
如果爸爸重新注册了一个账号都不能享受优惠的话，那拉新的数据可能非常难看。
到时候你就会发现，没有真正的“新人”

20 年那会，斑马等一众平台的推销人员还让孩子妈妈换一个手机号注册，这样就能享受到优惠呢。

[yisheyuanzhang]

@Grocker 如果有两个孩子，爸爸给哥哥注册、妈妈给妹妹注册算不算新用户。。

[Grocker]

@yisheyuanzhang 算不算全凭这个孩子在不在被关联的这个池子里

[flyqie]

防止新注册用户薅羊毛

你这边业务是推广期还是？

推广期的话你这种玩法拉新会非常难看。

不是的话，最好的方法就是以孩子唯一 ID 做一个组，这样会非常省事，不要想用互关这种方式来做，互关这场景做起来麻烦事一堆。

[flyqie]

@flyqie #34

如果有多个孩子的话，也可以考虑以家庭为唯一 ID 做组。

[Grocker]

@flyqie 业务已经是成熟期了

我们的注册模式是一个手机号可以注册一个用户，一个用户最多可以添加三个孩子
实际登录的实体是孩子
如果一个孩子被认为是分身，那么这个用户下的所有孩子都会被认为是分身

你说的 以孩子唯一 ID 做一个组是什么意思？

[icloudguizhou]

@TArysiyehua Uber eats 新用户 refer 有 55 美金大羊毛设备刷机+新的信用卡就能随便薅，没有强制上传 ID

[Grocker]

@Grocker 去除 “如果一个孩子被认为是分身，那么这个用户下的所有孩子都会被认为是分身”

[yankebupt]

@Grocker is_premium_user 字段存储最先注册的用户
其他关联用户全部用 referrer 字段存储关联 premium 用户的 id

当然关联关系获知时要给一点小利比如小优惠避免逃避检测，比如拼多多就放了个砍一刀陷阱，其实就是要手机指纹家庭关系关联数据库。

每个新优惠到达时全部按 referrer 递归层层上溯并存储在 premium user 的优惠记录中,但是使用权记在自己的记录中。然后所有人申请优惠时按 referrer 查找 premium user 是否享受过优惠即可。

[wweerrgtc]

没用的, 一个黄牛 带着 100 人的黄牛群

[angryfish]

算法应该是并查集。
数据库设置上，我觉得可以设置为（ user_id,root_associated_user_id,associated_user_id ）
查看两个用户是否是关联。直接看他们是不是同一个 root_associated_user_id 即可。root_associated_user_id 是真身，associated_user_id 是直接关联人（这个备用，方便以后将关系人传成链条）

[angryfish]

还得补充下，这里有个路径压缩问题，原有 A->B ,C->D 关联，后面来了个 B->C ，可以考虑遍历到最顶，也可以考虑在添加关系的时候进行路径压缩，更新 root_associated_user_id 。个人建议不需要压缩，直接遍历查询就行了。因为关系链不会很长。

[tangtang369]

https://leetcode.cn/problems/accounts-merge/description/ 看看这一题

[Grocker]

@angryfish （ user_id,root_associated_user_id,associated_user_id ）以 A->B 的话，这三个字段分别是？

[showB1]

imei 设备 id 呗

[4S3wVwsEaEc3ktu8]

如果愿意搞一个专门的系统做这个事，感觉就是 16 楼说的图数据库。问题就是一个连通图问题。跟社交软件的好友关联差不多。

[GeekGao]

你这个方法没用，这需要很系统化的风控策略，不止是用户信息层面

[txzhanghuan]

你这需要建设一套营销风控体系了。

[importmeta]

既然优惠力度很大，接入金融级人脸识别 SDK ，价格一块钱一次。。。

[SSang]

没有算法能实现你这种需求

[SSang]

我建议，你先把需求分析清楚了再提问，你都都线下辨别了，你干嘛不让业务人员自己去查表？

[realrojeralone]

不讨论业务场景，只从技术层面看，图数据库能满足需求吗？

[Grocker]

@realrojeralone 图数据库可以满足，只是走的有点远，并查集也能满足，以及 12 楼的也能满足

[longlonglanguage]

1.看网络，一般一家人回家都连 Wifi
2.看 sim 卡，可能存在一种场景，当前手机内并未装“相应的 sim 卡”，然而却输入的相应的 sim 卡号码
3.看账号的登录设备，一般情况下小孩会有一个设备专门用来“学习”
4.还可以在 123 条检测后，只要重复，就直接把对应的手机号记录进黑名单
5.不建议执行 1234 条，更不建议执行第 4 条，因为这会让你的顾客极度的不爽。

[angryfish]

@Grocker "（ user_id,root_associated_user_id,associated_user_id ）以 A->B 的话，这三个字段分别是？"

就像并查集一样，这里是要有初始化值的。为了让这个集合不太大，就放购买课程的人员吧。不用放全部用户进行初始化。
首先：用户 A 购买课程，表里就一条记录(A,A,NULL)
然后：B 购买就加条记录(B,A,A).
如果后面 C 购买，关系是 B->C 的，就增加一条记录（ C,A,B ）

若果出现 D->E,（ D,D,NULL ）,（ E,D,D ）
再出现一个 C->D 的话，这里可以自己衡量一下，如果查找很频繁，用户间关系很多的话，就进行路径压缩，否则直接查找就行了
最终，这个表的大小就是购买用户的数量。

[Pteromyini]

从数据结构说感觉可以构建最小生成树之类的，试试并查集？

[Pteromyini]

@Pteromyini #56 像是在找联通子图

[timpaikex]

楼主实际上要的是每个上课的娃只能用一次优
惠啊
那实际上应该对上课的娃的身份上做文章，保证每一个上课的娃都只有一个账号呗？说白了就是给上课娃的做实名制保证唯一，问题不就解决了？
至于可能出现的冒充身份上课问题，上传照片啥的可解，但是不建议做太多限制，有羊毛薅家长才会觉得不买亏

[zyxcompany]

有网络指纹 还是排除不了硬件更换

[lchynn]

用房产证吧， 一本产证只能一个号。

[lchynn]

或者一本产证最多允许 2 个未满 18 岁身份证号的优惠 （未满 18 岁也有身份证，户口本上有）；

按产证拿福利，思路来自于魔都大封城期间，居委发每户“救济粮”，按每户发放，而不是手机号或者什么别的号领取。

[pangdundun996]

从 op 的需求来看感觉没必要做那么复杂啊：
1 ）以小孩为唯一 id 建立家庭组；
2 ）家庭组中的小孩才能消费家庭权益；
3 ）家庭组中的家长才能为此家庭组购买权益；
4 ）后续所有的业务策略作用在家庭组上就好了

[pangdundun996]

@pangdundun996 至于说多孩家庭别人创多个家庭组享受新手优惠我觉得是合理的

[flmn]

图数据库

[v2defe]

既然实名了，用身份证号关联注册的用户不就行了，判断注册的用户是否有已关联账号，只需要根据身份证号来找。或者不用证件号，生成一个 uuid 来标识也可以吧

[junkk]

实名怎么做的，建议接入支付宝的实名，需要人脸，这个难度就高了很多

[qW7bo2FbzbC0]

图数据库 neo4j 为例：

返回与张三最多两度关系内的关联人手机号

Match (p1:Person)-[*0..2]-(p2:Person)
WHERE p1.Name='张三'
Return Distinct p2.Telephone


可以去网上搜搜 neo4j 的案例深入了解下

[mightybruce]

用人脸以及其他身份信息会直接导致用户不会下你的应用，获取用户的额外身份信息觉得是馊主意。
说实话你都是线下为主，那么线上只是辅助了， 录入一些信息校对是比较容易的， 线下核对为主。

是否是分身，我可以提供一点思路是早期用户都是邀请制， 点击链接必须要带上邀请码，这个邀请码就关联了一堆相关用户。

其次用户下载应用的浏览器要录入该浏览器的指纹，这样只要再用这个浏览器再注册新用户也只会判断为同一用户，浏览器指纹是多个属性，不管改了其中几个属性的值，还会判断为同一用户，如果实现困难，建议买一些付费的浏览器指纹识别前端库。

[qW7bo2FbzbC0]

你说的是否直接关联，在 neo4j 中就是一度关联，用关系长度进行过滤查询即可。
你说的取消关联，这个我不太理解，如果这两个是直接关联的话，那直接删除 p1 和 p2 的关系即可( delete relation 操作)
查询所有分身
Match (p1:Person)-[*]-(p2:Person)
WHERE p1.Name='张三'
RETURN p2

举个另外场景，查询与张三有性关系的人员(关系距离长度 100 以内),
Match (p1:Person)-[r:SEX*1...100]-(p2:Person)
WHERE p1.Name='张三'
RETURN p2

[mightybruce]

手机 app 倒是可以获取很多权限，像抖音在海外的 titok 直接检测 sim 卡信息，这个配合浏览器指纹就更方便判断是否为同一用户了。

至于关联， 简单的几层人际关系说实在不需要额外引入图数据库增加复杂度，又不是社交类应用。

数据库自关联查询可以解决层级关系。

[zbowen66]

这是军备竞赛啊👍🏻

[RandomJoke]

有那么复杂么。。。。你们业务上要求娃的身份号，不管谁关联娃，每个娃只能享受一次优惠不就好了。。没理解需求啊

[lazydog]

@Grocker #6 那这就是一家之中只能享受一次低价课优惠。那如果亲戚家没有小孩子或者小孩子不需要，你们这个是否也会判别为同一范围的关联关系呢？如果是的话，感觉可以考虑 #17 楼说的。#19 的似乎是更普片的做法，也许可以借鉴。

[jwenwang]

网易云盾、极验等成熟的风控 SDK 方案为啥不用？