设计一个糟糕的促销系统的方法

发表时间: 2024-01-04 10:23

在复杂的零售市场业务逻辑下,产品设计团队要怎么做好促销系统设计?这篇文章里,作者分模块介绍了促销系统的概要设计,并总结了促销系统设计过程中应当避开的“坑”,一起来看看吧,或许会对你有所启发。

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. 促销的非核心的组成部分还包括但不限于

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

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

三、需要避免的坑

1. 促销上游数据

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

2. 算价

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

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

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

3. 凑单

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

本文由 @阡之陌路 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。