从四方面聊聊，如何从0到1搭建营销活动后台

　　如何从0到1设计一个营销活动后台呢？本文作者将从需求、概念设计、原型设计、以及开发与测试这四方面为大家一一解读，值得一看。
　　借微信公众号之便利，目前各个公司（已不局限于互联网公司）都频频利用公众号开展营销活动，与用户进行交互。相比传统PC客户端营销便捷了不少，前端交互形式不断简化，越来越轻，但后端逻辑却日趋复杂。不论是淘宝、京东这些超级巨头，考拉、严选、唯品会这些一线大牌公司，还是滴滴、同程这些独角兽，营销活动的玩法越来越多。
　　而其中的变数，主要来源于活动逻辑和奖品逻辑，亘古不变，简单、朴素。
　　然而，很多中小型初创公司，为了快速迭代，通常将营销活动的逻辑写在具体的活动中，或是只有一个简单的页面配置活动的基本信息。这在前期基本适用，但是当业务发展到一定体量，需要靠活动运营、用户运营发力，进行用户促活的时候，种种弊端就彰显出来了。
　　那么，如何从0到1设计一个营销活动后台呢？且往下面看。（看清了是从0到1，不是从0到100，我到不了100，欢迎大家跟我共同冲向100）
　　一、明确需求，并对业务有一个中长期的认识
　　与前端产品不同的是，后端产品主要面向的对象是业务运营人员，虽然也会作为游戏规则制定者影响到用户，但是关注点还是在业务上。因此，进行后端产品设计时，需要与运营人员进行充分的沟通（如果本身就是运营，那么请多思考），确保系统在完全满足业务现有需求的基础上，增加可迭代性。
　　可以从以下几点进行思考（不限于此）：
　　目前业务发现处于什么阶段？
　　业务体量和发展速度是否需要活动运营来支撑？
　　如果需要，用户更偏向于那种类型的活动？如电商平台券类活动会多一些，社交平台曝光量重要一些
　　活动运营的形式能否抽象出来？
　　可以支持的奖励形式有哪些？
　　在思考之后，还需要冷静地对比一下，同行业竞品是怎么做的？因为同行业竞争对手往往有着与你类似的市场背景和格局，他们是否着力活动运营，或者已经开始相关客户关系系统的扩展？
　　明确需求之后，再开始进行产品设计。详见鱼骨图：
　　二、概念设计
　　在进行概念设计时，需要对后端系统有一个框架性的认识，在大的功能点下，可以逐层进行扩展：
　　整体架构如下，主要包含全局用户信息设置、活动类型、活动、奖励以及数据等几个方面：
　　从以下几个点，逐个进行分析：
　　1、记得在活动之上，加一个活动类型
　　有许多活动每个月会定期开展，如各大电商平台的会员日，但是每次的活动都会有些许不同。类似的业务场景很多，通过活动类型将部分活动进行归类，可以将共同因子抽象出来。
　　每个活动类型需要活动id，可以有研发进行定义。
　　2、具体的活动，逻辑的重中之重
　　在活动类型之下，就新建不同的活动，每个活动包含活动名称、描述、活动有效期、数据传输方式、条件限制、是否关联其他活动等字段。
　　通过活动类型id与活动id，可以唯一定位到一个活动，并且只在活动中开放关联接口。这么做的好处是：
　　增加活动运营人员的条理性，每个活动都可以进行归类
　　便于活动数据的调取，一类型活动可以通过活动类型id统一调取数据
　　在保证各个活动独立性的基础之上，可以通过活动类型对活动进行统一调控
　　减少外部接口调用风险，对不同商户，给出固定的活动类型id，对活动id进行更替
　　其中，活动设置中最核心的就是条件限制，通常会通过等级、新老用户、注册时间等多个维度进行条件限制，举例如下：
　　根据openid限制新老会员参与
　　根据是否X天内是否有购票消费行为限制参与
　　根据注册时间限制参与
　　3、活动的奖励是什么？请把奖励单独拎出来
　　见过很多活动后台，在创建活动的时候直接完成了对应奖励的配置，这导致后续需要修改活动规则的时候，每次都要提交全部信息更新。建议可以将奖励单独拎出来，单独做成一个配置页。通过选择对应活动后，完成奖励的配置，即可完成活动与奖励的分离。
　　奖励具体分为很多种，也都应该有对应的奖励代码，通过活动类型id、活动id及奖品id可以唯一定位一个一个奖品。常见的有积分、抵用券、成长值、刷卡金等等，每一种奖励类型拉出来都可以说一天，尤其是抵用券，支付宝、微信、京东已经把抵用券玩得炉火纯青，加上互联网金融的崛起，抵用券这个概念已经泛化了，想想白条立减免息券、京券、东券、支付宝红包、天猫红包、店铺红包、朋友的券恨不得在所有决策场景中都增加一个抵用券，来促进用户决策。只有想不到，没有做不到。
　　当然大家都这么做肯定是有原因的，也因此催生出了很多抵用券相关的创业机会，这个后续在单独来谈。
　　初期建议直接采用经典的积分抵用券的形式，完成基本的用户回馈、拉留存操作即可。
　　4、做好配套设置
　　所谓配套设施，就是贯穿所有活动体系中的一些因子，主要包括：
　　（1）等级管理
　　不一定是等级，也可以是成长值、成就、会员级别等等，一定是一个激励体系。此页面中，需要对等级、等级对应的经验、称号、奖励、头像等进行配置。
　　（2）活动信息管理
　　即是通过姓名、证件号、手机号邮箱、用户等级等信息完成用户个人信息的查询。
　　（3）消息发送管理
　　是否需要消息推送？有些需要，有些不需要。推送消息的目的，是更好的完成促活，所以针对不同的营销活动，选择不同渠道进行推送就非常重要。
　　（4）数据管理
　　奖励发放数据、用户个人数据、消息发送数据，都需要对应的页面进行查询和导出，便于后续进行数据分析（尽量少因为调取数据这种事打扰研发大哥可能会被打）
　　三、原型设计
　　不同于原型设计在前端产品中的重要地位，在后端产品设计中，原型设计不是特别重要。甚至在很多公司，后端产品是不需要原型设计的。
　　那么只要有需求文档就可以了吗？
　　在这个阶段，显然有一个比原型图更重要的东西，那就是数据（字段）。
　　后端产品可能会频繁与前端、外部等进行交互，故对接口字段的定义就尤为重要。一个活动的包含了哪些要素？除了活动类型、活动等信息外，还有积分信息、抵用券信息、以及用户全量信息等。从业务侧考虑需要几张表来存储信息？信息流是怎么样的？
　　这就是后台系统中的需求文档。
　　四、开发与测试
　　这个阶段最核心的是，很多在需求初始阶段考虑的问题，在实际开发过程中都很难实现，导致不可避免的对需求的更改。这种情况下，一定要确保基本框架的完好以及信息流的完整性。
　　而测试阶段，需要以最原始业务的需求进行测试用例的编写，尽量要求开发给出接口测试的demo，主流程和对应的关键接口（如活动参与接口、奖励发放接口等）一定要跑通。
　　这块非产品设计重点，主要是个人的沟通和项目跟进能力。
　　五、最后
　　没错，按照这个逻辑，一个基本的营销活动后台就搭建完成啦！（插一句，已提离职，恢复自由身不久，欢迎各位来撩）
　　附带一个思维导图，欢迎各位大拿来交流！