反羊毛党中的非即时反馈策略

新年,因为之前工作方向的调整,我开始负责先行介入处理公司的业务安全事宜。业务安全之前接触的不多,突然被老板“委以重任”加之其面对的是脸皮超厚的羊毛党们,不免有点小小的紧张。经过几次“战役”后,对反羊毛工作有了点新的认识,略记录一二。

在一部分反羊毛的工作者眼里,他们是十分痛恨羊毛党的,仿佛有种欲先杀之而后快的感觉。面对被筛出的羊毛党账号或者ip,可能会采取一些较为激进的封禁措施。如此一来,倘若初筛敏感度过高,就容易被误封的用户或者就干脆是厚脸皮的羊毛党,暴跳如雷地向网站客服反馈——你们技术部门(安全部门)就是垃圾,把老子这么乖的宝宝给封了,赔礼、赔钱。

紧接着,业务部门就会带着他们的老大以及你的老大一起来吊打你。这样的结果往往会是两败俱伤——羊毛党薅光奖品、你的安全策略被强制下线顺便落了个不靠谱的名声。

面对这种尴尬的场景,我们应该考虑一个严肃的问题——究竟这该咋整?

通常来说,答案是不咋整。我们经过实践发现,采取用户可感知的反制措施(尤其是封禁),会使得对抗被迫升级。并不能在期望的时间区间内达到让羊毛党消停的目标,反而容易“适者生存”的方式进化出一批高级羊毛党。

为了防止羊毛党进化,我们开始考虑如何让羊毛党变的更笨。想起做监督式机器学习时,对模型的反复训练、测试的修正过程。我们发现,在整个的进化过程中,即时反馈是学习成功的重要保证,也是物种或者能力进化所需要的关键步骤

我们之所以不会蠢蠢地把手伸进燃烧的火焰中,就是因为火焰会通过痛觉即时的告诉大脑它是有危险的。设想一下,如果这种反馈机制消失,很可能一个人变成“烤乳猪”了,还没有意识到自己正处于危险之中。剥夺了即时反馈的学习,结局自然只有死路一条。

思路有了就好办,于是,在我们的反欺诈系统中出现了一个有趣策略——非即时反馈策略。

某一次,业务方希望举行一个投票集赞活动,活动持续10天,首奖是New Macbook Pro一台。凭借直觉,我们认为这个活动一定会被羊毛党盯上。

活动上线后第7个小时,反羊毛系统出现告警并同时启动非即时反馈策略,系统会对参与投票的小部分人员随机弹出验证码或要求用户使用鼠标点击页面某个区域。这个过程不是必须的,系统允许用户拒绝响应这个请求。用户无论响应或拒绝响应这个请求,相关投票集赞接口返回值均不发生变化,投票数也会按照期望去“增加”。但是,反羊毛系统在后台记录了所有拒绝响应的用户。

活动结束前,客服部门已经陆陆续续接到其他用户投诉某几位投票异常增幅,我们建议客服部门使用话术先行安抚这些用户。活动结束后,我们关闭投票排名页面。反羊毛系统对所有投票进行合规检查,剔除了这类异常投票。经过人工确认,首奖中奖人确为真实用户和真实投票。被剔除的用户中,甚至有“倒打一耙”向客服举报其他人刷票的厚脸皮家伙;也有去为实际第二名的用户“被动刷票”然后泼脏水以取消真实用户中奖资格的家伙。

(上面的例子出于保密考虑,简化了大部分的识别、控制、剔除过程,实际工作中,我们采取了更加复杂的策略和更加丰富的数据维度去鉴定用户行为的合理性)

我们通过数据,让业务部门清清楚楚的看到活动异常的来龙去脉,也让他们对我们后续的反欺诈工作有了充分的信心。在一片欢声笑语中,我们业务部门的老大愉快地吃了一顿饭。

哎……内谁,老板……晋级加薪的事儿能不能给我个即时反馈啊?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*