电商产品经理必备知识：促销系统入门

一、秀儿的故事

秀儿是一个电商产品经理，有一天，业务方小张把她兴冲冲的叫出去，说：秀儿，我们想办个活动回馈，不用很复杂，简单点就行。秀儿一听到“不用很复杂”“简单点就行”这种字眼就心里直打鼓。

小张说了他的需求：我们申请下了一批预算，用户下单支付时满满50-3,100-10，而且支付成功后还以可以额外获得一个赠品，对了忘记说了，如果活动开场前5分钟付款，还可以享受最优惠的活动价，这样的话对我们平台拉新引流肯定会有很大的效果，而且还能清一波库存，你看这个需求已经说的很清楚了，今天能上线吗？

秀儿此刻的心里想法：？？？

诚然，促销玩法已是如今各个电商平台必不可少的售卖策略，用户通过低价买到了商品，也给平台带来了巨大的流量，是电商运营的“法宝”，例如两个电商巨头JD以及TB，每年平台上的的双11、618大促是无数个买买买爱好者的天堂，促销可以在单个商品或者全场商品上生效，可以对商品售价进行促销，也可以对订单支付金额进行促销。

如上文小张提到，支持促销玩法仅靠一两句话就可以说清楚吗，答案当然是否定的，促销系统与订单系统、算价服务、及用户端等其他系统有着不可避免的交互，而其自身也有很多的限制和约束，这里面的门道可不少。

二、促销系统相关介绍

1. 什么是促销？

促销简单点可以理解为是一个“优惠活动”，比如我们去线下的商场逛街时，听到的“不干啦不干啦，清仓甩卖，只要998“，以此来吸引消费者进店消费，其实这就是一个很典型的促销活动。那么线上的促销可以理解为用户在线上消费时可以参加的”清仓甩卖“活动。

目前电商促销类型主要分为以下几种:

第一种：单品促销

a.直降，比如一般我们看到的立减、秒杀、团购、特价等

b.折扣. 某个品打多少折，如商品A原价100，活动打9折，那么实际购买只需90元即可

顾名思义，单品促销是作用在单个商品上的，这里其实还有一点区别，

一个是「降了之后的钱」，比如秒杀、特价。指的是最终的商品优惠价，如商品原价30元，秒杀价5元，就是说不管商品售价金额如何调整，那么在活动期间，秒杀价就是5元。

另一个是「降了的钱」，比如立减、折扣。都是说在商品售价上进行调整一个固定的优惠值，换句话说，商品售价要是一直在变，那么折扣或立减的后的优惠的值也会随着商品售价的调整而调整，如果商品价格经常变动的话，这种促销玩法更适用于运营对于成本的把控。

第二种：赠品促销

a.买一赠N ，比如买一支牙膏，赠一个牙刷，那么买的多赠的就约多

b.买N赠N，比如同时买指定的几件商品，赠某个商品

第三种：满减促销

a.满减或满折

比如满50-10，如果订单实付金额是100，那么优惠金额是10元，用户师傅金额是90

例如满50打9折

b.每满减，即满减累计，如满50-10，如果订单原价金额是100，那么减的是20，用户实付金额是80

c.阶梯满减、阶梯满折

满减：如每50-10，每80-15等，将满减分为几个阶梯，最高优惠N元封顶

满折：如2件8折，3件6折等，最高优惠N元封顶

第四种：其他促销

a.满赠 如订单金额满n元赠某个商品

b.加价购 如商品A原价30，商品B原价40，但如果买了A的话，可以只花25元获得B，这个就是加价购

c.满返券 订单确收后，返给账户一张优惠券

d.套装 套装是两个及两个以上的商品打包在一起，套装的价格比单品总和的价格要更加优惠，用户必须一次性购买套装里的所有商品才可以享受套装价

实际case举例

购物车页面其实就需要调用促销的算价服务来进行算价，如果金额在用户预期内，那么用户会提交订单，完成支付，看一个C端用户感知购买命中促销的实际的case：

某电商APP：

购物车展示订单金额，点击【结算】后跳转下单页

下单页，点击【立即支付】，订单落库

2. 促销和他的兄弟系统

促销是影响交易链路的一环，若新增一种新的促销玩法，必须核心链路感知并配合改造，不然即便促销系统自己独立上线了，那么也只是个没有任何意义的“假促销”。回归本质，促销主要目的为了促成用户交易，那么核心系统一定离不开算价服务、订单系统（订单和支付系统的交互、订单和售后系统的交互这里不多赘）。

1）兄弟系统交互

由于订单落库后，数据不可变更，所以严谨的来说，订单在落库前会再次调用算价服务的接口，将最新的订单金额与请求下单时的金额进行数据一致性校验，校验通过才会生成订单落库，若校验失败说明当前优惠已时效，需要用户重新提单。

这种临界场景还是比较常见的，如用户在购物车页面停留太久，促销活动恰好做了调整、或者提单的时候，恰好过了零点活动失效等等。一般订单上也需要记录此次命中的促销活动ID、促销金额等促销信息，方便后续售后系统获取进行相应售后服务单处理

2）b端后台页面

其实当底层模型搭建已经很清晰的话，页面其实落地很快的。B端页面把握四个要点「增」「删」「改」「查」，然后根据前期和业务的沟通，考虑到提示日常业务的使用效率，对于系统上的交互、展示的数据做进行梳理，最后落地成方案。

这里很重要的一点由于促销和钱极为相关，系统需要前置做很多安全相关的数据校验、规则校验（譬如不同促销是否互斥、如果是可以同一时间、同一sku的促销可以相互叠加，那么算价规则是链式叠加或者平行叠加）以及系统预警（促销价低于一定阈值时系统预警）等，防止由于配置失误被恶意薅羊毛。

三、PM的一点思考

每一个在线上生效的促销活动，背后一定是有无数的各方业务沟通、以及最终配置、启用的。

对于产品来说，我们应该明确三点：

1. 底层系统的设计

初期需要在设计中要明确模型，考虑【可拓展性】，如果后面要新增促销玩法时，你设计的这一套东西不能复用，需要重构或者重新做一套，这样成本过高显然是不合适的，这一点不只针对于促销，任何系统都是一样的。比如目前业务诉求是支持秒杀，后期如果想支持折扣的话，其实不需要涉及促销模型的调整，只是在原有模型上新增一种类型即可，这样做成本小、上线快；反之，如果在设计初期没有深入考虑，只是新增一个case，解决一个case的话，在后期的迭代中，研发和业务都苦不堪言。

2. 业务的sop

线上的促销其实就像我们最早接触到的线下的各种打折、甩卖的活动一样，也是需要有人发起、有人参与、还需要明确活动的时间、活动面向的人群、活动的预期效果，最重要的是活动的预算由谁来承担。这不只是业务要做的事，产品也需要知道此次活动的sop是什么，甚至在业务不清晰的时候需要驱动业务指定规范的sop，如果没有明确的sop，那么促销的效果会大打折扣，而且会造成额外的资损，这些都是需要重点关注和考虑到的。

3. 促销本身

大部分的电商行业都离不开促销，促销系统可做大可做小，复杂的可以通过角色来配置促销活动，同一个sku可以在同一个时间叠加不同的促销玩法，这就需要产研前置考虑到各种并发情况。促销的手段千变万化，对于每年某宝双十一的玩法复杂到笔者早已败下阵来?‍♂️，促销的目标也很明确：拉新、留存、提示品牌知名度，用一定的成本促使利益做大化。

这篇文章只是对促销做了简单的一些说明，给想要了解促销的同学一些通俗的解释。后面文章会逐个分析不同的促销类型是如何驰骋于交易的各个链路中，敬请期待。

本文作者 @闫秀儿 。

版权声明

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