「电商产品能力拆解」第 9 篇 · 促销体系上篇。交易链路收尾，进入促销域。上篇拆规则层（分类框架、计算引擎、叠加互斥），下篇拆计算层（优惠分摊、券体系、大促交付）。

先看一次”临时加一个满减”是怎么翻车的

周四下午 16：50，月底倒数第二天。 小A 刚写完履约售后复盘，运营主管莉莉探过头：「A啊，月底冲 GMV 差一截，帮我加一个满 200 减 30 吧，全场通用。应该不复杂吧？周五能用不？」

小A 打开后台心里过了一遍：①选类型（订单满减）→ ②设规则（满 200 减 30）→ ③定范围（全用户、全场、不限次）→ ④排时间（周五 10:00 生效）。后台标准配置，10 分钟搞完。验收两单：250→220，201→171，金额正确，提交上线。

周五 10:00 活动生效，运营群一片祥和。周六 10：00，客服群炸了。 用户晒单——原价 250 元的美妆商品，同时命中会员 95 折、新用户 9 折、满 200 减 30 和品类券满 100 减 20。

系统当时的计算口径是：先算两个折扣，再减订单满减和品类券。于是实付变成：

250 × 0.9 × 0.95 – 30 – 20 = 163.75 元

相当于打了 6.55 折。单独看每个活动都没错，叠在一起却把毛利打穿了。

莉莉慌了：「我没让你叠这么多啊！能不能先下线？」小A 打开后台——活动已生效，关键字段全灰，关停则断流、不关则亏。

事故复盘时，老张只问了小A 三个问题：

1. 这个满减在促销体系里属于哪一类？
2. 它进入哪一个计算阶段，门槛按什么金额判断？
3. 它会和哪些已有活动同时命中，叠加后最低能卖到多少钱？

小A 一个都答不完整。她会配置活动，却还没有一套判断促销需求的方法。

我后来做促销需求，第一步也不再问「后台有没有这个活动类型」，而是先回答这三个问题。因为促销真正难的，从来不是把满 200 减 30 填进后台，而是把一条新规则放进正在运行的规则网格里，还能知道它会撞到谁。

今天回答 3 个核心问题（上篇）

这三个问题，对应一个产品经理拿到促销需求后的完整判断链：

• 问题 1 · 它是什么：用 5 个元要素和二维坐标定位玩法
• 问题 2 · 它怎么算：进入统一计算管线，明确门槛基数与执行顺序
• 问题 3 · 它和谁冲突：判断作用域重叠、叠加策略与优惠上限

最后再补一张上线护栏表：活动在草稿、待生效、生效中、暂停、结束五个阶段，分别能改什么。

问题 1 · 它是什么：不是枚举玩法，是建坐标系

老张先问了小A 一个问题：

「市面上常见的促销，到底有多少种？」

小A 数了一遍：「满减、满折、秒杀、拼团、会员折扣、买赠、优惠券、免邮……至少十几种。」

老张接着问：

「同一品类买 3 件不同商品，总价打 85 折，算哪一种？」

小A 想了想：「不算普通满折，也不是单品折扣，好像是个新品种。」

老张摇摇头：

「促销名称可以无限包装，底层规则却是有限的。这条需求本质是 S2 品类级 × 比例折扣，触发条件是满 3 件不同 SPU。」

所以，理解促销体系不能只记玩法名称，而要先看：它由什么组成。

一张图装下所有促销玩法

所有促销，本质上都是同一组要素的不同取值组合。我把它归纳为 5 个元要素：

促销 = WHO（谁可以参与）

+ WHERE（在哪些商品上生效）

+ CONDITION（满足什么条件触发）

+ ACTION（给什么优惠）

+ LIMIT（能用几次）

每个要素取不同值，就生成了不同的促销玩法：

真正有价值的部分：二维分类矩阵

光有 5 元要素还不够——它们告诉你一个促销「是什么」，但不能告诉你「跟已有的哪些促销会冲突」。冲突的判断需要另一个维度：作用范围。

我把所有促销按两个维度建了一个坐标系：

横轴 = 作用的商品范围（WHERE 的抽象层级）

纵轴 = 计算方式（ACTION 的类型）

用这个矩阵定位任何促销需求——比如：

• 「同一品类买 3 件不同商品打 85 折」→ 定位到 S2 品类级 × 比例折扣
• 「全场满 200 减 30」→ S3 订单级 × 价格减免，CONDITION = 满 200 元
• 「前 100 名送赠品」→ S1 单品级 × 赠品，LIMIT = 总量 100
• 「会员专享全店 95 折」→ S3 订单级 × 比例折扣，WHO = 会员 Lv2+

这张矩阵图怎么用

场景一：运营来了一个新需求

比如「会员日全店 95 折 + 美妆品类额外 9 折」，你 30 秒就能定位：

• 会员日 95 折 → S3 订单级 × 比例折扣，WHO = 会员 Lv2+，CONDITION = 无门槛
• 美妆品类 9 折 → S2 品类级 × 比例折扣，WHERE = 美妆

两个格子不同——WHERE 存在包含关系（全店 ⊃ 美妆）——意味着它们能同时命中同一笔订单，需要进入问题 3 的叠加判断。

场景二：跟研发沟通时

不用只报一个玩法名，直接说：「一个 S2 品类级 × 价格减免，CONDITION 满 99 元、ACTION 减 20。」研发就能继续确认活动模型、适用范围和计算阶段。

场景三：不知道某个需求能不能做

翻一下矩阵里有没有对应的格子。如果格子里已经有多个玩法的案例了，说明这类促销的底层逻辑已经跑通，新需求大概率是参数配置，不是系统改造。

踩坑案例：当分类维度缺失的时候

某电商平台接了一个「同品牌买 2 件打 8 折」的需求。产品经理把它归类为「满折」，按 S3 订单级配了。但 S3 订单级默认扫描订单中所有商品——用户下单时只要订单里有该品牌 2 件商品就触发，哪怕其中一件是「该品牌 + 另一品牌」的捆绑 SKU。

正确的分类应该是 S2 品类级 × 比例折扣，WHERE = 该品牌、CONDITION = 满 2 件。S2 品类级的 WHERE 是精确到品牌范围的，不会误伤跨品牌的捆绑 SKU。

分类错一格，叠加规则、计算逻辑、退款分摊全歪。

问题 2 · 它怎么算：玩法不同，计算必须走同一条管线

小A 翻开后台看了一下历史代码，发现促销计算逻辑散落在五个地方——单品促销写了一套、满减写了一套、满折又写了一套、优惠券单开了一套、赠品也有一套。她问老张：

「这么多玩法，是不是每种都要单独写一套计算？」

老张的回答很干脆：

「不需要每种玩法各写一套流程。应该让促销进入统一计算管线，再把门槛基数、优先级、互斥关系、取整方式做成规则。」

这里要区分两个概念：

• 统一的是计算管线：商品优惠、订单优惠、券、权益依次在哪个阶段处理
• 可配置的是计算规则：满减按原价还是折后价凑门槛、同阶段取最优还是可叠加、金额保留几位小数

不是所有公司都必须采用同一顺序，但同一促销场景必须落到一套明确口径，而且商品详情页、购物车、结算页、订单和售后都使用它。

统一计算管线

行级实付 = 基础价格

→ C1 商品优惠：直降、单品折扣、秒杀

→ C2 订单优惠：满减、满折、满赠

→ C3 券优惠：单品券、品类券、店铺券、平台券

→ C4 权益结算：赠品、免邮、积分或返还

核心不是背一条万能公式，而是明确每类优惠在哪个阶段执行，以及下一阶段拿什么金额做门槛判断。

计算引擎的四个阶段

为什么执行顺序这么重要

踩坑案例：某平台的商品页按「原价凑门槛」展示满减，结算引擎却按「单品折后价凑门槛」。两端口径不一致，用户到了结算页才发现优惠消失。

商品A：原价 150 元，参加单品 9 折

商品B：原价 60 元，不参加单品折扣

订单活动：满 200 减 50

口径一：按原价凑门槛

150 + 60 = 210，达到 200 元

再计算单品折扣与满减：150 × 0.9 + 60

– 50 = 145 元

口径二：按单品折后价凑门槛

150 × 0.9 + 60 = 195，未达到 200 元

不能触发满减，实付 195 元

两种口径都可以成为业务规则，真正危险的是展示端用第一种，结算端用第二种，售后又现场重算第三种。

所以评审促销需求时，不能只写「满 200 减 50」，还要明确：

• 门槛按原价、活动价，还是前序优惠后的金额判断
• 同阶段多个优惠是互斥、择优，还是允许叠加
• 计算结果如何取整，尾差落在哪一行
• 计算快照是否随订单保存，售后能否原样回放

分摊先留一个钩子：整单优惠最终必须落到商品行

C2 的订单优惠和 C3 的券优惠虽然按整单计算，最终都必须分摊到商品行，否则部分退货时就回答不了「退这一件，到底退多少钱」。

具体分摊基数、尾差处理和逆向退款放到下篇展开。上篇先记住一件事：订单不能只保存优惠总额，还要保存每项优惠在每个商品行上的计算快照。

问题 3 · 它和谁冲突：从「能不能叠」到「叠完谁优先」

这是全篇最核心的一道关。

很多促销叠加文章都停留在「互斥 / 择优 / 叠加」三个词的层面。但产品经理真正的问题不是不知道这三个词，而是：

「两个促销摆在我面前，我该设置互斥还是叠加？互斥了用户看到哪个？叠加的话谁先算？」

三步判断框架

第一步：画出两个促销的作用域

一个促销的作用域 = WHO + WHERE + CONDITION 的取值范围。判断两个促销会不会冲突，首先要看它们的作用域有没有重叠。

促销A: WHO=全体, WHERE=品类「美妆」, CONDITION=满199, ACTION=减30

促销B: WHO=会员Lv2+, WHERE=品牌「XX」, CONDITION=无门槛, ACTION=95折

作用域重叠分析：

– WHO：A ⊃ B（全体包含会员）

– WHERE：品牌「XX」在品类「美妆」下 → 作用域重叠

– CONDITION：A 有门槛、B 无门槛

结论：一个会员用户买品牌「XX」的商品满 199 元 → 两个促销同时命中

第二步：判断冲突类型

作用域重叠只代表「可能同时命中」，不等于天然互斥。接下来要结合活动类型、成本承担方和业务策略决定怎么处理：

第三步：处理叠加顺序冲突

当确定可以叠加，接下来按系统约定的计算管线执行：

• 先确认计算阶段：C1 商品优惠 → C2 订单优惠 → C3 券 → C4 权益
• 再确认同阶段策略：互斥取最优、按优先级执行，或允许叠加
• 最后做结果校验：最低实付、最高优惠、毛利率和补贴预算是否越线

这里没有放之四海而皆准的「价格减免一定先于比例折扣」。真正应该固定的，是公司自己的规则口径和全端一致性。

平台多商家场景：配置权分散后的叠加治理

前面讲的都是一个品牌/一个商家自己的促销叠加——规则制定者是一个人或一个团队，协调成本可控。

但到了平台，问题变成：100 个商家各自配各自的活动，平台还要管跟他们平台活动的关系。配置权一分散，叠加治理的难度是指数级上升。

三层配置模型：

踩坑案例：商家和平台的「互斥」理解不一致

某平台双11，平台活动「跨店满 300 减 40」，商家A 报了个名。同时商家A 自己在店铺设了一个「满 200 减 30」。

商家A 设了叠加规则：自己的满 200 减 30 和平台的跨店满 300 减 40「互斥」。商家预期是——同一笔订单只生效一个（取优惠更大的那个）。

但平台的默认规则是：平台活动可以叠加商家活动。结果用户的订单被两层都命中：跨店满减生效、店铺满减也叠加生效了。

商家A 发现毛利被压到负值，找平台索赔：「我明明设了互斥，为什么还叠了？」

根因：商家设的「互斥」只作用于他自己的活动之间（店铺满减 vs 店铺满折），不作用于「商家活动 vs 平台活动」。跨主体的叠加关系由平台控制，商家没有权限修改。

修法：商家报名平台活动时，必须明确展示「是否叠加店铺活动」、预计最低成交价和成本承担方；是否允许商家关闭，由平台规则决定。关键不是默认开还是关，而是平台先定义清楚治理边界。

上线护栏 · 活动生命周期：什么时候还能改，什么时候只能止损

三个核心问题回答完，还不能直接上线。一个促销活动从创建到结束，会经历多个状态；状态一变，可修改字段、审批要求和用户承诺也跟着变。

小A 那次翻车，就是在活动生效后才发现叠加结果不对。此时范围、门槛和面额都已经锁定，只剩暂停或关停。

生命周期不是第四套理论，而是前三个问题落地时的最后一道护栏。

促销活动的 5 个生命周期节点

上线前至少确认 3 件事

• 待生效怎么修订：核心规则一旦修改，是否自动触发重新审批；紧急通道由谁批准
• 生效中怎么扩量：增加库存或名额前，是否重新试算最低成交价、毛利和补贴预算
• 暂停后怎么履约承诺：已领取的券、已加购商品、未支付订单分别按什么时间点切断

暂停策略没有统一答案。可以给已加购用户留过渡期，也可以立即切断高风险活动；但确认弹窗必须展示受影响用户数、未支付订单数和预计继续损失，让运营知道自己按下的不是一个普通开关。

自查清单：你的促销体系扛不扛压

分类与计算（3 题）

• 任意一个促销需求，能不能 30 秒内在二维矩阵里定位到对应的格子？
• 商品页、购物车、结算页和售后是否共用 C1→C2→C3→C4 的计算管线与门槛口径？
• 新加一种促销类型，需要改计算引擎代码吗？还是只改配置？

叠加与互斥（4 题）

• 每新增一个促销活动，有没有自动跑一遍「作用域重叠分析」、找出所有可能跟它冲突的已有活动？
• 叠加优先级规则在全端是否一致？会不会出现「C 端展示一个价、结算页另一个价」？
• 平台活动和商家活动之间的叠加/互斥，治理边界定义清楚了吗？商家能不能自己覆盖？
• 有没有出现过「运营说互斥、系统实际叠加了」的线上事故？

运营与生命周期（3 题）

• 每个生命周期节点（草稿/审批/生效/暂停/结束），运营知道能改什么、不能改什么吗？
• 活动暂停后，已领取的券和已加购的用户怎么处理？
• 生效中的活动，修改任何一个字段有没有审批流程或毛利预警？

总结：上篇 · 4 条促销认知

一句话总结： 促销不是配功能，是管理一张会自我繁殖的规则网格。

下期预告—— 上篇先把规则框架立住，下篇进入三个深水区：优惠怎么分摊到商品行、券从领取到核销怎么治理，以及双11前如何用沙箱、压测和熔断守住大促。尤其是那道最容易和售后打架的问题：退一件，到底该退多少钱？