电子商务发展了这么多年，已经形成了成熟的商业模式。近年来，头部电商平台一直在不断推出新的玩法政策，促使消费者购买，同时保护消费者权益。但是好心不一定有好结果。本文就来说说电商价格保护规则带来的“眼镜蛇效应”。

一、什么是“眼镜蛇效应”

和大家分享一个小故事。

印度还是英国殖民地的时候，印度当地眼镜蛇横行，经常发生眼镜蛇伤人的事件。当地政府想解决眼镜蛇的问题，于是出台了一项计划：只要抓住眼镜蛇，就可以获得相应的赏金。

出于赏金的诱惑，印度民众捕获大量眼镜蛇，以换取相应的赏金。短时间内，眼镜蛇的数量大大减少。

眼镜蛇减少了，那些“吃政府羊毛”的人却不高兴了？投机取巧的人想出了一个解决办法。野外没有眼镜蛇，我们可以自己养。政府分不清野生和家养，所以捕蛇就成了养蛇。

很快，政府发现不对劲。显然，数量已经减少。为什么有那么多人拿蛇换赏金？经过调查，发现其中有猫腻，政府不得不停止赏金计划。

没有了赏金，养蛇的人自然失去了养蛇的动力，于是把养的蛇全部放生，眼镜蛇又在野外泛滥了，而且比以前更严重。

经济学家霍斯特西伯特(Horst siebert)根据这一事件创造了“眼镜蛇效应”一词。

每当你做决定的时候，你的出发点通常是好的，但是结果会好吗？

二、电商平台的“价保”规则

近年来，为了保护消费者权益，防止商家恶意定价，电商平台纷纷设置“价格保障”规则。我们先来看看某电商平台“价格保障”规则的描述：

我看到这套规则的第一个想法就是，太好了，平台终于管住这些无良商家了。原来购物节后压低价格的行为得到遏制，消费者可以放心购买。

我理解的价格保护规则是商家一定会遵守平台的要求，不敢随意调价。如果调价导致消费者权益受损，会被平台发现，差价返还给消费者，影响商家店铺评估分支。

真的是这样吗？消费者理解的“价格保证”规则和商家理解的一致吗？

三、商家的“价保”套路

这几年618活动从6.1一直持续到6.18，平台上的商品价格每天都在变化。我一时无法确定哪一天是最优惠的价格，就一直关注。6.16，我预感价格可以启动了。跟客服确认有“价格保障”规定后，我就下单了。

6.18当天，我重新登录平台查看商品最新价格，瞬间圈了一圈，说“那价格保障呢”？

带着质疑的语气问了客服，得到了以下的回答和解决方案：

商家态度很好，反应很快。提出的解决方案是，我不付款，以最低价格下单，然后给他发两个订单号。他确认了两个订单的差价，给我补了差价。虽然最后没有去平台申请“价保”，但还是顺利拿到了赔偿。

回顾整个事件，我感到恐惧。从商品调价到售后处理，这是一整套的解决方案。针对不同场景下的问题，已经设置了相应的解决方案：

卖家在营销策略的制定上做了多种价格方案。刚开始的时候，商品已经预热，价格也在不断调整，有升有降。重要的是消费者想不通，一直关注，害怕失去最好的价格。不管什么时候下单，都是商家的期望；

Lisitng可以瞬间改价格，改图片，改文案，这是软件绝对支持的。整个方案都是事先定好的，价格自动调整。

加入平台的“价格保护”活动，减少消费者的防备。消费者认为

从前到后，所有场景全覆盖，他们赌的就是部分消费者下单之后不再关注商品信息，赚的是这个信息差。

“赌”是有风险的，商家为什么能确定他能够赚到这份信息差？其实这是一个概率的问题，商家掌握了消费者的下单行为，已经有完整的消费者画像，和消费者行为路线图，经过大量的分析，得出消费者对类似事情的关注程度，从而得到了最优的配置方案。

我们看起来很赚，但商家永远不亏！

这就是“眼镜蛇效应”，平台的规则制定初衷是好的，但是却被商家钻了漏洞。要特别提醒从事电商的产品经理，警惕商家套路，多考虑方案设计，怎么才能进行合理优化，让“价保”方案发挥该有的用处，造福消费者。

四、产品设计的思考

作为软件设计从业者，我们要不断反思我们的每一次方案设计是否存在漏洞，是否覆盖了全场景。

方案的优化并不是拍脑袋、一时一刻就能设计出来的，需要我们持续跟进优化。

产品上线后，及时进行跟进使用效果，查看数据、分析行为、复盘使用场景，并不断优化。

我拿一个负责的项目给大家举例。

我负责了“供应商管理系统”的整体设计方案，上线之后，供应商管理部负责审核信息的同学给我反馈，他发现其他部门的小伙伴在引入供应商时，会对一家母、子公司进行重复引入。我司是杜绝马甲供应商的，所以他们希望做一下校验，使用手机号、地址等信息，发现重复地进行提示，人工核实。

这个需求我们评审很合理，于是我就规划了一个产品方案，与业务方进行评审。在评审过程中，业务方提出最好是填写信息的时候不进行相关提示，只有在审核的时候提示。

我表示不理解，如果我们在填写信息的时候就进行提示，那么新建的同事不就知道了是马甲供应商、避免重复引入、停止资料填写了吗？这也减少了供应商审核同事的工作量。

业务呵呵一笑，道出了真相。由于某些无法诉说的利益原因，新建的人如果发现了信息重复，他们会找供应商替换手机号和资料信息，绕过判断，从而成功入驻，这样的话我们的校验其实是帮助他们，不能实现这个功能的初衷。

我表示震惊，还有这种操作。软件方案并不作恶，但却会帮助别有用心之人。

于是我们设计方案进行了调整，只在审核的时候校验提示，并且不对公司其他部门公开我们的校验逻辑。没有了明确的规则，新建的人只能靠猜，虽然他绕过了我们第一道检测，但不一定能绕过第二道检测。

上线第二天，通过我们的检验，就发现了一个马甲供应商，并反馈给了对应的审核人员。

如果业务方没有意识到这个问题，上线后的需求，被某些同事巧妙运用了规则，我们就陷入了“眼镜蛇效应”，系统的数据还在观察，方案仍需优化……

五、总结

作为“产品经理”，我们都有可能会陷入“眼镜蛇效应”，即使是一个小需求，我们也不能放弃对需求的研究。不断去发现、去深思，把每一件小事做好，小事的成功也可以造福一方用户。