编辑导读：促销玩法已是如今各个电商平台必不可少的售卖策略，用户通过低价买到了商品，也给平台带来了巨大的流量，是电商运营的“法宝”。本文作者围绕促销系统展开分析，希望对你有帮助。一、秀儿的故事秀儿是一个电商产品经理，有一天，业务方小张把她兴冲冲的叫出去，说：秀儿，我们想办个活动回馈，不用很复杂，简单点就行。秀儿一听到“不用很复杂”“简单点就行”这种字眼就心里直打鼓。小张说了他的需求：我们申请下了一批预算，用户下单支付时满满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，用户实付金额是80c.阶梯满减、阶梯满折满减：如每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可以在同一个时间叠加不同的促销玩法，这就需要产研前置考虑到各种并发情况。促销的手段千变万化，对于每年某宝双十一的玩法复杂到笔者早已败下阵来
本文出自快速备案，转载时请注明出处及相应链接。