很多人关注这件事情的焦点在于京东到底需不需要发货，需不需要承担责任，不发货的法律风险，以及是否应该谴责羊毛党们的无理取闹，乃至其中正常使用了优惠券的人是否有损失。

但在我眼中这些都不重要，反而这次事件中暴露的风险管理问题才是真正的重点。

羊毛党可恶不假，但是风控在干什么。

现在这个年代，风险管理做不好的话，业务做得越大越危险，因为一点小小的错误就会造成巨大的损失。

尤其是临到春节促销，这种失误挺吓人的。

让我来拆分下这次事件中暴露的问题以及应该有的解决方案。

坐稳了，这些东西在外面是看不到的，有钱也买不到。

风控的实战经验很少对外暴露，能从里面领悟多少看你们的了。

风控是盾，亦可是矛。

我将本次事件按照流程做了排序，依次来描述其中的问题，并给出解决建议。

1.事前发券环节。

本次事件的第一个节点在于优惠券的发放。

电商的优惠券一般分为两种券，一种是无门槛的优惠券，不管你买了多少钱的商品，都能够正常的使用，最低可以付0元来获得商品。

另一种是有门槛的优惠券，属于满X减Y，例如满1000减200，由于有门槛券不论如何都是可以带来GMV的，所以有门槛券的限制会松很多，当然本次的主角也不是有门槛券。

所以我们主要讲无门槛券。

在电商业务中，无门槛券约等于现金，需要非常严肃的对待。

1.1无门槛券的效果完全等同于现金，所以无门槛券不能无限发。

无门槛券必须限制一个总额，也就是券的总张数，超过这个数字就显示已被抢光，这是最底层的规则，控制总成本。

此次事件中未出现这个限制，居然有24W张面值为200元的无门槛券被领走了，这个非常惊人。

1.2无门槛券必须严格限制领取资格。

不是所有人都有资格领券的，为了能够更好的保证活动效果的最大化，无门槛券往往会专门限定用户的群体。

随便举几个例子，实际业务中按照业务目的来做具体切割，新老用户的定义也是业务方按照需求定义的。

在拉新场景中，券不该给老用户，因为是用来给新用户的。

在运营场景中，券不该给新用户，因为是用来激活老用户忠诚度的。

在大促场景中，券不该给不活跃用户，因为是用来维持用户活跃度的。

而此次事件中，未出现此类限制，券人人都能领，这就导致羊毛党使用机器就可以在短时间内完成大量下单。

1.3无门槛券必须有一系列的核身（核实身份）策略，确保知道钱发给了谁。

因为无门槛券等于发现金，所以到底钱给了谁，非常很重要。

要保证钱必须给到不同的人，不然就是无效补贴。

核身策略中最常见的就是不同账号出现了同一收货手机号，同一收货地址，同一历史行为，同一IP，同一设备ID，同一支付ID，LBS，等等等等一系列策略，是电商最基础的风控规则包。

而此次事件中，未发现此类限制，导致羊毛党直接用脚本就可以操作，短时间24万订单，很恐怖。

整个发券环节，风控是存在一定缺失的。

2.发券环节结束后，是用券环节。

领券后想要获利，则必然要用券，这个阶段，是风控介入的重点环节。

如果用券风险管理做得好，可完全弥补发券环节的缺失。

2.1用户用券时，核验用户的异常特征。

每一个用户在登录APP的时候，都是会留下大量特征的，这些异常的数据特征都需要有专门的风险规则来核验。

随便举一些案例。

近3个月只登录了1次，且本次领券用券的用户。

登录IP为XX风险号段的用户。

登录特定设备型号（某安卓or苹果手机）+来源（应用市场）的用户。

登录设备曾经多次以不同身份登录APP的用户。

本地APP List中包含沙盒类APP的用户。

Root用户等等等等等等。

类似的异常特征有很多，每个成熟的电商都应该有类似的规则集，某些异常的用户就应该在用券的环节做double check，直接禁止用券或者禁止支付。

本次事件中，该机制没有发挥作用，是没有这套机制还是其他异常，不得而知。

2.2用券下单时，核验用户的下单信息，并横向比较。

用户在下单时，是需要留下大量信息的，这些信息可当作风险的判定条件。

举一些例子。

收货手机号是否出现多笔订单一致的情况？

收货手机号是否为账号常用手机号？

是否为本机手机号？

收货人姓名是否出现多笔订单一致的情况？

收货姓名是否为常用姓名？

收货地址是都出现多笔订单一致或者相似的情况？

下单区域是否出现动态叠加？

下单支付账号是否出现相同的情况？

下单设备号（IMEI），是否出现重复？

下单用户的操作路径，是否是直接登录-领券-下单？

类似的规则主要是拦截掉异常的订单。

此次事件中，未出现此类拦截。

2.3用券时，核验用户的共同特征。

共同特征主要是防范大规模机器操作的，原理为大量僵尸设备登录的时候会有非常显著的共性，一般批量拦截即可。

例如同一批下单区域的用户。

相同的WIFI地址。

相同的支付ID。

相同的操作频率（登录+选中+付款的速度），相同的操作路径。

相同的LBS位置。

相同的历史购物记录等等等等。

此次事件中，未出现此类拦截。

3.动态关系网络，抑或是图数据库。

所谓动态关系网络，是指在实时下单的用户中，通过关系网匹配已下单用户中的关联情况，抓取可疑的团伙群体。

例如，同一时间段内。

下单用户中出现大量互相交叉的收货地址，A给B下单，B给A下单。

下单用户中出现大量用户互相在通讯录中。

下单用户中发现大量用户曾经给某些商品进行过评价。

下单用户中出现大量用户曾经登陆过相同的设备，等等等等。

此次事件中，未出现此类拦截。

4.库存保护机制，订单三次核验以及发货拦截机制。

即使在领券，用券，下单支付环节都没有完成拦截和过滤，那么在下单后，依然能够直接进行风险管控。

4.1库存保护机制

这次被羊毛党主动攻击的订单集中于几个品牌的特定产品，并且短期内爆发了大量的订单，这个订单数量远远超过了正常库存的数量，这些商品是京东自营，不可能有这么多的库存数量。

一般电商风控在防止薅羊毛的时候，会在库存机制上做分隔，除非是确认的倾销，不然库存都是有一个上限的，卖完会下架或者换一个全新的SKU来替换。

被少量商品刷爆，并且库存丝毫没有拦截，是本次事件的一个特点。

4.2订单的第三次核验以及拦截

电商的订单不是用户付完款就直接发货的，一般是用户下单支付后的一段时间（N分钟到N小时）内，按批次发送物流，或者同时发送物流，但是按照时间节点来处理。

这就代表着，在物流处理的节点，还可以加一次check，还可以多加几个小时，等待大批量的订单进入待发货状态，批量比较订单。

很多海淘商品和大促商品，都有这套完整的机制，如果在这个节点发现异常，直接拦截即可。

这个在电商术语里面叫做砍单，相信我们大家不陌生。

这次事件的砍单效率，有点事后强行扭的意思，而且从声明中能够正常的看到已经有大批订单签收了，还有一大批堆在物流配送节点了。

这也是用户大量投诉的前提，假如直接砍单，那么反响会小很多。

整体的机制做的不够完善。

5.数据监控和警报机制。

对于优惠券消费，尤其是无门槛券，应该是有完整的监控体系的。

对于优惠券的流向以及流量监控，并且设置报警阈值，失效机制，熔断机制，这些风控和大数据都应该早就准备好的。

数据监控和警报埋点做好，实时监控所有订单，并统计数据，一旦某些指标超出常规，立刻发出警报到相关负责人的设备，并且暂时hold住所有异常订单发货，等待相关负责人做二次确认。

本次短时间爆发的大量订单，相关商品一定是在短时间冲上了类目的top5甚至top3，并且销售量和实付金额必然极度异常，有完整的数据监控和警报体系的话，应该是第一时间就冻结所有商品发货，然后通知相关负责人。

从本次的事件来看，似乎并没有完整的这套流程。

6.运营权限管控

本次大额无门槛券突然被大量的放了出来并且能够使用，且在短时间之内没有被风控拦截，按照京东声明里的说法是，优惠券设置错误。

把原本有门槛的券设置为无门槛，或者金额多了个0，或者使用范围增加了，在大型电商的运营后台，运营配置错误的情况时有发生。

能够理解，人出错是很正常的。

但是机制不应该出错。需要控制运营的权限，不允许单一运营配置总额大于X的券，并且需要设置二次审核甚至三次审核机制，更极致一点的还要数据分析师给出ROI测算依据。

权限管控和流程风控也是风险管理的重点，相信规则的力量。

本次事件中，这个点或许存在一定的隐患。

当然，本文讲述的风控知识只是最表面的一些，核心的关键指标设计，特征工程，变量中心，决策引擎，钓鱼机制，卡单逻辑以及规则集和关键词库等更有趣的内容受制于篇幅和敏感度，也不适合放出来，一般只有线下分享以及同行面对面的时候才会谈论。

只能说，对付羊毛党，一套成熟的风控体系还是有点用处的。

但无奈的是，对于绝大多数公司而言，风控都是很尴尬的存在。

因为风控只负责减法，而业务和运营负责加法，老板想看的是加法的结果。

这就导致风控即使有一肚子本身，可能都要不到研发资源，有限的资源全都去做业务了。

没有研发资源的风控，有本事也没本事。

风控是内功，是要大力投入的内功，可惜大部分人都不太重视。

一来嘛，风控属于桥上的栏杆，不出问题根本用不上，这就代表这不如多做业务多做GMV能才有利于个人的晋升答辩，风控这东西除非放贷款，不然很难量化成果。

尤其是做风控系统的，要吃大量的研发资源，但是效果看起来平平无奇，这个很考验企业老板的眼光。

二来嘛，有部分公司的老板很聪明，公司即使有些损失，但只要有GMV的增长，可以在长期资金市场把钱再拿回来，羊毛出在猪身上。

这时候，风控就很碍眼了，需要丢出来背锅。

所以在很多老板眼中，不出事儿，养风控就像养猪。

出了事儿，养风控可能还不如养猪。

这句话其实是有一定道理的，但这是增量年代的逻辑。

现在这个存量的年代，比谁不出错，可能才更有价值百科。