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

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

如何从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 原创发布于人人都是产品经理。未经许可,禁止转载。

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 有一个问题,比如一个活动是一天之内消费满了1000元的用户可以获奖,我要怎么配置这个获奖规则呢

    回复
    1. 本文没提及,一年前写的,还是有很多不足。
      你这个不适合做实时,走日终跑批吧。每日24:00拉用户当天累计交易数据,满足条件出发奖励系统发奖。

      回复
  2. 谢谢楼主分享,最近负责公司活动体系的搭建,看到了您的文章 帮助很大。
    但是有几点疑问需要求教作者,希望作者看到了 可以回复下
    1、数据传输方式,可以举例说明下吗?
    2、是否为链条,这个不太理解,是类似于活动的前置和后置活动吗?
    3、关联其他活动,活动与活动之间是如何进行关联的?我外的一场活动需要完成几个诉求,比如一个活动 新用户是0元购,老用户是分享得礼物,这样情况下,我们是如何管理的?

    回复
  3. 需要指定活动生效的端,PC还是H5,是在你的条件限制里面吗,谢回答

    回复
  4. 老哥 能给个联系方式吗

    回复
  5. 请教下:数据传输方式是指什么?

    回复
  6. 好支持作者 :x

    回复
  7. 好文,收藏。我目前来说。如何保持信息流的完整性是个难题

    回复
  8. 先mark在看

    回复