微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作

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

来源:人人都是产品经理 2035

如何从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,主流程和对应的关键接口(如活动参与接口、奖励发放接口等)一定要跑通。

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

五、最后

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

文章来源:人人都是产品经理

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

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND dw_posts.ID not in (272596) AND(dw_term_relationships.term_taxonomy_id = 15783 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 5

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号