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

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

文章插图
由于订单落库后，数据不可变更，所以严谨的来说，订单在落库前会再次调用算价服务的接口，将最新的订单金额与请求下单时的金额进行数据一致性校验，校验通过才会生成订单落库，若校验失败说明当前优惠已时效，需要用户重新提单。
这种临界场景还是比较常见的，如用户在购物车页面停留太久，促销活动恰好做了调整、或者提单的时候，恰好过了零点活动失效等等。一般订单上也需要记录此次命中的促销活动ID、促销金额等促销信息，方便后续售后系统获取进行相应售后服务单处理
2）b端后台页面
其实当底层模型搭建已经很清晰的话，页面其实落地很快的。B端页面把握四个要点「增」「删」「改」「查」，然后根据前期和业务的沟通，考虑到提示日常业务的使用效率，对于系统上的交互、展示的数据做进行梳理，最后落地成方案。

文章插图
这里很重要的一点由于促销和钱极为相关，系统需要前置做很多安全相关的数据校验、规则校验（譬如不同促销是否互斥、如果是可以同一时间、同一sku的促销可以相互叠加，那么算价规则是链式叠加或者平行叠加）以及系统预警（促销价低于一定阈值时系统预警）等，防止由于配置失误被恶意薅羊毛。
三、PM的一点思考每一个在线上生效的促销活动，背后一定是有无数的各方业务沟通、以及最终配置、启用的。
对于产品来说，我们应该明确三点：
1. 底层系统的设计初期需要在设计中要明确模型，考虑【可拓展性】，如果后面要新增促销玩法时，你设计的这一套东西不能复用，需要重构或者重新做一套，这样成本过高显然是不合适的，这一点不只针对于促销，任何系统都是一样的。比如目前业务诉求是支持秒杀，后期如果想支持折扣的话，其实不需要涉及促销模型的调整，只是在原有模型上新增一种类型即可，这样做成本小、上线快；反之，如果在设计初期没有深入考虑，只是新增一个case，解决一个case的话，在后期的迭代中，研发和业务都苦不堪言。
2. 业务的sop线上的促销其实就像我们最早接触到的线下的各种打折、甩卖的活动一样，也是需要有人发起、有人参与、还需要明确活动的时间、活动面向的人群、活动的预期效果，最重要的是活动的预算由谁来承担。这不只是业务要做的事，产品也需要知道此次活动的sop是什么，甚至在业务不清晰的时候需要驱动业务指定规范的sop，如果没有明确的sop，那么促销的效果会大打折扣，而且会造成额外的资损，这些都是需要重点关注和考虑到的。
3. 促销本身大部分的电商行业都离不开促销，促销系统可做大可做小，复杂的可以通过角色来配置促销活动，同一个sku可以在同一个时间叠加不同的促销玩法，这就需要产研前置考虑到各种并发情况。促销的手段千变万化，对于每年某宝双十一的玩法复杂到笔者早已败下阵来????♂?，促销的目标也很明确：拉新、留存、提示品牌知名度，用一定的成本促使利益做大化。
这篇文章只是对促销做了简单的一些说明，给想要了解促销的同学一些通俗的解释。后面文章会逐个分析不同的促销类型是如何驰骋于交易的各个链路中，敬请期待。
本文由 @闫秀儿原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。