Entrar Agora 昨天下午，产品姐姐在群里连发了几个哭脸，说对着电脑憋了半天，光标就在“商品优惠券”和“订单满减”之间来回闪，一个字都写不出来。需求单上只丢了一句话：“商品优惠券、订单满减，可以任意选。”没头没尾，她整个人都是懵的。
她纠结的地方其实很典型：商品折扣和订单折扣，到底是混着用，还是只能选一个生效？混用的话，金额怎么分摊？互斥的话，用户又该在哪个环节做选择？这种问题一到年底就扎堆，各个平台的优惠铺天盖地，不光用户算得头晕，设计规则的人自己也容易绕进去。
我刚好最近在梳理营销优惠的整个流程，干脆花几分钟，拿一个普通人的购物过程把折扣层级拆开，说不定能帮她理清思路。
假设有个用户叫小白，想自己做蛋糕。她打开某宝，搜“蛋糕模具”，逛到一家免运费的A店，挑了个6寸活底模具30元，又加了一盒鲜奶油40元，一起丢进购物车。接着找色素，逛到另一家免运费的B店，一盒12色色素原价60元，她领了张单品券减10元，刚好店铺本身还有个“满50减10”的活动，算下来50元就能拿下。她又顺手加了一袋低筋面粉20元。
等她点开购物车，勾选这四样东西，系统自动试算出来的优惠就很有意思了：色素先享受单品券减10元，然后在B店内部，色素和面粉加起来70元，又满足了店铺满50减10，再减10元。这还没完，页面顶部弹出跨店满减——“每满100减20”。模具30加奶油40，再加色素50和面粉20，总共140元，满足100元那档，直接减20元。小白确认地址，准备付款，又看到收银台提示，用某宝支付能再减10元，用某银行卡还能随机减20元。她犹豫了一下，放弃了随机减，直接付了100元。
这个购物过程看似平常，但优惠其实一层套一层。按流程拆开，刚好对应四个层级：单品优惠、单店铺优惠、跨店或订单优惠，以及收银台的支付方式优惠。产品姐姐那个问题，其实就卡在前两个层级能不能叠加，以及怎么设计叠加规则。
每一层优惠本质上都是一套计算规则，最终要分摊到具体的商品上。单品折扣，比如立减、折扣券、单品满减，都是针对某个SKU，金额直接落在这个商品头上。店铺层面的优惠，比如店铺满减、店铺券，是对该店铺内所有符合条件的商品进行分摊。跨店满减或平台券，则是在合并支付时，按整个订单的总额计算，再按比例分摊到每个商品。
如果允许叠加，系统就得有一套分摊逻辑。像小白那个订单，B店的色素既享受了单品券减10元，又参与了店铺满50减10，最后还分摊了跨店满减。算下来，色素的实际支付金额被层层剥掉。如果不允许叠加，就得在规则里写好互斥逻辑：比如享受了单品券，就不能再享受店铺满减，或者反过来，用户需要在某个环节手动选择用哪个优惠。
设计的时候，有几个容易踩坑的地方值得多聊几句。
第一，互斥优惠怎么处理。如果系统里配置了某些优惠不能共享，购物车试算时就要把互斥的优惠分摊排除掉。比如商品A享受了单品立减，那店铺满减的金额就不能再分摊给A，只能分摊给其他商品。如果用户反过来想用店铺满减，那A就得放弃单品优惠。这时候，用户到底在哪个环节做选择？比较合理的做法是在购物车页面或结算页，让用户勾选参与哪些优惠，提交订单之前一切都可以改。
第二，订单金额修改的问题。提交订单后，金额已经包含了所有优惠分摊到每个商品的结果，我个人建议不要允许再修改待付款金额。因为一旦改了，优惠分摊就可能乱掉，退款、对账也容易出问题。如果订单超时未支付，优惠券要不要退回给用户？这个得看业务需要，可以在优惠券属性里加一个开关，配置是否逾期自动返还。
第三，跨店优惠到底算不算订单层面。有些平台没有店铺概念，选几件商品直接结算，那它就是订单层面的优惠。如果平台有店铺，跨店满减往往会合并多个店铺的订单，在合并支付时才起作用。设计时最好把“订单层面优惠”和“合并支付优惠”分开，这样更灵活，将来叠加规则也更清晰。
至于分摊金额的具体算法，粗暴一点可以按商品价格比例分摊，也可以按优惠前的金额均摊。比如小白案例里，跨店减的20元，按140元总价分摊，模具和奶油分摊得少，色素和面粉分摊得多，比例分配一下就行。具体怎么落，看业务倾向。
说到底，营销优惠设计最怕的就是规则叠床架屋，自己都解释不清楚。用户虽然懒得算，但系统得在每一层都算得明明白白。对于刚上手做营销产品的新人，我的建议是：先别急着画原型，把业务流程从头到尾走一遍，画一张优惠层级图，搞清楚哪些活动可以叠加、哪些互斥，分摊规则怎么写，再动手搭结构。这样，就算运营方提的需求再模糊，你也能把问题拆解成“在哪一层、用什么规则、能不能叠加”这三个问题，再逐个击破。
产品经理这条路，既要懂营销逻辑，又要能跟开发掰扯清楚，还得顶住业务方千奇百怪的需求，路还长，一起加油吧。
