系统|电商产品经理必备知识：促销系统入门( 二 ) 工程师|需求|usb|电池|口袋|外部

c.满返券订单确收后，返给账户一张优惠券
d.套装套装是两个及两个以上的商品打包在一起，套装的价格比单品总和的价格要更加优惠，用户必须一次性购买套装里的所有商品才可以享受套装价
实际case举例
购物车页面其实就需要调用促销的算价服务来进行算价，如果金额在用户预期内，那么用户会提交订单，完成支付，看一个C端用户感知购买命中促销的实际的case：
某电商APP：
购物车展示订单金额，点击【结算】后跳转下单页

文章插图
下单页，点击【立即支付】，订单落库

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

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

文章插图
这里很重要的一点由于促销和钱极为相关，系统需要前置做很多安全相关的数据校验、规则校验（譬如不同促销是否互斥、如果是可以同一时间、同一sku的促销可以相互叠加，那么算价规则是链式叠加或者平行叠加）以及系统预警（促销价低于一定阈值时系统预警）等，防止由于配置失误被恶意薅羊毛。
三、PM的一点思考每一个在线上生效的促销活动，背后一定是有无数的各方业务沟通、以及最终配置、启用的。
对于产品来说，我们应该明确三点：
1. 底层系统的设计初期需要在设计中要明确模型，考虑【可拓展性】，如果后面要新增促销玩法时，你设计的这一套东西不能复用，需要重构或者重新做一套，这样成本过高显然是不合适的，这一点不只针对于促销，任何系统都是一样的。比如目前业务诉求是支持秒杀，后期如果想支持折扣的话，其实不需要涉及促销模型的调整，只是在原有模型上新增一种类型即可，这样做成本小、上线快；反之，如果在设计初期没有深入考虑，只是新增一个case，解决一个case的话，在后期的迭代中，研发和业务都苦不堪言。
2. 业务的sop线上的促销其实就像我们最早接触到的线下的各种打折、甩卖的活动一样，也是需要有人发起、有人参与、还需要明确活动的时间、活动面向的人群、活动的预期效果，最重要的是活动的预算由谁来承担。这不只是业务要做的事，产品也需要知道此次活动的sop是什么，甚至在业务不清晰的时候需要驱动业务指定规范的sop，如果没有明确的sop，那么促销的效果会大打折扣，而且会造成额外的资损，这些都是需要重点关注和考虑到的。