结论写在头里，好的运营活动一般具备下列要素：
○ 活动规则足够简单
○ 大多数用户能获得回馈
○ 用户能自发传播，自生长
“摇一摇”是我负责的产品功能，当然不是微信的摇一摇，而是另外一个产品的摇一摇。
我们摇一摇的规则很简单：用户摇动手机，抽取一次奖品，每天没有次数限制。
奖品大多来源于各家CP，有实物奖品和兑换码的形式。
大多数奖品是以网页的形式展示的，即用户摇动手机，展示一个网页，奖品或者活动相关的交互在网页中进行。
客户端：负责用户的摇动交互
服务端：分发奖品、记录中奖历史
网页：奖品相关的展示和交互
由于产品重心调整，该功能现在并没有开发资源支持，只有我和商务同学抽空运营和维护。好在之前找开发同学搞了一套页面制作模板，CP提供设计图，我们可以很快速地生成奖品页面并配置上线。
另外，产品开发期间把各种数据统计加的比较详细，还算比较有效评估每次活动效果。
为了满足不同CP的需求，只能看着数据，从运营活动规则入手。一段时间下来也总结了一部分运营经验。
下面是摇一摇历史上几次典型活动：
活动1.0：简单抽奖活动
摇一摇迎来的第一个商务合作是摇一摇送门票。
CP提供30张活动门票，该活动有明星出席。
中奖页面带有应用下载，长这样。
未中奖页面也带应用下载，长这样。
活动结果：奖品肯定全部发完了，但是应用下载量并不高
分析原因：用户来摇一摇是为了参加摇一摇这个活动，心理预期只有摇一摇，无论中奖与否，都没有下载应用的预期，因此带量效果非常差。
活动1.1：导流抽奖活动
在整理了活动1.0的问题之后，我们设计了微升级版的活动形式——导流抽奖活动。
这次活动CP提供了几十份实物奖品，我们经过沟通，在摇一摇活动同时，CP在自家应用内部也推出优惠活动。
中奖页面长这样：
未中奖页面样式：
活动结果：下载量提升效果明显，并且通过CP反馈的数据计算，激活率有60%，CP很满意。
分析原因：参加摇一摇的绝大多数用户都未中奖，虽然用户来摇一摇的预期只是摇一摇，但是未中奖页面给用户新的预期——“我都付出了努力还没中奖，干脆再对付出一点努力，下载应用拿点优惠”。仍然存在问题，绝大多数用户中不了奖，长久下来激励性不够。
活动2.0：摇一摇抽码活动
1.0时期的特点是：奖品数量少，通过促销活动导流。由此我们设计了2.0的活动规则：几乎所有用户都能获奖，到CP指定平台兑奖。
比如电商类CP，提供一部分满减券兑换码，用户摇到码之后，下载CP的应用，在应用内下单并使用兑换码。
中奖页面如下：
活动结果：活动效果也不错，和活动1.2的效果类似。
分析原因：活动效果几乎全受兑换码情况影响。比如京东无条件100元代金券，这种普适性的奖品就非常受欢迎，活动效果很好。但是如果是某母婴电商，又是满500减10的满减券，对于大多数用户来说几乎无用。为了控制活动效果，需要在筹备期间就与CP沟通，在控制成本的前提下争取尽量多的普适性的奖品。金额不需要太高，但是要求绝大多数用户可用。也有尴尬的事情，比如CP提供的奖品是电影票兑换码，要求用户到格瓦拉兑换电影票（CP并不是格瓦拉）。这样就变成了CP花钱推广格瓦拉了，最好在自己的产品里面找个位置，把兑票页面加进去，用户下载应用之后再应用内兑换。
活动3.0：如何让更多的人参与进来？
就目前情况而言，摇一摇1.0和2.0几乎可以满足大多数合作需求，效果也还算满意。但是我们作为运营平台的提供方，发现了一个问题：摇一摇留存率较高，新增用户较少，老用户占比太高。对于长期的运营活动来说，这可能并不是什么好现象。
我现在思考的问题是，不动用公司主产品的推广资源（push/banner等），如何在保证摇一摇规则简单的前提下，激励用户自发传播摇一摇活动？
假如摇一摇有次数限制，用户可以通过分享增加次数。然而次数问题是另外一个坑，有机会再细说。
摇一摇3.0，期望能让摇一摇的用户自己生长起来。【你得先有个开发】
