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

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

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

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

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

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

竞猜（彩）类活动：用户参与活动，进行竞猜（彩），赢取奖励，多见于世界杯年。

活动的目的，无非是着眼在两个层面：

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

促进网站或产品指标相关：功能使用频次，电商客单价、转化率，社区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年也推出过所谓“台历优惠券”（当然不能忘了肯德基也干过）：

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

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

3 从淘宝的卖家营销工具看活动的系统观念

电子商务和网络游戏，可能是互联网范围内，活动做的最多、最频繁的两个行业了。而淘宝，可能是活动工具系统化最深入的一家企业了。

让我们先看一眼淘宝为卖家提供了哪些推广和营销的工具：

如果我们分个类，大致是这样子：

我们用双11来举例的话，卖家报名参加双11，是在“淘营销”中，当然，这是Landing Page，而不是入口，至于入口，那其实就有很多了。卖家的店铺装修可以进、从卖家中心的“活动报名”也可以进、……

那么，就双11来说，淘宝提供了哪些工具呢？

1、店铺的免费装修，这种作法，强化了参与活动商家从界面上的统一性，显得不那么山寨。

2、双11专用的配置工具：

其中的打地鼠，其实就是我们在上一小节说的宝箱系统，可以给大家看一下配置页：

坦白来说，作为一个运营人员，如果拥有这样的工具，那么真的是纯粹看运营成本和各自的运营能力了。

再说的直白点，有没有奖品，多少人能中奖，完全要看运营人员如何进行配置了。

所以，我们常说，“运营之道，存乎一心”，这个后续我们再说吧。

再看一下淘宝提供的会员营销活动工具：

怎么样，是不是觉得卖家如果稍微懂一点运营知识，这些工具基本上覆盖了大多数的活动需求呢？

如果我们自己有这些系统，会不会极大的改善运营效率，从而有机会减少产品、运营、开发、测试等相关人员在一个活动上耗费的时间与精力，进而更有效的进行活动运营呢？

当然，系统是表象，而深层次更需要考虑的是：

1、提供出来的系统，应当是总结了大多数需求，可以满足大多数活动规则的产品。

2、如何去总结这些需求，并匹配到自己的运营工作中，才是最大的命题。

3、因此，有系统的活动观念，只是第一步，更重要的是实现系统。不管是一个系统的产品，还是一个周期性的活动计划表。想不重要，落地才重要。

4 内部活动与联合活动

说到做活动，活动运营人员经常在两个角色中转换：

内部活动：活动运营人员是驱动器，是活动的需求方。这一点几乎所有的公司，都是如此，对于内部活动，活动运营人员有很大的权限，可以决定做什么活动，如何实施，从而申请活动的执行预算，并且维护全程，让活动落地，有始有终。

联合活动：活动运营人员是调和剂，是活动需求的承接方和合作者。这一点，不同的公司有不同的分工，有的公司，活动运营人员同时还承担BD（Business Development 商务拓展）的角色，需要去和其他公司谈判，共担成本甚至让对方负担成本，采用联合活动的方式，来完成活动策划并让活动落地执行；而另一些公司，活动运营人员只是承接从市场（Marketing）传递过来的合作意向，去完成需求的整理及活动策划并让活动落地执行。

内部活动需要展开的并不多，我们在本章第一节中已经做了很多的说明，一个合格的活动运营人员，只要严格的按照成本-设计、风险-管理、数据-监控、效果-总结的做法来做，基本上就可以通过熟练度的提升、创意能力的锻炼、资源整合能力的加强，来提升整个内部活动策划、执行、管理的能力。

而联合活动（或称外部活动）就需要多谈一些。

首先要说的是需求确认与需求控制。

不管是承接活动需求，还是合作推进活动落地，都需要对活动本身是为什么而做，要达到什么目的，实现什么目标，进行严格而准确的定义。因为合作的基础是你有他没有的，而他有你没有的，说的直白一些，就是合作的双方需要各取所需。因此，联合活动的目的是必须要明确的，你想要的资源要通过什么方式从合作方转接过来，这需要准确的确认需求。

有一个误区：如果合作方出了钱，那么合作方就是大爷，提出的一切需求都需要满足。

这句话本身是没有问题的，但在实践中，如果真的如此执行，成本就过于高昂，因为可能合作方的需求大多数情况下是个性的。个性的问题在于，每个活动的实际需求可能是不同的。而且几乎无法复用。

这个时候，一个传统行里里经常说的方法就出现了：

客户预期管理。

首先来看客户预期，用一张图来表示：

基本需求是客户认为服务提供方本应提供的服务，是最基本应当提供的服务，因此，如果基本需求不能被很好的满足，客户就会不满意，而即便基本需求能够被满足的很好，其实客户也不觉得非常满意。而惊喜需求则是客户觉得你不会提供的服务，是一种超越了期待的服务，因此，不管满足的好不好，是否全面，客户都会觉得满意。而预期需求则是客户被告知、被教育会获得的服务，因此，这个预期需求实现程度的高低，与客户的满意度是呈正向的线性关系。

传统的管理客户预期的方法是：

对于我们的运营人员来说，这个方法其实是相通的，只是替换成了：

而这样做的原因其实还是：

实现自体的运营目标。

需求明确了，预期控制了，接下来做什么呢？

两件事：

1、围绕单一的合作活动，去做活动设计

2、总结合作活动的共性，去做系统设计

第一件事情，是为了实现当前的合作目标，第二件事情，是为了未来可以批量实现类似的合作目标，所以回过头来我们会发现，系统观念在运营工作中确实非常重要。

当看到第一件事和第二件事时，我们有时候会觉得迷惑：

单一的合作活动总有个性，即使做了系统，依然不能避免再次开发，那么做系统设计是否有必要。

我相信，很多商业产品经理的回答，都会是：绝对有必要。

从我的经验来说，很多合作活动的个性，区别在活动的包装，而活动的内核，往往没有区别，即便有区别，也区别并不大。当然，这里的没有区别，主要是对于同一类活动或者同一类合作方而言。

而商业产品经理之所以会回答有必要，则是因为他们通过客户预期管理，筛选出了最合适系统化的产品需求，然后做出了可以给大多数合作方使用的产品，从而可以获得更好的业绩。

以上，是乙方的做法，如果你是联合活动的甲方，那么做法其实就反过来了。

首先，你要明确进行联合活动的目的，确保联合活动是可以对你的目标产生价值的，可以符合你的预期。

然后，你要想办法了解甚至控制整个流程，避免被乙方牵着走。在这里你需要注意的是避免强人所难，但要保证合作预期效果的达成。