编辑导语：本文从平台性的营销活动切入，介绍了需求分析、产品设计架构思路和详细的单一活动模型设计，帮助大家熟悉底层逻辑，掌握核心要义，在产品初期就能够考虑到未来的扩展性、全面性，具有强势的扩展能力。
一、产品设计核心1.需求分析
针对平台性的营销策略活动，需求是比较明确的，而且市面上活动类型也层数不穷，如秒杀、满减、折扣、会员优享等等。需要做和可以做的有非常多的花样，每一种活动都可以单独立一个中小型的项目来去研发和实现，而难点也并不在一个活动的产品设计，而在于我们如何处理众多的折扣活动组合、活动之间的冲突矛盾，还有后续扩展活动的包容程度。
2.活动定义
当我们知道这个产品的难点在于处理各项活动之间的冲突矛盾，以及后续延展性问题，因此在设计初期需要清晰将各项活动进行定义。
从电商平台用户下单的路径来看，可以分为选择商品—>详情页—>添加购物车（可无）—>提交订单（结算页）—>提交订单—>付款等几个步骤，折扣活动能够触达用户并且生效的位置，只有详情页、提交订单时的结算页、付款，因此可以借此为突破口，可以将活动进行定义成4种类型：
1）个体商品折扣类
此类活动落脚点都为每一个个体商品，可以在原价基础之上进行的折扣。例如10元的商品A可以打折7折，打折之后为7元；商品A也可以应用到秒杀活动，价格为2元。
2）平台结算策略类
此类活动策略凌驾于与个体商品之上，是将全平台的活动进行统筹结算。此类结算出现购物车结算、用户提交订单、最终付款之前展现。
3）用户附加优惠类
此类型通常是平台和用户直接建立联系，会被赋予某种特定其权益，用户可以根据自身的情况，在规则内自由使用。如优惠卷、折扣券、积分抵扣等。
4）实付抵消类
此类权益，是用户在确定具体支付金额的情况下，抵消实付金额。这种情况更多偏向于属于用户的个人行为。平台支持此类权益，但是会有第三方把优惠差价给予平台补助。
3.活动冲突、边界
接下来需要处理的就是，处理和解决不同类型活动内部冲突和活动之间的边界与关联。
内部冲突：
平台结算策略是属于全平台的，随着店铺和商品的种类繁多，情况也较为复杂，划分原则：
用户附加优惠，属于平台和个人建立某种联系，此时个人可能会有多项优惠权益，但是在同一笔订单当中，只能选择一种优惠方式。通常平台会自动帮助用户选择最优惠的权益。平台结算出结果后，可以通过平台内，例如积分、金币等权益进行优惠。
实付抵消类，是指在实付金额的基础之上进行抵消，通常是第三方支付平台进行的补助和促进消费。唤起第三方支付平台时，通过此类权益可以抵消实际支付金额，而中间优惠差价，通过其他途经补充给平台。
外部边界与联系：
个体商品折扣、平台策略结算、用户附加优惠、实付抵消，属于层层递进的关系，因此在设计这几类活动边界和联系时，需要考虑下面的层级如何适配与包容上面的层级。
平台策略结算，通常发生在购物车内，因此首先需要判断的是有哪几种平台策略活动，这些活动是否在当前购物车中命中（命中需要考虑商品范围、数量、店铺范围等），一旦命中需要将触发的策略进行优先级排序，把最具有优惠力度的策略进行呈现给用户。
用户附加优惠，最平台策略计算最终产生的数值基础之上进行优惠即可；而实付抵消类更是在付款之时触发的逻辑。实付抵消，需要看平台支持哪些第三方支付平台。该类的优惠也是由第三方发起。
二、产品框架搭建
平台性的营销活动底层搭建是复杂的，而扩展的活动量级也是可预见的。这里的产品框架相对复杂的逻辑，可以借助MVC设计结构进行搭建。
1.MVC设计结构
首先简单阐述一下MVC模式，M（model）是指业务模型，V（view）是指用户界面，C（control）则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
而从产品设计的角度来说：
2.全平台框架设计落地
视觉展示层：
数据模型层：
1）活动基本数据：
2）活动商品数据：【参与活动类型】【活动id】【商品id】【商品名称】【优惠金额】（如果是平台结算，则无）
3）购物车数据：【用户id】【商品id】
三、单一活动设计
整体框架是基础，全局的规则搭建之后，就可以按照自己的节奏将具体的活动规则进行逐一迭代，这里选择几种不同类型的活动进行详细说明。
1.定价秒杀活动
逻辑描述：
详细设计：
1）原型设计
2）活动管理
3）订单管理
2.满减活动
四、总结
文本通过平台性的营销活动作为切入点，从需求分析到产品设计架构思路，最后详细的单一活动模型设计都有一个比较详细的介绍，希望大家后面在接手类似的项目时可以从核心的底层逻辑进行思考和设计，能够为整个产品夯实更稳定的产品结构，同时有强势的扩展能力。
本文由@形风原创发布于人人都是产品经理。未经许可，禁止转载