营销中心如果把它单单、看作是发券平台，就太过简单了。完整的营销中心是集活动、券、规则、发放、审核、数据为一体的一站式解决方案。帮助运营人员发现问题、辅助决策、完成运营方案制定；帮助产品人员挖掘有效数据、构建画像。
营销中心形态各异，大致可分为：电商、门店和第三方营销平台。
淘宝、京东等电商平台的商家端都会配备营销中心，主要用于发券、建立活动和数据统计分析；饿了么、美团、盒马等外卖或新零售平台主要扎根于实体门店，帮助门店完成线上店铺的营销活动发放和线下门店的到店活动；第三方营销平台可以不提供线上店铺服务，仅作为渠道运营商存在，提供券、促销等运营活动的发放。
笔者给大家分享的营销中心具有普适性，可以兼容线上线下各场景。
一、营销中心的实质
营销中心这个字眼实在太庞大，仅靠一篇文章很难讲透彻，笔者接下来讲的也都是一些实战经验，如果有讲的不明白的欢迎踊跃发言讨论。
营销中心的发放/创建主体是一个主题（theme），例如：创建一个主题活动——“三八妇女节，逛吃逛喝我买单”，这个活动里可能会包含线上商城的优惠券、店铺券，也可能包含满减活动；其次，主题也可以通过H5页面传播，同样也可以通过线下易拉宝宣传。
这种组合方式最大化地分离了主题和内容，让营销平台使用起来更明确、数据统计更精确、用户画像更准确；同时在接下来的创建、审核和发放环节，同样益处多多。
上图是某平台规则设置页面的截图，基本上在规则方面都大同小异，下面这张图是笔者针对主题和活动概念设置的一些规则。
这里要强调几点：
规则是需要预设的：
我见过有的营销平台，规则都是现加的，更甚者直接在活动创建的代码里补充上，这是非常不可取的。一方面太过于麻烦，另一方面不便于数据统计和分析，在活动期间发生BUG等突发情况，纠错难度大
规则不可能全覆盖：
笔者一开始天真的以为：只要将所有的规则都纳入系统逻辑即可，规划中发现这是不太可能的。因为活动形式有千千万，新的活动形式也在日益更新，有的新活动就有新的规则，所以在规则预设上不需要太过于追求全面，尽可能覆盖当前活动形式即可。
不建议使用统一规则设置：
有的营销系统会将限制规则放在发放阶段去做，作为统一收口处。
但笔者不建议如此，其一，不同活动限制规则可能不同（虽然像有效期等规则是相同的，但仍然有不少规则是存在差异的）；其二，统一收口在多人员、多部门协同办公上可能存在问题，公司里创建活动和最后审核发放的可能是不同的人，关注的点不同，创建的人更关注活动细节，审核的人更关注活动全局，让审核的人去设定统一规则不太适合。
审核作为可选步骤，在这里主要强调两点：
如果不需要审核，也请写进系统逻辑：
审核在许多小企业中是可以跳过的，但是希望大家也督促后端开发将其写入底层逻辑中，至于审核与否，根据实际业务需求出发。往后如果需要加上审核逻辑，不需要再担心重大的逻辑变更问题。
多级审核逻辑：
多级审核的概念是指：多名不同级别的人通过多阶段的审核流程，批准通过或不通过。
在这里，我着重强调将主题、券、活动分开设置审核逻辑，且需要考虑逆流程。上文已经交代了，不同的人员关注点不同，领导审核主题的宏观信息，如利润、成本、时间等，运营人员审核的是活动和券的内容细节。
发放是笔者认为最为复杂和重要的模块，发放承接了主题（含活动内容），设置发放的信息，最终数据汇总也会受发放时设置的信息影响。
发放阶段主要设置以下信息：
发放渠道：渠道一般分为线上（app、小程序、公众号、双微等）和线下（门店、卖场、户外等）；线上线下又可以细分出很多场景，例如：线下自助POS支付后，线下POS支付前，门店活动区域扫码，线上分享，广告车/花车巡游，宣传海报，传单等。
消费方式限制：又称为核销限制，主要作为消费渠道的限制，可以分隔线上线下不同的运营方式、有效地引流和便于数据收集。
发放人群：不在设置活动和券的时候做，是因为发放人群是针对主题而言的，作为统一收口限制的规则。
发放位置：这块主要考虑到线上线下不同场景；同时便于运营人员在没有开发的配合下，就能完成运营活动的投放。
营销中心内的数据模块，主要展示活动相关，如：活动GMV，利润，拉新，促活，成交笔数，领取数量，使用数量，分享数量，用户画像等。
数据是作为运营分析和决策制定的关键因素，但数据模块过于庞大，笔者就不在这里展开谈论，想要详细了解大家可以自行搜索相关文章。
二、券和活动的区别设计
刚才在讲主题的时候，有提到过券和活动的概念。那么，现在就来讲一下：为什么故意要将活动形式分为券和活动（也可以理解为促销）两种呢？
笼统地将两者混为一谈，在系统设计开发上会造成逻辑混乱——规则设置、数据统计、运营目的都不同。券的概念类似红包，有立减和满减两种性质，都是在金额上满足消费者的需求；而活动更多样化，规则限定更灵活。
在结算时，也通常可以看到，活动是进入结算页面后自动计算的，而券（红包、奖励金等）是需要手动勾选使用的。同时，分开设计也可以将两者的可延展性最大化。
三、规则限制和互斥性
上文已经提到了规则，但是互斥性没有详细说明。互斥性的主要目的在于：
互斥性可以梳理活动与活动、活动与券、券与券之间的使用关系，对运营人员把控活动进度，开发人员编写代码都有很大的帮助；同时，消费者在使用或向消费者说明时，可以更明确，避免纠纷和争论。
营销中心的职责不仅仅是创建活动和券，发放使用就完事了。对后续的收银支付同样有深刻的影响。如果不明确互斥性，结算时系统无法或直接跳过校验，会直接导致经营亏损或系统报错。
互斥性对运营人员来说，控制成本是非常大的职责。
大家使用饿了么或美团外卖都会发现：商家的活动有很多，但是同享的并不多，满X元减X元是无法与商品特价同时生效。
这就是商家在做促销活动时，计算成本利润后作出的决定。
互斥性在一定程度上可以减轻由系统BUG造成的严重后果，例如：设定券和活动的互斥性，就可以避免当券可以无限领取时，导致的可能性的亏损。
那么，笔者是如何设置互斥性的呢？
完全自由组合：
这是笔者在面对着N多个活动和规则，抓耳挠腮后的想法。
完全自由组合的意思就是：当需要设置互斥性时，通过当前活动或券的适用范围（商品、店铺、品类、品牌等），来判定该适用范围有无进行中或审核中的活动或券，自由勾选后互斥。
举个例子：当设置NIKE所有商品的满减活动时，可以看到当前NIKE正在进行中和审核中的所有活动和券信息。勾选某个活动后，被勾选的活动和当前设置的满减活动就形成互斥关系。
这样做的好处只有一个：方便。
笔者不是偷懒的人，在设想完全自由组合的逻辑上，并不是觉得这样方便设计，而是考虑到之后线上线下共同运营时的潜在问题。
我之前做过大型超市的部门负责人，对线下活动了解的比较清楚，深知其中的自由度其实非常高。如果在营销中心设计上，做过多的限制，那么对线下而言无疑断送的不少财路。
所以，笔者通过规则去约束、通过自由的互斥性设置去放开活动组合的可能性。
五、结言
最后，笔者想补充一句：本文是笔者和开发、运营人员共同参与讨论、商议、梳理出来的底层逻辑，并不涉及原型设计，也没有教大家应该怎么去设计。
笔者强调的是底层逻辑，只有明确了大体框架和脉络流程，才能设计出正确的交互原型图，才能写出完整的产品PRD文档。
对本文如有疑问或发现问题，欢迎指正，欢迎留言交流。
来源：小鸡腿
