请以系统的观念对待活动策划

在日常的活动运营中,我们常常会发现活动的设计很多是类似的,虽然各种不同的网站与产品的运营重点不同,但是从活动种类来说,大致会有以下几种:

抽奖类活动:满足一定条件的用户参与抽奖,抽奖的类型可以是礼盒、转盘、彩票开奖结果、股市指数等,时效可以是即时的(立即开奖)可以是延时的(指定时间公布开奖结果),奖品可以是现金、实物或者虚拟物品(积分、游戏的道具、商户的优惠券等等)。

红包类活动:满足一定条件的用户可以获得红包,红包中有一定金额的可以抵扣的代币或者现金,有些可以提现,有些不可以提现,红包可以限制使用场景。

收集类活动:用户通过行为去进行收集,收集后的物品可以组合或者单独进行兑换。比如,集齐七颗龙珠召唤神龙其实就是收集类活动。

返利类活动:用户满足一定的消费金额和笔数,可以获得返利(可以是现金,也可以是积分),返利获得的奖励可以限定使用场景。

竞猜(彩)类活动:用户参与活动,进行竞猜(彩),赢取奖励,多见于世界杯年。

活动的目的,无非是着眼在两个层面:

促进用户行为相关:注册、活跃、付费或者转化以及其他需要短期进行提升的用户行为;

促进网站或产品指标相关:功能使用频次,电商客单价、转化率,社区UGC数量等;

这两个层面其实是互相促进与联动的。

因此,不管是我们自己做活动,还是看别人做活动,基本上,活动的方式和方法都殊途同归,那么问题来了,如果我们并没有从运营层面上研究出新玩法,仅仅是在不同的时间点进行不同的包装,对于活动运营或者活动策划本身,我们究竟应该抱以什么样的态度和观念?

如果我们回想一下近年来比较热点的活动,我们可能会想到两个:

淘宝“双11”活动和新浪的“让红包飞”。

这两个活动几乎成了每年11月11日和每年春节期间必然会有的大型活动。

说到双11,你的心里是否会浮现出这样的暗示?

那么,说到“让红包飞”你会否有这样的感受?

为什么会产生这样的结果?

首先,这两个活动代表了一种活动类型:周期性活动或者我们称为定期活动。

然后,这两个活动的玩法或者说运营方式并没有很大的变化,且和自身的核心功能关联紧密,因此,无需付出更多的教育用户的成本。

从这个角度来看,我们会发现,对于活动运营者来说,如果不从系统的角度去思考活动的设计和策划,往往会做很多重复的工作。

比如,国庆节做了一期转盘抽奖活动,到了春节还想做一期九宫格翻牌的抽奖活动。如果我们从系统的角度去考虑,可以对开发提出需求,提供一个通用的自动抽奖后台,然后前台如何包装,都没有关系;如果我们不从系统的角度考虑,可能国庆节和春节要分别重新让开发写一段代码,来实现抽奖这个核心需求。

所谓系统的观念来对待活动策划,是对活动运营人员提出了一个考虑“系统复用”的课题,同时对活动运营人员还提出了需要具备周期性活动策划的意识。

什么是“系统复用”?

很简单,就是一套系统可以被用于多个场景。对于活动运营来说,就是有一个系统可以支撑多种活动运营模式,而无需再次开发。

为什么要“系统复用”?

产品开发和运营活动开发都是技术开发,需要美工设计和技术排期,特别对技术来说,如果在进行开发时,发现其实很多的内容都是过去已经开发过的,相信没有一个技术会对这种系统产生开发的热情,这和写策划和产品DEMO一样,重复的工作毫无价值。因此,我们必须要尝试学习系统复用的概念。

而系统复用,可以帮助我们:节省开发资源、缩短测试时间,快速完成上线。

什么样的系统可以复用?

从我的角度来说,可以复用的系统应该包含几个特点:

可扩展,系统本身的开放性很高,因此可以兼容多个产品设计方案的填充;可配置,调整配置就可以产生各种不同的效果;可通用,用户的需求有核心需求和边缘需求,系统也有核心功能和扩展功能,核心功能越没有针对性,可复用的可能性就高。

在这里我想用过去盛大积分的一个宝箱系统来说明,已有系统复用,可以做到什么样的程度。

宝箱系统,其实是一个可配置概率的后台抽奖系统。对于这类系统相信大多数运营人员和产品人员都不陌生,相信很多公司都有类似的系统,这个东西一般的使用场景,是在做活动的时候,在后台配置奖品的爆出概率。看到这里,先思考一个问题:你认为这套系统可以做哪些事情?

如果你可以不假思索的给出3个以上的答案,那么就不要往下面看了,如果你停下来思考,那么请往下面看。

盛大积分的宝箱系统在设计的,整个系统架构是由概率控制系统、奖品管理系统和宝箱管理系统这三个子系统进行配置设计的,我们用它做了很多有趣的事情:

1、基本功能:以宝箱系统作为抽奖后台,前台搭配不同的展现形式,比如:转盘抽奖、过节发红包、翻格子(什么打地鼠啦、九宫格啦、应景的其他各种抽奖)等等。

2、小扩展:由于在这个系统里,奖品的种类和数量其实是可以无限拓展的,由于有概率控制系统,于是,淘宝之前玩的集字游戏(收集类活动)也可以利用宝箱系统,通过配置被收集物的类型和数量,在前台各个可触发宝箱开奖的路径调用接口就可以实现。

3、开放平台:运营人员会碰到很多机会做与外部的联合活动,通过宝箱系统,我们可以在只做接口的情况下,快速的完成活动上线,并且满足不同联合活动的需求。

4、核心底层:我们后期将宝箱系统变成了一个抽奖引擎,加上了用户行为库、风控库和规则引擎,产生出了一个通用的用户行为奖励系统,通过这个系统,在后台配置活动规则与目标用户,通过调用活动模板库,可以快速的完成活动上线。

积分的宝箱系统最早是用来满足基本抽奖的,没有任何包装,就是开宝箱;后来我们想包装一下,于是转盘抽奖就直接推出来了,从决定做到上线,只花费了美工2天的时间,技术没有开发,测试只用了半天;(基础功能)

09年春节,我们想提升网站的PV,于是用宝箱底层,把打开页面动作和开宝箱结合在一起,直接推出了集字游戏,活动上线的结果是让服务器崩了,开发用了2天,美工用了1天,测试1天;(小扩展)

10年输出给某项目组使用,他们举办活动的时候,可以直接调用接口,随机开宝箱,送给用户奖品,这个开发基本没有花什么时间,联调花费1天;(开放平台)

10年下半年,我们通过新建宝箱名称,成功的打造了一款小的收集游戏,之后,这个小游戏立刻进入产品化用于对外输出,奖励接入方用户行为的一套系统。(开放平台+小扩展)

11年和13年上半年,通过宝箱系统作为底层,产出了积分的针对用户行为的积分发放系统和通用用户行为奖励系统。(核心底层)

这是“系统复用”的力量。

而周期性的活动策划意识是另一个活动运营系统观所需要考虑的事情。

“签到”是一个非常常见的周期性活动策划。从腾讯到阿里,不管是游戏(比如手游的每天登录送XXX)、娱乐(比如签到解锁表情)、会员(签到领淘金币、QQ登录再在线时长升级)等等,都在着力培养用户的习惯——经常上来看一下,久而久之就成了习惯。

周期性活动运营观念,从我的了解来说,最早可能是从游戏中来的,比如说,06年的《魔力宝贝》和《魔兽世界》都有活动日历的功能:

京东有一段时间,非常喜欢用日历——其实现在也很喜欢用:

永和大王2012年也推出过所谓“台历优惠券”(当然不能忘了肯德基也干过):

为什么大家会选择以这种方式呢?

很简单,周期性的活动有助于培养用户的习惯养成,可以减少宣传的成本,养成了习惯的用户到了时间节点会主动的参与活动。通过用户主动参与的行为,可以了解用户的偏好,对后续的活动运营改进有所助益。