朴朴（线上超市）促销系统模拟

milk 2023-07-23 07:13:07

这篇学习到促销系统，促销是平台让利提高销量的重要手段，包括一般的促销活动（满减、满折、满赠等）和优惠券。主要相交互的系统是商品系统、库存系统、订单系统、crm（会员）系统。

商品系统用于指定活动的商品；库存系统可以划分出活动库存和一般库存；订单系统很重要的一点就是在结算这些活动时按什么顺序结算以及分摊到各个商品，会影响订单的最终支付金额和退款时的计算；crm 系统可用于精准营销指定可以享受活动资格的用户群体。

促销系统其实我们作为消费者已经知道了很多套路，尤其是最近几年天猫双十一的种种优惠，几乎没有什么促销方案在双十一中找不到的。所以其实归纳促销方案并不是重点，虽然如何把种种促销方案抽象归纳并形象化方便配置也很重要，但是更重要和复杂的还是重叠互斥和结算这一块。

原型链接：https://xd.adobe.com/view/80b51f95-d563-48bd-7f8f-38fea693b065-f684/

一、学习

有一篇文章从比较高的角度总结了促销类型和计算顺序，这篇文章首先是将促销类型归为三种：

针对商品单品（特定 SKU 或 SPU）的降价，如商品券，或者直接打折；
商品集合的降价。即以人工划分的商品类别为单位做一些营销活动，如某品牌系列的满减，或比如柑橘类水果的活动；
订单整体的降价，比如绝大部分优惠券是适用于整单的打折或降价的。

然后规定了大部分业务场景的结算顺序是按照以上顺序的 1 2 3 来计算的，在商品小计中先计算单品价格，单品降价后再看是否符合商品小计的活动规则，最后再计算订单整体。接着说明了一句很重要的原则： “同类型通过实体进行互斥、不同类型可以相互叠加。”

二、简单归纳

我认为他对于促销类型的总结和最后的原则都很合理，也体现了绝大部分业务场景。第三点原则的类型是比较具体的类型，比如满减是一个类型，满赠、满折、满额换购，都是不同的类型，实体是商品，也就是说一个商品不能参加两个不同的满减，或者两个不同的满赠，对于同一商品来说如果在同类型的两个不同活动中。那么这两个活动一定要是互斥的，而不能叠加。

在创建具体的活动时，我们可以手动来设定不同类型的活动 A 与活动 B 互斥或叠加，但是在总体上应该有一个基础的、同商品不能同时参加同类型活动的规则，这样可以使配置和开发时的代码没那么多冗余。

这里就要求我们在最开始设定类型时，要想好哪些活动是同一个商品绝不可以同时参与的。这个规则决定了抽象程度，如满减和满折如果认为都是降价类的，同商品不能两次降价，那么划归一类不可以同时参与，如果换购和赠品都属于低价获取商品类的，也划归一类不能同时参与。

如果只是不能满 50 – 20 后又满 10 – 5 这样叠加下去，但是满减后也可以满折，那么就满减、满折都是不同的类型。当然一般来说划分的细一点，比较可以适应之后活动的灵活性。但是对于第二点计算顺序我还是有些不同的想法。

当然了，订单整体的降价一定是放在最后的，但是商品单品和商品小计的顺序其实可以更灵活一点，通过配置权重来决定展示和结算的顺序，毕竟本身权重也是一定要配置的一个要素。

三、配置的基本要素

对于一个促销活动，也是可以用基本的 5W2H 来分析的。

WHAT – 是什么类型的促销活动？活动名称是什么？促销的商品有哪些？
WHY – 需求的目标是什么？这其实应该是促销人员思考的，在做一个活动时目的是提高销量，还是清空库存，还是带动客单价，来决定他配置一个怎样的活动。
WHO – 后台角度：谁配置的？是否有审核？前台角度：从 crm 中选择合适的用户。
WHEN – 后台角度：什么时间配置的？前台角度：可用时间？
WHERE – 投放渠道是哪里？小程序、app。
HOW – 具体的活动规则是什么？如满减的数额，与其他活动是否互斥？权重多少？
HOW MUCH – 投入产出比如何？有无数量限制？商品有无限购库存？用户端有无限购？

四、关于权重

我认为权重分为两方面：显示权重和计算权重，但实际上也可以只配置一个权重。权重是为了控制包含相同商品的活动与活动之间的关系，活动与活动的关系可认为只有两种：叠加和互斥。也就是对于同一个商品，活动 A 与 B 是可以叠加还是只能选择其一。

如果是互斥，那么默认为顾客选择哪一个就是显示权重，此时没有计算的先后可言，因为只能选一个。如果是可叠加享受，一定是要有个计算的先后逻辑；并且肯定是全部显示出来，但是哪一个为先呢？这个等下再讲。

具体到如何去设计这个逻辑，我的思路是填写数字而不应该是固定的一些等级，原因是如果同时期，首先配置了活动 A，包含商品 x，那么假若有三个以上的活动同时包含了商品 x，就很难去配置相互之间的关系。既然这个权重只是要在多个共存时确定一个“比较级”，那么只要有数字的比较就可以了，不需要确定的等级，甚至无需对数字作要求，如果喜欢，10000 也可以。

这个权重可以视为这个活动的一个标签，如果活动过期，即可释放这个数字。比如原有一组有重复商品的活动 A B C，权重分别为 1 2 3，C 活动过期，3 这个数字得到释放，新建活动 D 也与 A B 有重复商品，那么此时可以把 D 的权重设置为 3。

同时，在不同活动 A B C 有重复商品时，只需对 A B C 设定数字即可，这一组数字不会影响到另一组 E F G H 的权重。（这里的一组表示包含重复商品的不同活动）也就是说可以对 A B C 赋值权重 1 2 3，也可以对 E F G H 赋值 1 2 3 4，只要 A B C 与 E F G H 没有相同商品即可。

具体到前台的计算和显示上，示意图如下：

朴朴（线上超市）促销系统模拟

活动和权重

假设有三种产品 X Y Z，各自有图上所示的活动和权重。表格中的 O P 两种活动是与 ABC 活动可叠加的，O 与 P 互斥，A B C 之间互斥。此时 O 权重高于 P，对于 X Y 而言 A1 权重最高，Z 而言 C1 权重最高。

那么此时在购物车的显示如下图：

朴朴（线上超市）促销系统模拟

优惠活动示例

用户可以在 O 这里可以切换成 P，也就是可以切换为同样能应用于全部 XYZ 的其他优惠活动；同时可以手动单独切换 X Y Z 的所有可选优惠，如把 Z 单独从 O 的活动中解放出来单独设定为 P；或从当前 C1 切换为 C2，那此时还是和 XY 共同属于 O 活动的。

那么如果 O 与 C2 互斥，P 与 C2 可叠加，这一操作会使得 Z 商品适用 P 和 C2 两种活动，此时 P 和 C2 到底应该哪一个为先呢？从视觉上看，就是哪一个在上，哪一个在下呢？

我觉得比较合理的是这样：与计算权重相反，计算权重越高，越在下，从视觉上我觉得这样更符合习惯，也就是某活动下面列表中的商品我们先计算一下金额，再去看是否符合上面的条件，有一个汇总计算的感觉。

其实权重本身从商品的角度看，可以认为给商品的活动赋予了优先级，如 Z 商品有四种、两组活动，OP 一组，C1C2 一组，切换时等于是将这个商品的这一活动优先级手动临时提升到了组内最高，如果切换成其他的活动，那么原来的活动还按原有的权重去计算和比较。

还有一种特殊情况是，商品 Z 同时享受 A1 和 P，A1 的计算权重高于 P，此时界面上看起来就会是这样的：

朴朴（线上超市）促销系统模拟

同一活动分割显示

由于 P 在显示上要高于 A1，所以导致与其他 A1 活动商品分隔开了，这种情况下想清晰看到所有活动商品可能方案就只有点进活动详情，将已选择的商品放在最前面来展示比较好。

朴朴（线上超市）促销系统模拟

活动页面展示

当然实际上这种情况很少见，同一个商品有两种互斥的营销活动就比较多了，一般来说运营人员也不会这样去配置，毕竟对结算、计算成本、用户理解都会提高复杂度，所以在做后台的时候，我们应该在合适的时候提醒运营人员该活动与其他活动是否有重复商品，减少犯错的可能。

五、优惠券

这里把优惠券也划归促销系统，主要是考虑到使用人员和调用的系统基本是一致的。优惠券各个产品社区已经有很多介绍的文章了，这里也没什么特殊。划分类别从领用机制上可分为用户触发和系统触发。

其中系统发放可认为是用户无需做任何操作，系统出于补偿或活动发券，直接发放到用户账户中，活动发券又可以分为主动发放和被动触发，主动发放是直接发放到用户账户中，被动触发是当用户打开 app 或小程序时才发放到用户账户中（比如饿了么）。

用户触发可以分为用户直领和任务发券，用户直领就是在指定页面直接领取即可，任务发券则是需要完成一定的操作，比如下单、注册、拉新才可以领取的券。

字段的话主要也是使用 5W2H 分析得到的各类字段：

WHAT – 是什么类型的优惠券？优惠券名称是什么？适用商品有哪些？
WHY – 这里和促销活动是一样的。
WHO – 这里和促销活动也是一样的。
WHEN – 后台角度：什么时间配置的？前台角度：可领取的时间？可用的时间？绝对时间还是相对时间？是否要具体到时间段？
WHERE – 投放渠道是哪里？小程序、app；使用渠道又是哪里？可以满足比如小程序发券 app 使用来带动 app 下载使用量。
HOW – 具体的券规则是什么？如满减的数额，与其他活动和券是否互斥？权重多少？触发机制？用户领用还是直接发放？
HOW MUCH – 投入产出比如何？有无数量限制？每天限量还是限制总量？每人在单位时间内可以领用几张券？

这里维护的是固定业务模式的优惠券和优惠券池，也就是说常见的每日领券、下单返券、客服发券等，可以在这里维护，如果是涉及到关联券的活动，应在另一平台（暂称活动平台）维护，在活动平台可以设定具体的比如 H5 页面内容样式，页面有效时间，页面分享样式等内容，只需复制优惠券系统的券编号，即可关联此处设置的优惠券。

如果业务的组合有更多丰富的形式，则可以在设计系统时有更多的解耦，在这里只维护各类基础的优惠券，完全不涉及业务规则，将一切业务规则转移到活动平台来维护。