我有一个需求是为了分辨多个用户之间是否是分身(需求背景是为了防止新注册用户薅羊毛,优惠力度挺大的,是分身的用户只要一人享受了优惠,其他人不能再次享受), 所以我要将多个用户之间人为的去关联,比如用户 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);
需要用到的场景有: 取消关联某两个用户之间的关联 查询给定用户的所有分身
1
murmur 100 天前
别需求了,现在只能实名制,有多少黑产专门卖抹指纹的手机
我看到的下面都是不知所云 最核心的用户特征辨别方法都没有 |
5
TArysiyehua 100 天前 9
楼上说的对,其实光实名都不太行,之前我待的一家公司就是,实名+手机号才能过的账号,也被黑产刷了一大波。关键就是黑产手上有无数个号。
后来不得不限定只有用户我们的产品才能薅羊毛(就是你必须有类似于购买或者消费记录),这样来说这样的用户是肯定能满足的。 不过这一套又不能用在拉新身上,因为新人他是不会有任何购买或者消费记录的,这样就不得不再设计一套类似于现在很多 app 这样,可以让你信号注册领羊毛,但是变现不了,只能用于消费。(类似于朴朴,淘宝这样的拉新) 当然如果你的优惠是针对虚拟的东西,这又不一样了。。。 总之一个铁律:不能提现,变现。最好能跟产品商品绑定,优惠下来,哪怕不挣钱,甚至亏一点点,但是产品还是卖了,也不亏。 |
6
Grocker OP 所有用户事先都已实名了,比如有个宝宝,用他妈妈的账号注册了,去买了个低价课,上完后,又用他爸爸的账号注册了再去买了个低价课,就是为了避免这种情况
|
7
veni2023 100 天前
技术上能实现的话,用户体验肯定非常差
|
10
hi909 100 天前 via iPhone
用树形结构,在数据库中加个 path 字段,例如 A/B/C/D ,就表示 D 的上级是 C 。就和文件夹一样。
|
11
Unicornvic 100 天前
@Grocker 如果“上课的娃始终没变”,那么签协议的时候设置一下主体,判断一下唯一可行吗
|
12
hi909 100 天前 via iPhone 2
或者可以增加一个 customer group ,每个上课的人都需要有一个 group 。 他爸妈的账号也要关联在这个 group 里。
|
13
meilicat 100 天前 5
并查集
|
14
saberlove 100 天前
填写娃儿的身份证
|
15
zizon 100 天前
你想想面向对象编程里子类和父类的关系.
|
16
wangxiaoer 100 天前 via iPhone
感觉图数据库很合适拿来用用。
|
17
xabcstack 99 天前
你需要的是账号遗传 DNA 的算法
|
18
Crit 99 天前
保留 associations 表,同时使用另一个表来记录每个用户的所属分量。遍历 associations 表中的用户,有直接关联的两个用户属于同一分量,通过并查集将他们合并到同一个合集。这样可以吗?
|
19
docx 99 天前 via iPhone
同一设备,同一手机号,同一实名,同一支付方式满足其一即为同一用户
照着那些办羊毛活动的来准没错,他们都是被薅过有经验的 |
20
alphaControler 99 天前 via Android
楼主,你搜搜并查集算法。有树的路径压缩
|
21
alphaControler 99 天前 via Android
@alphaControler 如果需要权重,那就搜带权并查集
|
22
null113 99 天前
|
23
xiangyuecn 99 天前
研究什么算法,直接一条一条查完事,查 100 次也不是什么事
|
24
MoYi123 99 天前
并查集的删除不太好做. 还是用 sql 的递归来实现 dfs 硬查吧, 看起来数据量不会很大.
|
26
tianhehechu 99 天前
看了一圈,V 友们给出的方案要么太麻烦,要么达不到效果。用我这个方案就行了。
我的方案很简单,换个思路。不要去想着防止同一个人用多个账号登录,你要先假设系统中所有账号都是同一个人(未识别账号)。 接下来要做的就是从这些未识别账号中,识别出不是同一个人的。其余的一律提示:活动尚未对您开放。 如何识别出不是同一个人的账号呢,分事先预防和事后校验。 事先预防,就是注册账号时,用户名必须是有意义的字符串,只需要这一条,剩下的不需要。 事后校验,就是提现时要求输入信用卡号和 CVC 、校验人脸。信用卡信息不符、人脸校验不通过直接封 IP 、封设备指纹(并撤销同 IP 、同设备指纹所有用户的参与资格,已获得且未提现的归零,此操作只需把这些用户一并归入未识别用户)。未识别用户登录时,若此前已体现但资格被撤销,则要求从信用卡扣款返还费用方可继续使用。对于同一设备指纹的其他用户,也作相同提示:该设备中有欺诈用户尚未返还非法所得,已禁止当前设备所有用户使用,返还非法所得后将解除限制。 |
27
Grocker OP @hi909 我觉得这种也是最简便的,比如 A 关联 B ,group 是 1 ,B 关联 C ,查询到他有 customer group 了,把它也放在 group 1 就行了
|
28
dyllen 99 天前
你这个数据库设计相当于把账号关联穷举存在了数据库。删除两个数据,需要把直接或者间接的也全找出来删掉,这那里是什么算法,分明是个数据库设计和查询问题,照你这设计穷举写入,删除也穷举查询呗。
|
30
clf 99 天前
都是线下了,做成发码的机制呗。业务员发码,一个 手机设备识别号 或 实名信息 只能使用一次。
额外的需要线下登记宝宝的身份证号,只允许登记 XX 周岁以下的身份证信息 但这种反正就是无法避免业务员和客户之间勾结 |
31
allenpu666 99 天前
@Grocker #6 这种建议不要去重。
如果爸爸重新注册了一个账号都不能享受优惠的话,那拉新的数据可能非常难看。 到时候你就会发现,没有真正的“新人” 20 年那会,斑马等一众平台的推销人员还让孩子妈妈换一个手机号注册,这样就能享受到优惠呢。 |
32
yisheyuanzhang 99 天前
@Grocker 如果有两个孩子,爸爸给哥哥注册、妈妈给妹妹注册算不算新用户。。
|
33
Grocker OP @yisheyuanzhang 算不算全凭这个孩子在不在被关联的这个池子里
|
34
flyqie 99 天前
防止新注册用户薅羊毛
你这边业务是推广期还是? 推广期的话你这种玩法拉新会非常难看。 不是的话,最好的方法就是以孩子唯一 ID 做一个组,这样会非常省事,不要想用互关这种方式来做,互关这场景做起来麻烦事一堆。 |
36
Grocker OP @flyqie 业务已经是成熟期了
我们的注册模式是一个手机号可以注册一个用户,一个用户最多可以添加三个孩子 实际登录的实体是孩子 如果一个孩子被认为是分身,那么这个用户下的所有孩子都会被认为是分身 你说的 以孩子唯一 ID 做一个组是什么意思? |
37
icloudguizhou 99 天前
@TArysiyehua Uber eats 新用户 refer 有 55 美金大羊毛设备刷机+新的信用卡就能随便薅,没有强制上传 ID
|
39
yankebupt 99 天前
@Grocker is_premium_user 字段存储最先注册的用户
其他关联用户全部用 referrer 字段存储关联 premium 用户的 id 当然关联关系获知时要给一点小利比如小优惠避免逃避检测,比如拼多多就放了个砍一刀陷阱,其实就是要手机指纹家庭关系关联数据库。 每个新优惠到达时全部按 referrer 递归层层上溯并存储在 premium user 的优惠记录中,但是使用权记在自己的记录中。然后所有人申请优惠时按 referrer 查找 premium user 是否享受过优惠即可。 |
40
wweerrgtc 99 天前
没用的, 一个黄牛 带着 100 人的黄牛群
|
41
angryfish 99 天前
算法应该是并查集。
数据库设置上,我觉得可以设置为( user_id,root_associated_user_id,associated_user_id ) 查看两个用户是否是关联。直接看他们是不是同一个 root_associated_user_id 即可。root_associated_user_id 是真身,associated_user_id 是直接关联人(这个备用,方便以后将关系人传成链条) |
42
angryfish 99 天前
还得补充下,这里有个路径压缩问题,原有 A->B ,C->D 关联,后面来了个 B->C ,可以考虑遍历到最顶,也可以考虑在添加关系的时候进行路径压缩,更新 root_associated_user_id 。个人建议不需要压缩,直接遍历查询就行了。因为关系链不会很长。
|
44
Grocker OP @angryfish ( user_id,root_associated_user_id,associated_user_id )以 A->B 的话,这三个字段分别是?
|
45
showB1 99 天前
imei 设备 id 呗
|
46
4S3wVwsEaEc3ktu8 99 天前
如果愿意搞一个专门的系统做这个事,感觉就是 16 楼说的图数据库。问题就是一个连通图问题。跟社交软件的好友关联差不多。
|
47
GeekGao 99 天前
你这个方法没用,这需要很系统化的风控策略,不止是用户信息层面
|
48
txzhanghuan 99 天前
你这需要建设一套营销风控体系了。
|
49
importmeta 99 天前 1
既然优惠力度很大,接入金融级人脸识别 SDK ,价格一块钱一次。。。
|
50
SSang 99 天前
没有算法能实现你这种需求
|
51
SSang 99 天前
我建议,你先把需求分析清楚了再提问,你都都线下辨别了,你干嘛不让业务人员自己去查表?
|
52
realrojeralone 99 天前
不讨论业务场景,只从技术层面看,图数据库能满足需求吗?
|
53
Grocker OP @realrojeralone 图数据库可以满足,只是走的有点远,并查集也能满足,以及 12 楼的也能满足
|
54
longlonglanguage 99 天前
1.看网络,一般一家人回家都连 Wifi
2.看 sim 卡,可能存在一种场景,当前手机内并未装“相应的 sim 卡”,然而却输入的相应的 sim 卡号码 3.看账号的登录设备,一般情况下小孩会有一个设备专门用来“学习” 4.还可以在 123 条检测后,只要重复,就直接把对应的手机号记录进黑名单 5.不建议执行 1234 条,更不建议执行第 4 条,因为这会让你的顾客极度的不爽。 |
55
angryfish 99 天前
@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 的话,这里可以自己衡量一下,如果查找很频繁,用户间关系很多的话,就进行路径压缩,否则直接查找就行了 最终,这个表的大小就是购买用户的数量。 |
56
Pteromyini 99 天前
从数据结构说感觉可以构建最小生成树之类的,试试并查集?
|
57
Pteromyini 99 天前
@Pteromyini #56 像是在找联通子图
|
58
timpaikex 99 天前 via Android
楼主实际上要的是每个上课的娃只能用一次优
惠啊 那实际上应该对上课的娃的身份上做文章,保证每一个上课的娃都只有一个账号呗?说白了就是给上课娃的做实名制保证唯一,问题不就解决了? 至于可能出现的冒充身份上课问题,上传照片啥的可解,但是不建议做太多限制,有羊毛薅家长才会觉得不买亏 |
59
zyxcompany 99 天前
有网络指纹 还是排除不了硬件更换
|
60
lchynn 99 天前 2
用房产证吧, 一本产证只能一个号。
|
61
lchynn 99 天前
或者一本产证最多允许 2 个未满 18 岁身份证号的优惠 (未满 18 岁也有身份证,户口本上有);
按产证拿福利,思路来自于魔都大封城期间,居委发每户“救济粮”,按每户发放,而不是手机号或者什么别的号领取。 |
62
pangdundun996 99 天前
从 op 的需求来看感觉没必要做那么复杂啊:
1 )以小孩为唯一 id 建立家庭组; 2 )家庭组中的小孩才能消费家庭权益; 3 )家庭组中的家长才能为此家庭组购买权益; 4 )后续所有的业务策略作用在家庭组上就好了 |
63
pangdundun996 99 天前
@pangdundun996 至于说多孩家庭别人创多个家庭组享受新手优惠我觉得是合理的
|
64
flmn 99 天前
图数据库
|
65
v2defe 99 天前
既然实名了,用身份证号关联注册的用户不就行了,判断注册的用户是否有已关联账号,只需要根据身份证号来找。或者不用证件号,生成一个 uuid 来标识也可以吧
|
66
junkk 99 天前
实名怎么做的,建议接入支付宝的实名,需要人脸,这个难度就高了很多
|
67
qW7bo2FbzbC0 99 天前
图数据库 neo4j 为例:
返回与张三最多两度关系内的关联人手机号 Match (p1:Person)-[*0..2]-(p2:Person) WHERE p1.Name='张三' Return Distinct p2.Telephone 可以去网上搜搜 neo4j 的案例深入了解下 |
68
mightybruce 99 天前
用人脸以及其他身份信息会直接导致用户不会下你的应用,获取用户的额外身份信息觉得是馊主意。
说实话你都是线下为主,那么线上只是辅助了, 录入一些信息校对是比较容易的, 线下核对为主。 是否是分身,我可以提供一点思路是早期用户都是邀请制, 点击链接必须要带上邀请码,这个邀请码就关联了一堆相关用户。 其次用户下载应用的浏览器要录入该浏览器的指纹,这样只要再用这个浏览器再注册新用户也只会判断为同一用户,浏览器指纹是多个属性,不管改了其中几个属性的值,还会判断为同一用户,如果实现困难,建议买一些付费的浏览器指纹识别前端库。 |
69
qW7bo2FbzbC0 99 天前
|
70
mightybruce 99 天前
手机 app 倒是可以获取很多权限,像抖音在海外的 titok 直接检测 sim 卡信息,这个配合浏览器指纹就更方便判断是否为同一用户了。
至于关联, 简单的几层人际关系说实在不需要额外引入图数据库增加复杂度,又不是社交类应用。 数据库自关联查询可以解决层级关系。 |
71
zbowen66 98 天前
这是军备竞赛啊👍🏻
|
72
RandomJoke 98 天前
有那么复杂么。。。。你们业务上要求娃的身份号,不管谁关联娃,每个娃只能享受一次优惠不就好了。。没理解需求啊
|
73
lazydog 98 天前
@Grocker #6 那这就是一家之中只能享受一次低价课优惠。那如果亲戚家没有小孩子或者小孩子不需要,你们这个是否也会判别为同一范围的关联关系呢?如果是的话,感觉可以考虑 #17 楼说的。#19 的似乎是更普片的做法,也许可以借鉴。
|
74
jwenwang 98 天前
网易云盾、极验等成熟的风控 SDK 方案为啥不用?
|