分辨多个用户之间是否是分身的算法? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
Grocker
V2EX    程序员

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

  Grocker 2024-07-29 11:34:35 +08:00 8489 次点击
这是一个创建于 443 天前的主题,其中的信息可能已经有所发展或是发生改变。

我有一个需求是为了分辨多个用户之间是否是分身(需求背景是为了防止新注册用户薅羊毛,优惠力度挺大的,是分身的用户只要一人享受了优惠,其他人不能再次享受), 所以我要将多个用户之间人为的去关联,比如用户 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); 

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

74 条回复    2024-07-30 17:06:43 +08:00
murmur
    1
murmur  
   2024-07-29 11:37:02 +08:00
别需求了,现在只能实名制,有多少黑产专门卖抹指纹的手机

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

最核心的用户特征辨别方法都没有
Grocker
    2
Grocker  
OP
   2024-07-29 11:40:21 +08:00
@murmur 辨别方法是线下,因为业务人员知道哪些人之间存在关联关系
murmur
    3
murmur  
   2024-07-29 11:42:10 +08:00
@Grocker 你最好在仔细想一下常见,设备指纹、实名制,这两个最常用的方法你不用

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

你这需求我真看不懂。。。
Grocker
    4
Grocker  
OP
   2024-07-29 11:43:38 +08:00
@murmur 我们场景不一样,是线下教育机构
TArysiyehua
    5
TArysiyehua  
   2024-07-29 11:45:32 +08:00   9
楼上说的对,其实光实名都不太行,之前我待的一家公司就是,实名+手机号才能过的账号,也被黑产刷了一大波。关键就是黑产手上有无数个号。
后来不得不限定只有用户我们的产品才能薅羊毛(就是你必须有类似于购买或者消费记录),这样来说这样的用户是肯定能满足的。
不过这一套又不能用在拉新身上,因为新人他是不会有任何购买或者消费记录的,这样就不得不再设计一套类似于现在很多 app 这样,可以让你信号注册领羊毛,但是变现不了,只能用于消费。(类似于朴朴,淘宝这样的拉新)

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

总之一个铁律:不能提现,变现。最好能跟产品商品绑定,优惠下来,哪怕不挣钱,甚至亏一点点,但是产品还是卖了,也不亏。
Grocker
    6
Grocker  
OP
   2024-07-29 11:46:03 +08:00
所有用户事先都已实名了,比如有个宝宝,用他妈妈的账号注册了,去买了个低价课,上完后,又用他爸爸的账号注册了再去买了个低价课,就是为了避免这种情况
veni2023
    7
veni2023  
   2024-07-29 11:50:56 +08:00
技术上能实现的话,用户体验肯定非常差
wuud
    8
wuud  
   2024-07-29 11:53:45 +08:00
@Grocker #6 如果这个宝宝用他妈妈的手机和身份、他爸爸的手机和身份,这个应该怎么分辨。同好奇,有答案麻烦踢一下
Grocker
    9
Grocker  
OP
   2024-07-29 11:58:23 +08:00
@wuud 其实分辨不是这个问题的重点,主要是问算法

我们的业务模式是线下,上课的娃始终没变,自然知道哪些账号之间是存在关联的了
hi909
    10
hi909  
   2024-07-29 12:02:19 +08:00 via iPhone
用树形结构,在数据库中加个 path 字段,例如 A/B/C/D ,就表示 D 的上级是 C 。就和文件夹一样。
Unicornvic
    11
Unicornvic  
   2024-07-29 12:03:00 +08:00
@Grocker 如果“上课的娃始终没变”,那么签协议的时候设置一下主体,判断一下唯一可行吗
hi909
    12
hi909  
   2024-07-29 12:04:45 +08:00 via iPhone   2
或者可以增加一个 customer group ,每个上课的人都需要有一个 group 。 他爸妈的账号也要关联在这个 group 里。
meilicat
    span class="no">13
meilicat  
   2024-07-29 12:22:12 +08:00   5
并查集
saberlove
    14
saberlove  
   2024-07-29 12:24:29 +08:00
填写娃儿的身份证
zizon
    15
zizon  
   2024-07-29 12:28:03 +08:00
你想想面向对象编程里子类和父类的关系.
wangxiaoer
    16
wangxiaoer  
   2024-07-29 12:31:56 +08:00 via iPhone
感觉图数据库很合适拿来用用。
xabcstack
    17
xabcstack  
   2024-07-29 12:48:47 +08:00
你需要的是账号遗传 DNA 的算法
2Q6flVvMwgSYg5T8
    18
2Q6flVvMwgSYg5T8  
   2024-07-29 13:09:15 +08:00
保留 associations 表,同时使用另一个表来记录每个用户的所属分量。遍历 associations 表中的用户,有直接关联的两个用户属于同一分量,通过并查集将他们合并到同一个合集。这样可以吗?
docx
    19
docx  
   2024-07-29 13:20:53 +08:00 via iPhone
同一设备,同一手机号,同一实名,同一支付方式满足其一即为同一用户

照着那些办羊毛活动的来准没错,他们都是被薅过有经验的
alphaControler
    20
alphaControler  
   2024-07-29 13:42:58 +08:00 via Android
楼主,你搜搜并查集算法。有树的路径压缩
alphaControler
    21
alphaControler  
   2024-07-29 13:45:04 +08:00 via Android
@alphaControler 如果需要权重,那就搜带权并查集
null113
    22
null113  
   2024-07-29 13:48:16 +08:00
并查集,求连通分支数,数据库的话就想办法生成一个唯一 id
xiangyuecn
    23
xiangyuecn  
   2024-07-29 13:49:21 +08:00
研究什么算法,直接一条一条查完事,查 100 次也不是什么事
MoYi123
    24
MoYi123  
   2024-07-29 14:04:43 +08:00
并查集的删除不太好做. 还是用 sql 的递归来实现 dfs 硬查吧, 看起来数据量不会很大.
snailya
    25
snailya  
   2024-07-29 14:07:17 +08:00
@hi909 我觉得你说的对
tianhehechu
    26
tianhehechu  
   2024-07-29 14:13:16 +08:00
看了一圈,V 友们给出的方案要么太麻烦,要么达不到效果。用我这个方案就行了。
我的方案很简单,换个思路。不要去想着防止同一个人用多个账号登录,你要先假设系统中所有账号都是同一个人(未识别账号)。
接下来要做的就是从这些未识别账号中,识别出不是同一个人的。其余的一律提示:活动尚未对您开放。
如何识别出不是同一个人的账号呢,分事先预防和事后校验。
事先预防,就是注册账号时,用户名必须是有意义的字符串,只需要这一条,剩下的不需要。
事后校验,就是提现时要求输入信用卡号和 CVC 、校验人脸。信用卡信息不符、人脸校验不通过直接封 IP 、封设备指纹(并撤销同 IP 、同设备指纹所有用户的参与资格,已获得且未提现的归零,此操作只需把这些用户一并归入未识别用户)。未识别用户登录时,若此前已体现但资格被撤销,则要求从信用卡扣款返还费用方可继续使用。对于同一设备指纹的其他用户,也作相同提示:该设备中有欺诈用户尚未返还非法所得,已禁止当前设备所有用户使用,返还非法所得后将解除限制。
Grocker
    27
Grocker  
OP
   2024-07-29 14:24:29 +08:00
@hi909 我觉得这种也是最简便的,比如 A 关联 B ,group 是 1 ,B 关联 C ,查询到他有 customer group 了,把它也放在 group 1 就行了
dyllen
    28
dyllen  
   2024-07-29 14:26:52 +08:00
你这个数据库设计相当于把账号关联穷举存在了数据库。删除两个数据,需要把直接或者间接的也全找出来删掉,这那里是什么算法,分明是个数据库设计和查询问题,照你这设计穷举写入,删除也穷举查询呗。
Grocker
    29
Grocker  
OP
   2024-07-29 14:30:04 +08:00
@dyllen 如果数据库设计能满足场景,那他就是个数据库设计和查询问题,如果设计的不满足,就演变成算法问题了
clf
    30
clf  
   2024-07-29 14:38:50 +08:00
都是线下了,做成发码的机制呗。业务员发码,一个 手机设备识别号 或 实名信息 只能使用一次。

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

但这种反正就是无法避免业务员和客户之间勾结
allenpu666
    31
allenpu666  
   2024-07-29 14:53:31 +08:00
@Grocker #6 这种建议不要去重。
如果爸爸重新注册了一个账号都不能享受优惠的话,那拉新的数据可能非常难看。
到时候你就会发现,没有真正的“新人”

20 年那会,斑马等一众平台的推销人员还让孩子妈妈换一个手机号注册,这样就能享受到优惠呢。
yisheyuanzhang
    32
yisheyuanzhang  
   2024-07-29 15:28:38 +08:00
@Grocker 如果有两个孩子,爸爸给哥哥注册、妈妈给妹妹注册算不算新用户。。
Grocker
    33
Grocker  
OP
   2024-07-29 15:33:15 +08:00
@yisheyuanzhang 算不算全凭这个孩子在不在被关联的这个池子里
flyqie
    34
flyqie  
   2024-07-29 15:34:36 +08:00
防止新注册用户薅羊毛

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

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

不是的话,最好的方法就是以孩子唯一 ID 做一个组,这样会非常省事,不要想用互关这种方式来做,互关这场景做起来麻烦事一堆。
flyqie
    35
flyqie  
   2024-07-29 15:36:06 +08:00
@flyqie #34

如果有多个孩子的话,也可以考虑以家庭为唯一 ID 做组。
Grocker
    36
Grocker  
OP
   2024-07-29 15:58:41 +08:00
@flyqie 业务已经是成熟期了

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

你说的 以孩子唯一 ID 做一个组是什么意思?
icloudguizhou
    37
icloudguizhou  
   2024-07-29 16:16:36 +08:00
@TArysiyehua Uber eats 新用户 refer 有 55 美金大羊毛设备刷机+新的信用卡就能随便薅,没有强制上传 ID
Grocker
    38
Grocker  
OP
   2024-07-29 16:25:01 +08:00
@Grocker 去除 “如果一个孩子被认为是分身,那么这个用户下的所有孩子都会被认为是分身”
yankebupt
    39
yankebupt  
   2024-07-29 16:29:40 +08:00
@Grocker is_premium_user 字段存储最先注册的用户
其他关联用户全部用 referrer 字段存储关联 premium 用户的 id

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

每个新优惠到达时全部按 referrer 递归层层上溯并存储在 premium user 的优惠记录中,但是使用权记在自己的记录中。然后所有人申请优惠时按 referrer 查找 premium user 是否享受过优惠即可。
wweerrgtc
    40
wweerrgtc  
   2024-07-29 17:03:56 +08:00
没用的, 一个黄牛 带着 100 人的黄牛群
GBdG6clg2Jy17ua5
    41
GBdG6clg2Jy17ua5  
   2024-07-29 17:12:49 +08:00
算法应该是并查集。
数据库设置上,我觉得可以设置为( user_id,root_associated_user_id,associated_user_id )
查看两个用户是否是关联。直接看他们是不是同一个 root_associated_user_id 即可。root_associated_user_id 是真身,associated_user_id 是直接关联人(这个备用,方便以后将关系人传成链条)
GBdG6clg2Jy17ua5
    42
GBdG6clg2Jy17ua5  
   2024-07-29 17:18:15 +08:00
还得补充下,这里有个路径压缩问题,原有 A->B ,C->D 关联,后面来了个 B->C ,可以考虑遍历到最顶,也可以考虑在添加关系的时候进行路径压缩,更新 root_associated_user_id 。个人建议不需要压缩,直接遍历查询就行了。因为关系链不会很长。
tangtang369
    43
tangtang369  
   2024-07-29 17:35:59 +08:00
Grocker
    44
Grocker  
OP
   2024-07-29 17:59:53 +08:00
@angryfish ( user_id,root_associated_user_id,associated_user_id )以 A->B 的话,这三个字段分别是?
showB1
    45
showB1  
   2024-07-29 18:43:58 +08:00
imei 设备 id 呗
4S3wVwsEaEc3ktu8
    46
4S3wVwsEaEc3ktu8  
   2024-07-29 19:06:32 +08:00
如果愿意搞一个专门的系统做这个事,感觉就是 16 楼说的图数据库。问题就是一个连通图问题。跟社交软件的好友关联差不多。
R4rvZ6agNVWr56V0
    47
R4rvZ6agNVWr56V0  
   2024-07-29 19:19:04 +08:00
你这个方法没用,这需要很系统化的风控策略,不止是用户信息层面
txzhanghuan
    48
txzhanghuan  
   2024-07-29 19:38:41 +08:00
你这需要建设一套营销风控体系了。
importmeta
    49
importmeta  
   2024-07-29 19:39:32 +08:00   1
既然优惠力度很大,接入金融级人脸识别 SDK ,价格一块钱一次。。。
SSang
    50
SSang  
   2024-07-29 19:39:37 +08:00
没有算法能实现你这种需求
SSang
    51
SSang  
   2024-07-29 19:44:32 +08:00
我建议,你先把需求分析清楚了再提问,你都都线下辨别了,你干嘛不让业务人员自己去查表?
realrojeralone
    52
realrojeralone  
   2024-07-29 19:50:25 +08:00
不讨论业务场景,只从技术层面看,图数据库能满足需求吗?
Grocker
    53
Grocker  
OP
   2024-07-29 19:53:35 +08:00
@realrojeralone 图数据库可以满足,只是走的有点远,并查集也能满足,以及 12 楼的也能满足
longlonglanguage
    54
longlonglanguage  
   2024-07-29 19:58:19 +08:00
1.看网络,一般一家人回家都连 Wifi
2.看 sim 卡,可能存在一种场景,当前手机内并未装“相应的 sim 卡”,然而却输入的相应的 sim 卡号码
3.看账号的登录设备,一般情况下小孩会有一个设备专门用来“学习”
4.还可以在 123 条检测后,只要重复,就直接把对应的手机号记录进黑名单
5.不建议执行 1234 条,更不建议执行第 4 条,因为这会让你的顾客极度的不爽。
GBdG6clg2Jy17ua5
    55
GBdG6clg2Jy17ua5  
   2024-07-29 20:33:12 +08:00
@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
    56
Pteromyini  
   2024-07-29 22:40:45 +08:00
从数据结构说感觉可以构建最小生成树之类的,试试并查集?
Pteromyini
    57
Pteromyini  
   2024-07-29 22:41:15 +08:00
@Pteromyini #56 像是在找联通子图
timpaikex
    58
timpaikex  
   2024-07-30 08:53:19 +08:00 via Android
楼主实际上要的是每个上课的娃只能用一次优
惠啊
那实际上应该对上课的娃的身份上做文章,保证每一个上课的娃都只有一个账号呗?说白了就是给上课娃的做实名制保证唯一,问题不就解决了?
至于可能出现的冒充身份上课问题,上传照片啥的可解,但是不建议做太多限制,有羊毛薅家长才会觉得不买亏
zyxcompany
    59
zyxcompany  
   2024-07-30 09:10:12 +08:00
有网络指纹 还是排除不了硬件更换
lchynn
    60
lchynn  
   2024-07-30 09:40:27 +08:00   2
用房产证吧, 一本产证只能一个号。
lchynn
    61
lchynn  
   2024-07-30 09:42:41 +08:00
或者一本产证最多允许 2 个未满 18 岁身份证号的优惠 (未满 18 岁也有身份证,户口本上有);

按产证拿福利,思路来自于魔都大封城期间,居委发每户“救济粮”,按每户发放,而不是手机号或者什么别的号领取。
pangdundun996
    62
pangdundun996  
   2024-07-30 09:58:42 +08:00
从 op 的需求来看感觉没必要做那么复杂啊:
1 )以小孩为唯一 id 建立家庭组;
2 )家庭组中的小孩才能消费家庭权益;
3 )家庭组中的家长才能为此家庭组购买权益;
4 )后续所有的业务策略作用在家庭组上就好了
pangdundun996
    63
pangdundun996  
   2024-07-30 10:00:49 +08:00
@pangdundun996 至于说多孩家庭别人创多个家庭组享受新手优惠我觉得是合理的
flmn
    64
flmn  
   2024-07-30 10:06:59 +08:00
图数据库
v2defe
    65
v2defe  
   2024-07-30 10:09:02 +08:00
既然实名了,用身份证号关联注册的用户不就行了,判断注册的用户是否有已关联账号,只需要根据身份证号来找。或者不用证件号,生成一个 uuid 来标识也可以吧
junkk
    66
junkk  
   2024-07-30 10:13:32 +08:00
实名怎么做的,建议接入支付宝的实名,需要人脸,这个难度就高了很多
qW7bo2FbzbC0
    67
qW7bo2FbzbC0  
   2024-07-30 10:21:16 +08:00
图数据库 neo4j 为例:

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

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


可以去网上搜搜 neo4j 的案例深入了解下
mightybruce
    68
mightybruce  
   2024-07-30 10:27:15 +08:00
用人脸以及其他身份信息会直接导致用户不会下你的应用,获取用户的额外身份信息觉得是馊主意。
说实话你都是线下为主,那么线上只是辅助了, 录入一些信息校对是比较容易的, 线下核对为主。

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

其次用户下载应用的浏览器要录入该浏览器的指纹,这样只要再用这个浏览器再注册新用户也只会判断为同一用户,浏览器指纹是多个属性,不管改了其中几个属性的值,还会判断为同一用户,如果实现困难,建议买一些付费的浏览器指纹识别前端库。
qW7bo2FbzbC0
    69
qW7bo2FbzbC0  
   2024-07-30 10:28:00 +08:00
你说的是否直接关联,在 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
    70
mightybruce  
   2024-07-30 10:40:56 +08:00
手机 app 倒是可以获取很多权限,像抖音在海外的 titok 直接检测 sim 卡信息,这个配合浏览器指纹就更方便判断是否为同一用户了。

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

数据库自关联查询可以解决层级关系。
zbowen66
    71
zbowen66  
   2024-07-30 12:54:03 +08:00
这是军备竞赛啊
RandomJoke
    72
RandomJoke  
   2024-07-30 13:25:14 +08:00
有那么复杂么。。。。你们业务上要求娃的身份号,不管谁关联娃,每个娃只能享受一次优惠不就好了。。没理解需求啊
lazydog
    73
lazydog  
   2024-07-30 17:00:49 +08:00
@Grocker #6 那这就是一家之中只能享受一次低价课优惠。那如果亲戚家没有小孩子或者小孩子不需要,你们这个是否也会判别为同一范围的关联关系呢?如果是的话,感觉可以考虑 #17 楼说的。#19 的似乎是更普片的做法,也许可以借鉴。
42V0CdLjCU494ogF
    74
42V0CdLjCU494ogF  
   2024-07-30 17:06:43 +08:00
网易云盾、极验等成熟的风控 SDK 方案为啥不用?
关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     905 人在线   最高记录 6679       Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 28ms UTC 20:43 PVG 04:43 LAX 13:43 JFK 16:43
Do have faith in what you're doing.
ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86