我们在各大电商平台购物时，有时候会在提交订单时遇到诸如“当前下单人数太多，请稍后再试”或者是“很抱歉，当前销售太火爆，请稍后再试”的提示拦截。

    那么，此时真的是销售太火爆，我们抢不到商品了吗？

    其实，有时候这种提示文案只是一种“美化”，背后对应的可能是，你被电商防刷单机制拦截了，从而导致你无法正常下单。

    为什么电商会有防刷单机制？

    电商产品经理又应该如何搭建防刷单机制？

为什么电商要防刷单？

    我们日常经常会在新闻中看到，某某平台因为价格设置错误，导致低价销售了某个商品，亏损达几百万甚至几千万元。这是哪个平台无论如何都不愿意承担的损失——人为因素造成的利润大量亏损。

    此处我们需要明确，电商绝不是不能让利或者亏损。我们日常都会体验到电商的促销活动，可能是为了促活，也可能是为了清库存。所以，促销活动是正常销售必不可少的，但是绝不能因为“人为”因素造成“大量”亏损。

    因此，我们电商防刷的第一层因素，就在于防止操作不当等原因造成大量亏损，例如，防止运营人员针对商品的活动价格设置错误导致被“薅羊毛”，也就是——防亏损。

    除了防亏损，电商防刷还有第二层原因——防黄牛。

    黄牛是什么？是薅完平台的羊毛就走的用户。这就是意味着，一个电商平台正常的销售模式下，我们很难在黄牛用户身上获取盈利。我们在某些用户身上投入营销费用，背后的逻辑是希望将该用户培养为平台用户，让其在平台上形成可持续的复购模式，从而获取用户价值。但是黄牛用户明显与该目的相悖。

    同时，很多平台与品牌方是官方合作的形式，品牌方也会希望通过自身让利，将营销费用投入到真正能产生粘性的有价值的用户身上，从而为品牌带来更多的价值。如果品牌方与平台合作，却发现在平台上的该品牌用户都是黄牛用户，势必会对品牌效果大打折扣。而且品牌方很容易通过发货时是否“连号”检测到是否有黄牛刷单现象。例如，苹果品牌在这方面就比较严格。

    因此，站在平台角度，为了将优惠提供给真正有价值的用户，且维护好与相关品牌方的合作，都需要要——防黄牛。

电商防刷单机制如何搭建？ 

    既然电商平台需要防刷单，那么作为电商产品经理，尤其是负责交易链路或者营销模块的产品经理，就需要了解如何搭建电商防刷单体系和机制，并在交易流程中完成落地。

    正如上文所述，电商防刷单体系包含防亏损和防黄牛，在这两个模块下，各自包括多层方法，不同方法间又存在递进关系。

    防亏损包括活动层面和商品层面两层拦截。主要跟成本价格和用户实付价格息息相关，涉及到价格间的计算和比较。

    防黄牛除了活动层面、商品层面的拦截，还有风控维度对于黄牛用户的判断和识别机制，主要是限制用户对于某个商品的购买数量，涉及到限购逻辑。

1、如何防亏损？

    所谓亏损，就是用户实际支付的订单金额，小于订单中商品的成本金额，即平台采购金额。那么防亏损，就需要计算用户实际支付金额与采购金额之间的关系。

1.1 活动预算阈值熔断

    首先，当我们设置商品价格时，一般电商系统都会有销售价不低于采购价的校验逻辑。所以，可能造成销售价低于采购价的场景，就是因为促销活动。

    我们创建促销活动时，会设置商品促销价格，也就是商品原价-活动优惠金额。此时，我们会对该活动设置预算，当活动优惠金额到达预算金额时，可以理解为我们为活动准备的预算已经花完了。如果此时再有优惠产生，则是超出计划的亏损。因此，此时就会触发活动预算阈值熔断机制。

    总结如下：

    1）设置单个促销活动的预算

    2）计算活动订单优惠总金额

    3）当优惠总金额=预算，即活动熔断，意味着活动结束 

1.2 商品价格阈值熔断

    活动预算阈值熔断可以帮助我们保护单个活动的预算不被击穿。但是，在实际销售过程中，我们一个商品常常会参加多个活动，例如，又有单品直降100元，同时还可以叠加某张面额50元的优惠券。这种情况下，单个活动层面的阈值熔断就无能为力了。

    因此，我们还需要在商品层面上的阈值熔断。

    运营在经营销售该商品时，会很清楚该商品的成本价，即采购价是多少，也会很清楚最终可接受的销售价格在多少，因为运营也需要预留一定的“价格空间”促销调节。那么，他可以为该商品SKU配置一个价格阈值。

    这个阈值可以基于原价，也可以基于采购价。如果是基于采购价，那么意味着，当订单的实付金额小于采购价乘所配置的阈值时，就会造成运营计划之外的亏损，此时的订单就会进行拦截。

    此处需要注意，计算订单实付金额时，是否需要包含全部的优惠金额。

    如果是运营自身配置的促销活动，例如直降活动、优惠券或者预售，该部分活动成本由运营自身承担的，应该统计在内。

    如果是其他业务合作带来的促销活动，例如“京东卡”或者“京豆”这类的抵扣下单金额优惠，该部分活动成本可能由其他业务线承担，并已经将成本费用支付给运营，那么在计算订单实付金额时，应该剔除在外。

    总结如下：

    1）设置单个商品SKU的价格熔断阈值，可以基于原价或者采购价维度

    2）计算活动订单实付金额，需考虑哪些优惠金额需要统计，哪些优惠金额需要剔除

    3）当订单实付金额<商品采购价*阈值，即触发商品价格熔断，拦截下单

2、如何防黄牛？ 

    黄牛常见于针对一个商品，一个用户购买多件。此处更重要的是限购逻辑，从多个维度，限制一个用户的购买数量。 

2.1 活动商品限购

    如同上文所述，我们在做促销活动时，会设置商品优惠金额，同时，也可以设置该商品在活动中的限购数量，避免该商品的活动优惠，都被单用户“薅走”。

    除了活动中单个商品的限购数量限制，单个活动也可以设置总的限购数量限制。因为有很多长期的活动，例如秒杀活动，属于长期存在且周期性的活动，为避免在该周期的秒杀活动的优惠，都被同一用户享受，活动层面也需要设置限购。

    总结如下：

    1）单个促销活动，设置单个商品的限购数量

    2）单个促销活动，设置活动总限购数量

2.2 普通商品限购

    在活动层面上的限制，只能应用到该活动，又会遇到上文防亏损同样的问题，即一个商品同时参与多个活动，就无法进行限制。

    因此，在商品层面上，也需要限购。我们需要针对单个SPU或者单个SKU，配置其单用户限购数量。为了更加精准的限购，我们还可以针对维度，例如单个收货人姓名、单个收货人手机号、单个收货人地址等。

    总结如下：

    1）商品配置上，增加单SPU/SKU限购

    2）从用户、收货人姓名、收货人手机号、收货人地址等多维度限购

2.3 风控黄牛识别

    除了业务侧针对商品、活动层面的限制，每个电商平台其实都有自己的风控团队，专门识别欺诈风险，也就是刷单风险。他们一般会从更加细致的维度，去识别黄牛用户，并针对性的配置限制规则。

    风控侧一般可以从三个角度出发，用户角度、商品角度、时间角度，交叉配置限购规则。

    从用户角度，风控可以获取用户的实时地址、设备号等更多信息，并搭建自身的黑名单用户库、黑名单地址库，以此更精准的判断黄牛用户。

    黑名单用户，顾名思义即大量刷单用户，或者短时间内大量购买某类商品的用户，同时，我们还可以计算每个用户的总优惠成本。如果某个用户的历史累计订单的总优惠成本达到某个阈值，甚至负毛利，那么该用户可以被定义为黑名单用户。

    黑名单地址即该区域的刷单现象很严重。有时候，薅羊毛用户常聚集在同一个地方，同一个村子里。地址的维度包括粗粒度的一级地址（省）、二级地址（市），也可以细化到三级或者四级地址。因此还可以针对单个县或者镇进行用户账户、用户下单的管控。

    从商品角度，风控可以从类目、品牌、SKU等多维度出发，不同类目或者不同品牌的拦截规则可差异化配置。

    从时间角度，风控可以从1小时内、24小时内、7天内等多维度进行管控，限制用户的购买频率。

    通过以上维度，交叉形成一条规则，并配置对应的限购阈值。同时，限购阈值可以随时调节以适应不同的场景。例如，电商大促时为了销量高峰，可适当调高阈值，放宽限制，以此类推。

    总结如下：

    1）风控侧更精准的识别黄牛用户并维护对应的防刷规则

    2）从用户、商品、时间等多个维护交叉配置规则

    3）用户维度上，可增加实时地址、设备号、黑名单用户库、黑名单地址库等维度

防刷单机制的扩展 

    当我们为了防亏损和防黄牛，搭建好一套防刷单机制后，还需要考虑调节和体验问题。

    我们的防刷单规则不一定能保证百分百准确，意味着有些用户不可避免的会被“误伤”，这时候我们需要兼顾好用户体验问题。

    同时，我们会有一些业务场景，基于某些特定的业务目标，需要绕过防刷规则。此时，从产品功能的角度上，也需要做好白名单机制建设。

1、兼顾被拦截用户的体验问题

    当用户在提交订单时，遇到防刷单拦截时，我们要么直接拦截，不让用户下单成功，要么则让用户去除优惠，以商品原价下单。

    如果我们直接拦截用户下单，则需要采用更通用化的提示语，例如文章开头所述的那样，大多数平台会模糊化处理，仅告诉用户“当前下单人数太多，请稍后再试”。如果是命中了明确的活动限购规则拦截，也可以告诉用户“当前商品限购数量为X，您已超过限购数量”。一般情况下，这种具体的活动和商品规则，可以在活动页或者商详页向用户告知，避免用户针对该类场景的客诉。

    如果不直接拦截，我们也可以让用户去除优惠，以原价下单。毕竟以原价购买，对于平台来说是盈利的，只是用户购买意愿会下降。此时，我们一般以弹窗形式告诉用户“当前活动已结束，是否去除优惠继续下单”。如果用户愿意去除优惠，则剔除活动后，继续完成下单支付流程。

    总结如下：

    1）如果直接拦截下单，需采用通用性的语句。如果是可告知的用户规则，可前置展示

    2）如果不直接拦截下单，可让用户选择是否剔除优惠后继续下单支付 

2、防刷提前至领券等前置节点

    从上文我们也可以看到，防刷单主要是因为有活动，商品有优惠时，怕用户因为享受过多优惠导致亏损。那么，我们也可以尝试在优惠源头就进行切断。

    例如，用户要使用优惠券，必须先领取优惠券，此时，我们限制黑名单用户不能领券，则即使该部分用户下单，也不会使用该项优惠导致亏损。

    同理，针对其他促销活动，我们可以在活动层面就限制特定用户无法参与，以此控制该部分用户的刷单。

    总结如下：

    1）防刷单节点前置，例如前置到领优惠券时判断

    2）针对促销活动，可设置参与用户的限制 

3、考虑特殊场景的白名单机制

    经过千锤百炼，防刷单体系终于上线完成。此时，我们又会遇到一些“不能防刷”的特殊场景。

    例如大促时为了制造营销噱头，发放满2022减618元的大额神券。可是如果用户使用大额券，又可能遇到价格阈值拦截。这样相当于制造了“假噱头”，既影响用户体验，又造成平台的负面评价。

    因此，当我们设计防刷单体系时，还要考虑特殊场景下的白名单机制。以上述场景为例，针对商品价格阈值熔断机制中，我们需要增加针对某类优惠，不加入计算逻辑的规则。这类优惠可能是一个活动ID或者一个优惠券ID，它产生的优惠金额不会计入订单实付金额中，以此绕过该项拦截。

    包括我们的风控黄牛识别系统中，有黑名单用户，自然也会有白名单用户。例如，很多场景下，公司内部人员为了测试功能，或者对外宣讲，都需要额外的“特权”。那么可以将公司内部员工加入白名单用户，该类用户不会命中拦截规则。

    总结如下：

    1）防刷单的拦截功能需要考虑白名单机制，支持特殊场景下绕过某个规则

    2）白名单机制可以是针对活动，也可以是针对用户或者地址

结语

    电商防刷单体系是电商产品体系中不可或缺的一部分。当产品经理设计营销系统功能时，尤其要主要防刷单模块设计。而交易链路作为电商黄金流程最重要的一环，也需要包含防刷单模块的兜底设计。

    任何一个电商平台都会遇到黄牛和刷单。试想一下，如果连黄牛都不愿意去，那这个平台是有多差？当黄牛发现被某个平台拦截后，他们又会升级自己的“马甲”，跃过系统的规则。而系统又会发现新的“黄牛”、新的“伎俩”，从而又促进了系统及规则的迭代升级。

    因此，电商与刷单的“斗争”是无穷无尽、永不止步的。作为产品经理，必须好防刷单系，搭建成完善的系统，才能帮助平台快速、精准而安全的打好每场“战役”。