如何从0到1设计一个营销活动后台呢？本文作者将从需求、概念设计、原型设计、以及开发与测试这四方面为大家一一解读，值得一看。

借微信公众号之便利，目前各个公司（已不局限于互联网公司）都频频利用公众号开展营销活动，与用户进行交互。相比传统PC/客户端营销便捷了不少，前端交互形式不断简化，越来越轻，但后端逻辑却日趋复杂。不论是淘宝、京东这些超级巨头，考拉、严选、唯品会这些一线大牌公司，还是滴滴、同程这些独角兽，营销活动的玩法越来越多。

而其中的变数，主要来源于活动逻辑和奖品逻辑，亘古不变，简单、朴素。

然而，很多中小型/初创公司，为了快速迭代，通常将营销活动的逻辑写在具体的活动中，或是只有一个简单的页面配置活动的基本信息。这在前期基本适用，但是当业务发展到一定体量，需要靠活动运营、用户运营发力，进行用户促活的时候，种种弊端就彰显出来了。

那么，如何从0到1设计一个营销活动后台呢？且往下面看。（看清了是从0到1，不是从0到100，我到不了100，欢迎大家跟我共同冲向100）

一、明确需求，并对业务有一个中长期的认识

与前端产品不同的是，后端产品主要面向的对象是业务/运营人员，虽然也会作为游戏规则制定者影响到用户，但是关注点还是在业务上。因此，进行后端产品设计时，需要与运营人员进行充分的沟通（如果本身就是运营，那么请多思考），确保系统在完全满足业务现有需求的基础上，增加可迭代性。

可以从以下几点进行思考（不限于此）：

• 目前业务发现处于什么阶段？
• 业务体量和发展速度是否需要活动运营来支撑？
• 如果需要，用户更偏向于那种类型的活动？如电商平台券类活动会多一些，社交平台曝光量重要一些
• 活动运营的形式能否抽象出来？
• 可以支持的奖励形式有哪些？

在思考之后，还需要冷静地对比一下，同行业竞品是怎么做的？因为同行业竞争对手往往有着与你类似的市场背景和格局，他们是否着力活动运营，或者已经开始相关客户关系系统的扩展？

明确需求之后，再开始进行产品设计。详见鱼骨图：

二、概念设计

在进行概念设计时，需要对后端系统有一个框架性的认识，在大的功能点下，可以逐层进行扩展：

整体架构如下，主要包含全局用户信息设置、活动类型、活动、奖励以及数据等几个方面：

从以下几个点，逐个进行分析：

1、记得在活动之上，加一个活动类型

有许多活动每个月会定期开展，如各大电商平台的会员日，但是每次的活动都会有些许不同。类似的业务场景很多，通过活动类型将部分活动进行归类，可以将共同因子抽象出来。

每个活动类型需要活动id，可以有研发进行定义。

2、具体的活动，逻辑的重中之重

在活动类型之下，就新建不同的活动，每个活动包含活动名称、描述、活动有效期、数据传输方式、条件限制、是否关联其他活动等字段。

通过活动类型id与活动id，可以唯一定位到一个活动，并且只在活动中开放关联接口。这么做的好处是：

1. 增加活动运营人员的条理性，每个活动都可以进行归类
2. 便于活动数据的调取，一类型活动可以通过活动类型id统一调取数据
3. 在保证各个活动独立性的基础之上，可以通过活动类型对活动进行统一调控
4. 减少外部接口调用风险，对不同商户，给出固定的活动类型id，对活动id进行更替

其中，活动设置中最核心的就是条件限制，通常会通过等级、新老用户、注册时间等多个维度进行条件限制，举例如下：

• 根据openid限制新老会员参与
• 根据是否X天内是否有购票/消费行为限制参与
• 根据注册时间限制参与

3、活动的奖励是什么？请把奖励单独拎出来

见过很多活动后台，在创建活动的时候直接完成了对应奖励的配置，这导致后续需要修改活动规则的时候，每次都要提交全部信息更新。建议可以将奖励单独拎出来，单独做成一个配置页。通过选择对应活动后，完成奖励的配置，即可完成活动与奖励的分离。

奖励具体分为很多种，也都应该有对应的奖励代码，通过活动类型id、活动id及奖品id可以唯一定位一个一个奖品。常见的有积分、抵用券、成长值、刷卡金等等，每一种奖励类型拉出来都可以说一天，尤其是抵用券，支付宝、微信、京东已经把抵用券玩得炉火纯青，加上互联网金融的崛起，抵用券这个概念已经泛化了，想想白条立减/免息券、京券、东券、支付宝红包、天猫红包、店铺红包、朋友的券……恨不得在所有决策场景中都增加一个抵用券，来促进用户决策。只有想不到，没有做不到。

当然大家都这么做肯定是有原因的，也因此催生出了很多抵用券相关的创业机会，这个后续在单独来谈。

初期建议直接采用经典的积分+抵用券的形式，完成基本的用户回馈、拉留存操作即可。

4、做好配套设置

所谓配套设施，就是贯穿所有活动体系中的一些因子，主要包括：

（1）等级管理

不一定是等级，也可以是成长值、成就、会员级别等等，一定是一个激励体系。此页面中，需要对等级、等级对应的经验、称号、奖励、头像等进行配置。

（2）活动信息管理

即是通过姓名、证件号、手机号邮箱、用户等级等信息完成用户个人信息的查询。

（3）消息发送管理

是否需要消息推送？有些需要，有些不需要。推送消息的目的，是更好的完成促活，所以针对不同的营销活动，选择不同渠道进行推送就非常重要。

（4）数据管理

奖励发放数据、用户个人数据、消息发送数据，都需要对应的页面进行查询和导出，便于后续进行数据分析（尽量少因为调取数据这种事打扰研发大哥可能会被打）

三、原型设计

不同于原型设计在前端产品中的重要地位，在后端产品设计中，原型设计不是特别重要。甚至在很多公司，后端产品是不需要原型设计的。

那么只要有需求文档就可以了吗？

在这个阶段，显然有一个比原型图更重要的东西，那就是数据（字段）。

后端产品可能会频繁与前端、外部等进行交互，故对接口字段的定义就尤为重要。一个活动的包含了哪些要素？除了活动类型、活动等信息外，还有积分信息、抵用券信息、以及用户全量信息等。从业务侧考虑需要几张表来存储信息？信息流是怎么样的？

这就是后台系统中的需求文档。

四、开发与测试

这个阶段最核心的是，很多在需求初始阶段考虑的问题，在实际开发过程中都很难实现，导致不可避免的对需求的更改。这种情况下，一定要确保基本框架的完好以及信息流的完整性。

而测试阶段，需要以最原始业务的需求进行测试用例的编写，尽量要求开发给出接口测试的demo，主流程和对应的关键接口（如活动参与接口、奖励发放接口等）一定要跑通。

这块非产品设计重点，主要是个人的沟通和项目跟进能力。

五、最后

没错，按照这个逻辑，一个基本的营销活动后台就搭建完成啦！（插一句，已提离职，恢复自由身不久，欢迎各位来撩）

附带一个思维导图，欢迎各位大拿来交流！

作者：whisperbot；公众号：灵魂为自己找一个伴侣（ID:vashresources）

本文由 @whisperbot 原创发布于人人都是产品经理。未经许可，禁止转载。