编辑导语：你是否遇到过电商平台公司的致电回访，有时还会给一系列的优惠，其实电商平台公司往往为了实现新用户转化或者老客复访复购，会采取一系列的运营活动。本文针对电商促销活动的产品设计进行分析。欢迎感兴趣的小伙伴阅读哦！
一、活动形式
活动形式可以归纳为三种，一种是优惠券直减或满减，一种是返现或者返券形式，第三种是低价购买商品。
- 第一种顾名思义就是像淘宝发放的红包或者双十一满200减30类似的活动，满足一定的活动规则可以直接付款的时候直接抵扣部分金额。
- 第二种是像拼多多的拼团，砍价，或者小米有品的下单立返等活动形式，花费一定的金额进行购买，满足一定运营活动规则后，返还给用户现金或者红包。
- 低价购买商品主要有单个商品金额直减或者加购商品直减，分别可以提高用户转化或者客单价。
二、产品设计及模块分析
图1 运营活动产品模块分析图
运营活动一般分为前端页面展示和后端系统支持，为了方便大家理解，脑图也是按照前端和后端进行区分的：
- 前端主要关注用户的路径，所以要对涉及到的页面进行详细的拆分，比如一般活动都会有单独的活动页面，个人中心会有对应的优惠券或者金额说明，另外还涉及到主路径上的用户引导，比如商品详情页的活动信息，订单支付页的优惠引导以及支付页面的优惠选择等。另外还有基础数据的埋点方便日后做活动的数据分析。
- 后端主要配合运营活动，涉及到的交易系统，需要兼容本次活动的优惠信息或者其他内容，比如一个订单的多个商品分摊红包的规则等。另外还有财务系统、售后、客服、CRB系统的信息兼容等。另外因为往往电商活动中的红包是真金白银的优惠，所以也会关注羊毛党，设置相应的防薅规则。
本篇文章主要从后端系统进行更进一步的分析。
三、活动配置
活动在创建的时候，需要进行一系列的配置，还有活动的选品。活动选品一般是通过计算优惠金额比例和商品实际的利润来选择的。如果活动让利太多，商品达不到盈利的效果，那么这个商品就应该被踢出活动池。从而可以看出，活动配置涉及到几个模块：活动管理、商品管理、活动商品池管理。
活动管理中应该是对运营的活动开关、活动规则进行配置。比如该活动针对什么样的人群，活动是不是有地域、渠道、时间的限制，活动返还红包还是现金，返还哪种形式多少面额的红包等。活动管理对一系列的活动进行控制和显示，如果平台活动形式比较多，而且每种活动配置不可通用。可以再细分二级模块对不同形式的活动进行管理。
商品管理，是对所有可以参与活动的商品进行展示。包括商品的SPU、SKU、商品的价格、必须属性、商家名称、库存等。另外还需要对商品的库存变动进行日志的展示。
活动商品池，即每一个活动，对应的可用商品池，可以配置多个商品池，但是在用的，只能有一个。如果该活动有独立库存，还需要进行设置，即其他活动不能使用这部分商品的库存。
最后，整的来说，电商的促销活动，离不开多种运营活动的规则。理清每一种活动的元素，规则和配置，整合成模块化的内容，一方面可以满足产品的扩展性，另一方面可以避免修改规则后前端重新发布版本。
图2 运营活动系统功能模块图
四、交易系统
每一种活动，势必都会涉及到交易系统的变化或者兼容。交易系统的关键，在于订单类型、订单状态、订单金额、订单优惠。
前提：我们预设平台的订单系统已经普遍适用，做成了订单中台服务。所以，有新增活动时，我们一般不去修改订单现有的逻辑。
订单类型：如果是和现有订单逻辑不兼容，那么为了不修改通用规则，可以考虑再现有订单的基础上，封装一层，或者再单独写一个独立的活动单，在用活动单去对应到普通订单上。比如买一笔订单，赠送一个商品。为了方便记录，可以单独做成活动单，记录参与赠送活动的资格和该笔赠送商品单的情况。用活动单将普通订单和赠送商品订单封装进行关联。单独对活动单进行设计。
订单状态：最好不要随便修改订单的状态，因此有新的业务活动，我们考虑活动单的状态机。分别考虑时机：创建订单（订单下单待支付）、订单支付成功、订单取消支付、订单生产中、订单发货、订单收货、订单关闭、订单退款，以及活动单对应不同订单状态，对应的活动单状态。创建订单时，校验活动规则，是否可以创建成功。订单支付时考虑该业务是否可以用各种现有优惠券等。取消支付时，是否超时自动取消还是必须主动取消？订单退款以后，各种优惠如何返还、愿订单商品是否可以单独申请退货（赠品不退、如何防止羊毛党）。
订单金额：如何计算支付金额、将优惠券优惠分摊到各商品、各订单。退款后各优惠、金额如何返还到用户账户。
举个例子：用户的红包可以叠加使用，但是购买了多个商品。退款之前，用户有新获得的红包，还有账户下有红包到达了过期时间。那么我们考虑退货时，红包的退回逻辑：
图3 红包退款逻辑图
另外，还可以选择按照退款金额，创建一个新的红包，这个都视具体的运营规则而定。
五、其他
另外在设计电商促销活动时，还要考虑必要的前端埋点便于进行后续的数据分析；财务系统考虑新订单类型、新优惠方式的兼容；CRB要涉及到用户召回或者活动推送push等；客服系统是要考虑到用户提问场景以及客服所需要的信息查询列表等。
六、总结
产品在梳理新玩法的时候，往往涉及的面会很广，各模块之间会有上下游的交互，后端模块也会和前端有关联。所以细节之处是非常多的，经常和上下游进行好信息的同步是非常重要的。如果有需要可以进行多次内审。另外和技术团队之间的沟通也需要注意，可能在会议中某模块的技术团队只听了自己直连的产品PRD宣讲，没有听到关联模块的宣讲，产品需要提前进行技术的沟通和协调。
最后，系统上线以后要及时和业务方进行培训、跟踪用户反馈、观察数据，从而进行版本的优化和迭代。
本文由@把个脉吧 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
