电商促销业务逻辑盘根错节？试试脱离场景，从系统计算逻辑上思考

如果你整体设计过电商网站的促销功能，整理过相关的促销逻辑（例如，针对商品或订单的满减、满赠、折扣、优惠券等等），那么你一定清楚：如果对这些促销类型进行任意组合，将会有非常多样化的场景，这对于系统来说极易发生重叠甚至冲突的情况，那时你是如何处理这些逻辑关系的，又是如何做到在满足业务/运营需求的同时，最大化的降低系统判断逻辑的？如果你所设计的只是促销系统中的某个功能模块，会很容易陷入逻辑死循环，因为只有从整体上设计促销逻辑才能保证各子系统流程顺畅流转。笔者尝试脱离实际促销场景，抽象出一条行之有效的促销整体原则。

用一句话概括这条原则： 同类型通过实体进行互斥、不同类型可以相互叠加 。这里说明实体是商品或者订单。

为什么会有这么一句话？我们来看下下图：

电商系统订单金额计算流程

促销计算逻辑

上图展示了电商系统中，一笔订单导入系统后，它的价格是如何计算出来的。为什么要说这个呢？

电商所谓营销，归根结底都是订单金额的变化；如果我们清楚的知道订单金额的计算流程是怎样的，那么我们只需要顺着系统的计算流程做促销，就不用担心各种促销类型之间产生重叠或者冲突的情况了。

当我们知道这个关系后，就可以将营销活动区分为三种类型：改商品价格、改商品小计价格、改订单价格，因为无论什么营销归根结底都是可以描述成改价格。

第一种类型：修改商品价格

一笔订单被提交时，系统必然首先查找出订单中的所有商品，并判断此商品是否具备特殊价格（促销价格）。如果没有，则取正常的商品零售价；如果有，则取当前商品所处促销活动价格。

商品价格计算流程

那么好了，我们便可以把所有涉及更改商品价格的促销活动全部归到此类，例如现价段非常流行的促销活动玩法： 秒杀。

秒杀是一种限时类的商品低价促销活动类型。用较低的价格和较短的活动时间，以营造抢购氛围的一种营销玩法。这种活动，在一个用户看来是一个非常新颖好玩的活动，但是对于一个PM来讲，它无非就是一个修改商品价格的促销类型而已，注意我对秒杀活动的定义：限时类的 商品低价 促销活动类型，核心是商品低价，这直接决定了它是一种修改商品价格的促销活动，也就是 第一种类型

其他关于修改价格的营销类型，如： 限时折扣，降价拍、团购、拼团等 都可以归类到这一方式

这类型的促销活动，遵循促销核心原则： 同类型通过实体进行互斥、不同类型可以相互叠加 。此处的实体就是商品。所以这条原则也可以表述为：不同商品可以参与相同的（秒杀、拼团、限时折扣等修改价格）活动；但是相同商品进行互斥，就是说，同一个商品不可以同时参与同一类型的活动，例如：同一个SKU不可以同时参与（秒杀、拼团、限时折扣等修改价格）活动。

第二种类型：修改商品小计

当系统完成了对商品价格的查找之后，就需要将查找出的商品价格分别乘以订单中的每个商品数量，从而计算出每个商品的小计金额。当系统计算出所有商品的小计金额之后，这时候，就可以介入一些营销活动，例如指定商品的：满减、满赠、折扣等。

商品小计金额计算流程

那么好了，我们又可以将指定商品的：满减、满赠、折扣 归类为修改商品小计的营销活动

例如：全场母婴用品，满100减10，满200减30；就是典型的第二种类型营销活动，因为它是针对某种/某类 商品的小计金额来匹配满足那种类型的活动，并在满足活动的商品小计金额基础上进行减、赠、折。

那么我们再次用促销核心规则来捋一捋它的处理逻辑： 同类型通过实体进行互斥、不同类型可以相互叠加 。此处的实体是商品，所以这对第二种类型的促销活动，我们就可以得出以下结论：

同一个商品，不能同时参与指定商品的（满减、满赠、折扣 等）活动，不同的商品没有限制。

例如：SKUA 不能同时参加满减、满赠、折扣；但是SKUA 参与满减，SKUB参与满赠 这种是被允许的。

我们注意到第二条原则：不同类型可以相互叠加，也就是说，同一个商品虽然不能同时参与同种类型的活动，但是却可以同时参与不同类型的促销活动，例如：SKUA 可以同时参与限时折扣和指定SKUA的满减活动！！！，也就是我们常说的折上折。我们需要做的仅仅是区分促销是属于哪种类型而已

第三种类型：修改订单金额

当系统完成了对商品小计金额的计算之后，就会将所有优惠后的商品小计金额进行叠加，生成一个初步的订单总金额，当系统得到初步的订单总金额之后，又可以介入一些营销活动，例如指定订单的：满减、满赠、折扣和优惠券等。

订单金额计算

那么好了，我们又可以将指定订单类的：满减、满赠、折扣归类为第三种：修改订单金额的营销活动。例如：京东招牌活动全场满88包邮；就是典型的第三种类型营销活动，因为它是针对订单的总金额来匹配满足那种类型的活动，并在满足活动的订单金额基础上进行减、赠、折、优惠券和包邮等。

那么我们再次用促销核心规则来捋一捋它的处理逻辑： 同类型通过实体进行互斥、不同类型可以相互叠加 ，此处的实体就是订单。

所以，针对第三种类型的促销活动，我们就可以得出以下结论： 同一笔订单不能同时参与针对订单的：满减、满赠、折扣的活动。

总的来说

之所以会有： 同类型通过实体进行互斥、不同类型可以相互叠加 ，这条原则，是因为它高度遵循了系统计算订单金额的流程—在计算同一类型的促销活动时，如果存在多个相同的活动，除非你人为的告诉系统（对于平台电商，例如京东、天猫，存在多商家活动，每个运营负责的店铺/类目/品牌不同，仍然可能存在不同商品参与多个促销活动的情况，这时候就需要告诉系统应该选择哪个促销规则？

1. 让用户自己选；
2. 系统自动定义优先级 或者其他，最终都必须只有一个促销活动），优先计算哪条规则，否则，系统就无法进行下去，当你帮助系统排除了这些冲突，问题自然迎刃而解。

所以，当你脑洞大开希望实现一个促销功能时，首先应该判断是哪种类型（改商品价格、改商品小计价格还是改订单价格），再根据类型通过实体（商品或者订单）去与其他促销活动区别开，这样就可以玩转各种促销活动了。

说明： 这里仅讨论系统层面的电商营销逻辑，保证系统流程上不发生冲突，没有考虑实际的业务场景，但是无论什么业务场景都应该在上述原则范围内行事，不能逾越。比如：针对商品的活动，你可以限制拼团的商品（第一类促销）不能参加指定商品满减（第二类促销），即：在逻辑上允许叠加，但是业务场景上可以限制；但是绝不可能同时使某个商品即参与拼团活动，又参与秒杀活动。这在业务逻辑上就是不被允许的，也就是： 可以在上述原则范围内行事，但是不能逾越这个原则。

 

本文由 @菜哥 原创发布于人人都是产品经理。未经许可，禁止转载。