如何设计一个不好的促销系统

23年上半年，我在上一家公司负责面向香港市场的yuu APP（背后运营者是香港本地两大零售商之一的Dairy Farm – 牛奶集团，旗下有：惠康超市、Market Place by Jasons超市、711、万宁、美心等业务）的促销引擎升级项目，大型商超业态 超卷的香港零售市场叠加导致了复杂的业务逻辑，在此记录总结一下。

（图：DF直接运营、代运营、参股的零售品牌）

本文行文的顺序是：先分模块介绍促销系统的概要设计，然后总结应避免的坑。

一、从业务角度来讲，促销活动的目标只有一个

期望刺激用户买得更多、更频繁，产生更高的GMV。

超市业态很特殊，它的净利润率（Net profit margin）很低，是“低头捡钢镚”的民生生意，需要薄利多销。例如，国内经营水平很好的永辉超市2018年至2022年的销售净利润率分别为1.41%、1.71%、1.77%、-4.94%、-3.33%。在我目前的认知中——商超的促销规则是复杂度最高的，其他零售业态的促销玩法可以视为其子集。

二、促销系统的核心组成部分

从后台的角度来说，可以增、删、改、查促销规则。

从前台应用的角度来说，主要有两个场景：

1. 促销查价（线上：商品列表/详情使用；线下：价签使用）；
2. 促销分摊和算价（线上是购物车页、凑单页使用；线下是POS使用）。

1. 促销的类型

通过不同的维度创建促销，会产生以下的常见类型：

1. 单品促销（奖励限定为折扣）
2. 品牌促销（比如海飞丝品牌）
3. 品类促销（比如红酒）
4. 店铺促销（比如耐克店买200减50）
5. 整单促销（只要加进购物车的都可以享受）

这里的类型，会影响促销价格、标签展示（查价），也会影响促销的算价，一般都是以特定的优先级，算完一级优惠之后剩余的金额再参与下一个优先级的优惠计算。

2. 创建促销

上面的每一种创建的维度之下，如果把促销的玩法抽象出来，可以认为是：每一个促销都像符合这样一个描述：

Buy (门槛条件 门槛商品） Get （奖励类型 奖励商品）

拆解来说：

【门槛条件 门槛商品 – Threshold】：购买特定商品，满足一定的金额或满足一定的件数（满额 – Amount或满件 – Quantity），比如：“买¥10香蕉，则达到门槛”、“买3支香蕉，则达到门槛”

【奖励类型 奖励商品 – Reward】：参与促销的奖励类型有折扣、赠品、换购，以及奖励商品列表的设置：

• 折扣：主要有3种类型，最后体现的都是金额减免。“立减”，比如减20元；“百分比折扣”，比如享8折；“特价”，比如可乐1元。如：买满¥10香蕉，（香蕉）打8折
• 赠品：如果赠品是单个SKU，在线上的场景需要自动送；如果奖励类型是多个SKU，则需要用户自己选择。线下场景需要在价签提示，让顾客自己拿赠品一起结算。如：买3支香蕉，送2颗樱桃
• 换购：用户可以用优惠的价格换购指定范围的商品，大致有两种类型。一种是满足主品门槛后，可以一件一件换购指定的从品，最多可以换N件，比如“买满海飞丝品牌100元，可1元换购可乐，最多换购3瓶”。另一种是必须选择足够数量的换购品，以打包价换购，比如“买满海飞丝品牌100元，可以3元价格换购3瓶可乐”。

在以上三个要素的组合下，会形成一个确定的促销规则，比如“买3件A，送1件B”。在此基础上，我们希望鼓励用户买得越多省得越多，因此又衍生出两个机制：

【翻倍 – Repeat】：在翻倍的情况下，意味着可以重复达到相同的门槛，再多次领取相同的奖励：If 每买XX达到 【门槛】, then 分别获得【奖励内容1； 奖励内容2；奖励内容N】，最高翻倍N次。如：每买满¥10香蕉，打8折；最高翻倍5次。

【阶梯 – Tiers】在阶梯的情况下，意味着促销的门槛和奖励类型会升级（进阶）：

• If 买XX达到 【门槛1】, then 获得【奖励内容1】；
• If 买XX达到 【门槛2】, then 获得【奖励内容2】；
• 如：买3支香蕉，送2颗樱桃；买7支香蕉，送10颗樱桃。

3. 促销查价

查价是相对静态单个商品的促销信息查询，不涉及计算（只会计算单品促），信息包括：商品价格、促销标签、促销标签静态描述语，线上呈现的场景是商详、列表页。线下则是纸质价签、电子磅秤、电子价签。

4. 促销算价（及分摊）

算价，狭义来讲是指：给定数量的商品，计算订单的优惠总金额（及待支付总金额）。

算价的设计策略是分而治之。

我在2.1中提到了多种促销类型，这些促销类型如果混着算会非常乱，如果可解释的程度差，甚至可能会导致财务统计的问题。不同公司根据业务规则不同，会有区别，但是大同小异，我将通过以下例子说明。

假设我买了10件商品，原价总计是100元。如果跳过中间步骤（促销凑单），直接计算结算价格，那么首先需要考虑问题是：计算的顺序是什么。比如，可以按这个顺序计算：单品>品类>品牌>品牌>店铺>整单。

具体来说：

1. 这10件商品，其中5件设置了单品促销，各自扣除折扣金额后，剩余的商品总价是90元
2. 然后这90元的商品再看是否有命中品类促销，比如其中3件商品是可口可乐，命中了：“买软饮，买二送一”，节省的钱是5元（可乐单价5元），那么计算完品牌促销的剩余金额是85元。这三件可乐因为享受了上述的优惠，系统还需要使用加权平均的方式计算出一个优惠分摊后的金额=((5*3)-5)/3=3.33元。这个金额的作用一方面是便于给用户展示优惠后金额（以及财务成本核算），另一方面便于在产生退款时直接使用。
3. 以此类推，直到算完所有的促销类型。最终求和后会得到一个“优惠总金额“，以及”待支付总金额”。

上述是算价的骨干逻辑，也是无论线上线下都需要应用。

在此基础上，线上APP由于UI交互需要，增加了促销算价的复杂度。因为线下场景用户把商品一股脑都塞给售货员就行了，POS机只计算一个最终价格以及总优惠即可。但是线上场景有加购、凑单的过程，在这个过程中要体现进度、体现下一个阶梯/翻倍的条件，优惠需要预先演算，并呈现给用户。因此还有如下算价相关的难题需要解决：

1. 哪些商品未满足促销门槛，还差多少可以获得奖励？如何引导用户添加更多商品？
2. 哪些商品已经满足了促销门槛，并且获得了奖励？
3. 门槛满足后，奖励是自动获取的吗？还是需要用户主动选择（赠品、换购品）？
4. 购物车中的商品如何分组，会让促销组合、计算、引导更清晰的呈现？
5. …

这些问题需要购物车系统、凑单系统，结合促销引擎的能力，提供针对线上购物体验定制化的设计。

5. 促销的非核心的组成部分还包括但不限于

1. 促销上游的数据处理。在之前公司的业务场景下，促销数据的创建是由商家的ERP创建的，有一个中间层来处理多个商家的促销数据映射，把不同格式的促销数据都转成我们促销引擎认可的促销数据格式，并下发给我们内部的下游系统消费。
2. 促销返利计算。在零售业务场景下有很多促销的成本承担方是供应商，因此当用户下单且享受促销后，零售商会按照商品享受的促销金额找供应商要返利。
3. 电商公司一般都会说大促的流程是：招/选/搭/投（招商、选品、搭会场、投放），所以招商（活动提报）、选品也可以理解为促销的前置关联环节。
4. …

我个人的经验有限，就不一一列举了，熟悉上下游业务的朋友也可以在评论中替我补充。

三、需要避免的坑

1. 促销上游数据

线下数字化改造的项目，或Saas服务会遇到这个问题，一般自主研发的促销系统不会有这个问题。这里说的是：当存在两套促销系统时，两套系统之间需要进行逻辑映射、数据同步。就这个问题而言，应该以最快的速度切换成一套系统。否则，会剪不断理还乱。会遇到各种逻辑转换的问题、兼容问题、数据实时性问题。

2. 算价

我在做这个项目的时候，业务规则上有个很变态的要求，简单来说是：有4个类型的促销，之间没有优先级，哪个优惠节省的金额最高，就应用哪个。

业务这样做的原因是，香港的商超零售竞争激烈，每家超市都希望提供最优惠的价格，而且大部分的让利是供应商承担的，如果按照上述优先级规则计算，可能用户最终获得的优惠并不是理论上最优惠的。这样的处理，在线下不会有问题，因为顾客只需知道最终的优惠结果。

但是放在线上由于需要引导用户凑单，整个过程就变得不可解释了，违背了don’t make me think原则——用户购物车命中的促销，会随着加购商品的变化而变化。UI无法设计成有稳定预期的引导，只能告知促销算价的结果。针对这一点，我建议是：促销算价还是要有优先级的，不应该为了追求极致的优惠而损失了顾客的可理解程度。

3. 凑单

虽然有上述业务限制，但是在跳着脚铐跳舞的情况下，产品团队和设计团队还是尽量让凑单的过程更清晰，展示明确的门槛目标（虽然会变）。不好的设计总是让用户捉摸不透，无法拥有稳定的预期。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！