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

您已获得免费畅听价值989元全栈运营微课的资格。

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

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

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

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

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

在进行概念设计时，需要对后端系统有一个框架性的认识，在大的功能点下，可以逐层进行扩展：整体架构如下，主要包含全局用户信息设置、活动类型、活动、奖励以及数据等几个方面：

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

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

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

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

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

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

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

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

（1）等级管理

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

（2）活动信息管理

（3）消息发送管理

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

（4）数据管理

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

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

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

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

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

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

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

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

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

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

【转载说明】若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com