数字化营销 - 促销活动业财一体化的思考【草稿】-网络知识

一、活动形式

活动形式可以归纳为三种，一种是优惠券直减或满减，一种是返现或者返券形式，第三种是低价购买商品。

第一种顾名思义就是像淘宝发放的红包或者双十一满200减30类似的活动，满足一定的活动规则可以直接付款的时候直接抵扣部分金额。
第二种是像拼多多的拼团，砍价，或者小米有品的下单立返等活动形式，花费一定的金额进行购买，满足一定运营活动规则后，返还给用户现金或者红包。
低价购买商品主要有单个商品金额直减或者加购商品直减，分别可以提高用户转化或者客单价。

二、产品设计及模块分析

图1 运营活动产品模块分析图

运营活动一般分为前端页面展示和后端系统支持，为了方便大家理解，脑图也是按照前端和后端进行区分的：

前端主要关注用户的路径，所以要对涉及到的页面进行详细的拆分，比如一般活动都会有单独的活动页面，个人中心会有对应的优惠券或者金额说明，另外还涉及到主路径上的用户引导，比如商品详情页的活动信息，订单支付页的优惠引导以及支付页面的优惠选择等。另外还有基础数据的埋点方便日后做活动的数据分析。
后端主要配合运营活动，涉及到的交易系统，需要兼容本次活动的优惠信息或者其他内容，比如一个订单的多个商品分摊红包的规则等。另外还有财务系统、售后、客服、CRB系统的信息兼容等。另外因为往往电商活动中的红包是真金白银的优惠，所以也会关注羊毛党，设置相应的防薅规则。

本篇文章主要从后端系统进行更进一步的分析。

三、活动配置

活动在创建的时候，需要进行一系列的配置，还有活动的选品。活动选品一般是通过计算优惠金额比例和商品实际的利润来选择的。如果活动让利太多，商品达不到盈利的效果，那么这个商品就应该被踢出活动池。从而可以看出，活动配置涉及到几个模块：活动管理、商品管理、活动商品池管理。

活动管理中应该是对运营的活动开关、活动规则进行配置。比如该活动针对什么样的人群，活动是不是有地域、渠道、时间的限制，活动返还红包还是现金，返还哪种形式多少面额的红包等。活动管理对一系列的活动进行控制和显示，如果平台活动形式比较多，而且每种活动配置不可通用。可以再细分二级模块对不同形式的活动进行管理。

商品管理，是对所有可以参与活动的商品进行展示。包括商品的SPU、SKU、商品的价格、必须属性、商家名称、库存等。另外还需要对商品的库存变动进行日志的展示。

活动商品池，即每一个活动，对应的可用商品池，可以配置多个商品池，但是在用的，只能有一个。如果该活动有独立库存，还需要进行设置，即其他活动不能使用这部分商品的库存。

最后，整的来说，电商的促销活动，离不开多种运营活动的规则。理清每一种活动的元素，规则和配置，整合成模块化的内容，一方面可以满足产品的扩展性，另一方面可以避免修改规则后前端重新发布版本。

图2 运营活动系统功能模块图

四、交易系统

每一种活动，势必都会涉及到交易系统的变化或者兼容。交易系统的关键，在于订单类型、订单状态、订单金额、订单优惠。

前提：我们预设平台的订单系统已经普遍适用，做成了订单中台服务。所以，有新增活动时，我们一般不去修改订单现有的逻辑。

订单类型：如果是和现有订单逻辑不兼容，那么为了不修改通用规则，可以考虑再现有订单的基础上，封装一层，或者再单独写一个独立的活动单，在用活动单去对应到普通订单上。比如买一笔订单，赠送一个商品。为了方便记录，可以单独做成活动单，记录参与赠送活动的资格和该笔赠送商品单的情况。用活动单将普通订单和赠送商品订单封装进行关联。单独对活动单进行设计。

订单状态：最好不要随便修改订单的状态，因此有新的业务活动，我们考虑活动单的状态机。分别考虑时机：创建订单（订单下单待支付）、订单支付成功、订单取消支付、订单生产中、订单发货、订单收货、订单关闭、订单退款，以及活动单对应不同订单状态，对应的活动单状态。创建订单时，校验活动规则，是否可以创建成功。订单支付时考虑该业务是否可以用各种现有优惠券等。取消支付时，是否超时自动取消还是必须主动取消？订单退款以后，各种优惠如何返还、愿订单商品是否可以单独申请退货（赠品不退、如何防止羊毛党）。

订单金额：如何计算支付金额、将优惠券优惠分摊到各商品、各订单。退款后各优惠、金额如何返还到用户账户。

举个例子：用户的红包可以叠加使用，但是购买了多个商品。退款之前，用户有新获得的红包，还有账户下有红包到达了过期时间。那么我们考虑退货时，红包的退回逻辑：

图3 红包退款逻辑图

另外，还可以选择按照退款金额，创建一个新的红包，这个都视具体的运营规则而定。

五、其他

另外在设计电商促销活动时，还要考虑必要的前端埋点便于进行后续的数据分析；财务系统考虑新订单类型、新优惠方式的兼容；CRB要涉及到用户召回或者活动推送push等；客服系统是要考虑到用户提问场景以及客服所需要的信息查询列表等。

六、总结

产品在梳理新玩法的时候，往往涉及的面会很广，各模块之间会有上下游的交互，后端模块也会和前端有关联。所以细节之处是非常多的，经常和上下游进行好信息的同步是非常重要的。如果有需要可以进行多次内审。另外和技术团队之间的沟通也需要注意，可能在会议中某模块的技术团队只听了自己直连的产品PRD宣讲，没有听到关联模块的宣讲，产品需要提前进行技术的沟通和协调。

最后，系统上线以后要及时和业务方进行培训、跟踪用户反馈、观察数据，从而进行版本的优化和迭代。

这篇学习到促销系统，促销是平台让利提高销量的重要手段，包括一般的促销活动（满减、满折、满赠等）和优惠券。主要相交互的系统是商品系统、库存系统、订单系统、crm（会员）系统。

商品系统用于指定活动的商品；库存系统可以划分出活动库存和一般库存；订单系统很重要的一点就是在结算这些活动时按什么顺序结算以及分摊到各个商品，会影响订单的最终支付金额和退款时的计算；crm 系统可用于精准营销指定可以享受活动资格的用户群体。

促销系统其实我们作为消费者已经知道了很多套路，尤其是最近几年天猫双十一的种种优惠，几乎没有什么促销方案在双十一中找不到的。所以其实归纳促销方案并不是重点，虽然如何把种种促销方案抽象归纳并形象化方便配置也很重要，但是更重要和复杂的还是重叠互斥和结算这一块。

原型链接：https://xd.adobe.com/view/80b51f95-d563-48bd-7f8f-38fea693b065-f684/

一、学习

有一篇文章从比较高的角度总结了促销类型和计算顺序，这篇文章首先是将促销类型归为三种：

针对商品单品（特定 SKU 或 SPU）的降价，如商品券，或者直接打折；
商品集合的降价。即以人工划分的商品类别为单位做一些营销活动，如某品牌系列的满减，或比如柑橘类水果的活动；
订单整体的降价，比如绝大部分优惠券是适用于整单的打折或降价的。

然后规定了大部分业务场景的结算顺序是按照以上顺序的 1 2 3 来计算的，在商品小计中先计算单品价格，单品降价后再看是否符合商品小计的活动规则，最后再计算订单整体。接着说明了一句很重要的原则： “同类型通过实体进行互斥、不同类型可以相互叠加。”

二、简单归纳

我认为他对于促销类型的总结和最后的原则都很合理，也体现了绝大部分业务场景。第三点原则的类型是比较具体的类型，比如满减是一个类型，满赠、满折、满额换购，都是不同的类型，实体是商品，也就是说一个商品不能参加两个不同的满减，或者两个不同的满赠，对于同一商品来说如果在同类型的两个不同活动中。那么这两个活动一定要是互斥的，而不能叠加。

在创建具体的活动时，我们可以手动来设定不同类型的活动 A 与活动 B 互斥或叠加，但是在总体上应该有一个基础的、同商品不能同时参加同类型活动的规则，这样可以使配置和开发时的代码没那么多冗余。

这里就要求我们在最开始设定类型时，要想好哪些活动是同一个商品绝不可以同时参与的。这个规则决定了抽象程度，如满减和满折如果认为都是降价类的，同商品不能两次降价，那么划归一类不可以同时参与，如果换购和赠品都属于低价获取商品类的，也划归一类不能同时参与。

如果只是不能满 50 – 20 后又满 10 – 5 这样叠加下去，但是满减后也可以满折，那么就满减、满折都是不同的类型。当然一般来说划分的细一点，比较可以适应之后活动的灵活性。但是对于第二点计算顺序我还是有些不同的想法。

当然了，订单整体的降价一定是放在最后的，但是商品单品和商品小计的顺序其实可以更灵活一点，通过配置权重来决定展示和结算的顺序，毕竟本身权重也是一定要配置的一个要素。

三、配置的基本要素

对于一个促销活动，也是可以用基本的 5W2H 来分析的。

WHAT – 是什么类型的促销活动？活动名称是什么？促销的商品有哪些？
WHY – 需求的目标是什么？这其实应该是促销人员思考的，在做一个活动时目的是提高销量，还是清空库存，还是带动客单价，来决定他配置一个怎样的活动。
WHO – 后台角度：谁配置的？是否有审核？前台角度：从 crm 中选择合适的用户。
WHEN – 后台角度：什么时间配置的？前台角度：可用时间？
WHERE – 投放渠道是哪里？小程序、app。
HOW – 具体的活动规则是什么？如满减的数额，与其他活动是否互斥？权重多少？
HOW MUCH – 投入产出比如何？有无数量限制？商品有无限购库存？用户端有无限购？

四、关于权重

我认为权重分为两方面：显示权重和计算权重，但实际上也可以只配置一个权重。权重是为了控制包含相同商品的活动与活动之间的关系，活动与活动的关系可认为只有两种：叠加和互斥。也就是对于同一个商品，活动 A 与 B 是可以叠加还是只能选择其一。

如果是互斥，那么默认为顾客选择哪一个就是显示权重，此时没有计算的先后可言，因为只能选一个。如果是可叠加享受，一定是要有个计算的先后逻辑；并且肯定是全部显示出来，但是哪一个为先呢？这个等下再讲。

具体到如何去设计这个逻辑，我的思路是填写数字而不应该是固定的一些等级，原因是如果同时期，首先配置了活动 A，包含商品 x，那么假若有三个以上的活动同时包含了商品 x，就很难去配置相互之间的关系。既然这个权重只是要在多个共存时确定一个“比较级”，那么只要有数字的比较就可以了，不需要确定的等级，甚至无需对数字作要求，如果喜欢，10000 也可以。

这个权重可以视为这个活动的一个标签，如果活动过期，即可释放这个数字。比如原有一组有重复商品的活动 A B C，权重分别为 1 2 3，C 活动过期，3 这个数字得到释放，新建活动 D 也与 A B 有重复商品，那么此时可以把 D 的权重设置为 3。

同时，在不同活动 A B C 有重复商品时，只需对 A B C 设定数字即可，这一组数字不会影响到另一组 E F G H 的权重。（这里的一组表示包含重复商品的不同活动）也就是说可以对 A B C 赋值权重 1 2 3，也可以对 E F G H 赋值 1 2 3 4，只要 A B C 与 E F G H 没有相同商品即可。

具体到前台的计算和显示上，示意图如下：

活动和权重

假设有三种产品 X Y Z，各自有图上所示的活动和权重。表格中的 O P 两种活动是与 ABC 活动可叠加的，O 与 P 互斥，A B C 之间互斥。此时 O 权重高于 P，对于 X Y 而言 A1 权重最高，Z 而言 C1 权重最高。

那么此时在购物车的显示如下图：

优惠活动示例

用户可以在 O 这里可以切换成 P，也就是可以切换为同样能应用于全部 XYZ 的其他优惠活动；同时可以手动单独切换 X Y Z 的所有可选优惠，如把 Z 单独从 O 的活动中解放出来单独设定为 P；或从当前 C1 切换为 C2，那此时还是和 XY 共同属于 O 活动的。

那么如果 O 与 C2 互斥，P 与 C2 可叠加，这一操作会使得 Z 商品适用 P 和 C2 两种活动，此时 P 和 C2 到底应该哪一个为先呢？从视觉上看，就是哪一个在上，哪一个在下呢？

我觉得比较合理的是这样：与计算权重相反，计算权重越高，越在下，从视觉上我觉得这样更符合习惯，也就是某活动下面列表中的商品我们先计算一下金额，再去看是否符合上面的条件，有一个汇总计算的感觉。

其实权重本身从商品的角度看，可以认为给商品的活动赋予了优先级，如 Z 商品有四种、两组活动，OP 一组，C1C2 一组，切换时等于是将这个商品的这一活动优先级手动临时提升到了组内最高，如果切换成其他的活动，那么原来的活动还按原有的权重去计算和比较。

还有一种特殊情况是，商品 Z 同时享受 A1 和 P，A1 的计算权重高于 P，此时界面上看起来就会是这样的：

同一活动分割显示

由于 P 在显示上要高于 A1，所以导致与其他 A1 活动商品分隔开了，这种情况下想清晰看到所有活动商品可能方案就只有点进活动详情，将已选择的商品放在最前面来展示比较好。

活动页面展示

当然实际上这种情况很少见，同一个商品有两种互斥的营销活动就比较多了，一般来说运营人员也不会这样去配置，毕竟对结算、计算成本、用户理解都会提高复杂度，所以在做后台的时候，我们应该在合适的时候提醒运营人员该活动与其他活动是否有重复商品，减少犯错的可能。

五、优惠券

这里把优惠券也划归促销系统，主要是考虑到使用人员和调用的系统基本是一致的。优惠券各个产品社区已经有很多介绍的文章了，这里也没什么特殊。划分类别从领用机制上可分为用户触发和系统触发。

其中系统发放可认为是用户无需做任何操作，系统出于补偿或活动发券，直接发放到用户账户中，活动发券又可以分为主动发放和被动触发，主动发放是直接发放到用户账户中，被动触发是当用户打开 app 或小程序时才发放到用户账户中（比如饿了么）。

用户触发可以分为用户直领和任务发券，用户直领就是在指定页面直接领取即可，任务发券则是需要完成一定的操作，比如下单、注册、拉新才可以领取的券。

字段的话主要也是使用 5W2H 分析得到的各类字段：

WHAT – 是什么类型的优惠券？优惠券名称是什么？适用商品有哪些？
WHY – 这里和促销活动是一样的。
WHO – 这里和促销活动也是一样的。
WHEN – 后台角度：什么时间配置的？前台角度：可领取的时间？可用的时间？绝对时间还是相对时间？是否要具体到时间段？
WHERE – 投放渠道是哪里？小程序、app；使用渠道又是哪里？可以满足比如小程序发券 app 使用来带动 app 下载使用量。
HOW – 具体的券规则是什么？如满减的数额，与其他活动和券是否互斥？权重多少？触发机制？用户领用还是直接发放？
HOW MUCH – 投入产出比如何？有无数量限制？每天限量还是限制总量？每人在单位时间内可以领用几张券？

这里维护的是固定业务模式的优惠券和优惠券池，也就是说常见的每日领券、下单返券、客服发券等，可以在这里维护，如果是涉及到关联券的活动，应在另一平台（暂称活动平台）维护，在活动平台可以设定具体的比如 H5 页面内容样式，页面有效时间，页面分享样式等内容，只需复制优惠券系统的券编号，即可关联此处设置的优惠券。

如果业务的组合有更多丰富的形式，则可以在设计系统时有更多的解耦，在这里只维护各类基础的优惠券，完全不涉及业务规则，将一切业务规则转移到活动平台来维护。