300 万粉丝的秘密：微信抽奖活动从架构到运营

抽奖活动，应该算是最古老的运营活动之一了，无论线上还是线下，商场还是超市，大转盘都无处不在。然而，在微信红包出现以后，抽奖活动便发生了质的飞跃，因为用户抽到的红包可以直接发放到零钱中，这可是真金白银的活动，而且立马可以体验到好处，刺激反馈非常实时。所以，基于微信的红包抽奖想不火都不行。

早在 2015 年初的时候，我司的运营同学策划了基于微信服务号的『天天大抽奖』活动，在那样的蛮荒时期，朋友圈活动还不会打击得特别严厉，因此借助于此固化活动，我们获得了数百万粉丝留存。当然，关于留存的部分，就不只是发钱这么简单了，还需要结合其他促销活动一起才能留住真正的优质用户。

曾经在很长的一段时间内，业界并未见到类似的微信抽奖活动，所以有好几家公司试图出巨资（数十万）购买我们的全套抽奖活动系统。这至少说明，基于服务号的完善的抽奖系统，是具有一定价值的。当然，作为公司来讲，我们不会去赚这些小钱，毕竟我们不是程序外包公司 ~

那么，本篇我们就来探讨一下，一个（相对）完整的抽奖活动，都需要考虑哪些东西。

1. 平台的选择

首先我们来说一下平台的选择，目前我们可以选择的主流平台大致有 PC、H5（移动端网页版）、APP、微信平台的服务号、微信小程序、阿里平台的天猫、手淘应用，甚至支付宝小程序等。至于具体选用哪个平台，要基于自身用户群体的分布，以及研发团队的技术积累，还要考虑一些新兴的处于风口的平台类型，比如微信小程序。 这里简单带过一些平台上可能产生的差异：

1.1 PC

PC 上需要考虑的主要是不能直接发红包的问题，电脑上的抽奖活动存在好多年，除了抽取积分、卡券、实物等，没有什么实质性的变化。另外一点就是大量的兼容性问题，比如圆形的转盘动画在低级 IE 浏览器就很难实现，所以之前许多抽奖活动都是用 flash 解决方案。

1.2 H5

除了兼容性问题少了一点（真的吗？）外，其他与 PC 特性差异不大。

1.3 APP

众所周知，APP 版本在各个应用市场存在审核时间的问题，但如果固话活动不经常修改，且变动部分都能由运营热更新实现的话，也是个不错的选择。因为原生 APP 可以实现更多流畅的交互体验，更多炫酷的效果。

1.4 微信服务号

这是我认为的最佳选择，撒钱真的很方便！而且开发也不复杂，服务号开发文档非常完善。

1.5 天猫、手淘应用

在淘宝开放平台上可以作为独立开发者（ISV）创建应用，然后授权给其他店铺使用，做得好还可以赚钱。不过，同样的问题就是，在成本一样的情况下，任何其他的奖品都没有微信红包诱惑大。目前笔者在淘宝开放平台还没有看到第三方应用的发放红包接口，即使有这种接口，作为第三方的应用，商户资金管理和审计也比较复杂，店铺不会把这种发放资金的能力交给第三方应用开发者的。

1.6 微信小程序

微信小程序目前只有支付能力，即收钱的能力，暂时还没有开放发钱的能力。不过如果一定要在小程序里玩，可以考虑通过 unionid 打通小程序和服务号的用户，在用户中奖时获取该用户在对应服务号下的 openid 再调用服务号的红包发放接口发放红包。

1.7 支付宝小程序：你说啥？

本文的案例始于 2015 年，彼时服务号方兴未艾，微信也将许多资源倾向于服务号的能力扩展，就像现如今的小程序一样，大家都没有想好怎么玩。所以，对于微信服务号这个平台，我们除了要做基本的『服务』之外，也希望尝试更多的玩法，加之微信红包接口已经开放，故，基于微信服务号开发的『天天抽大奖』活动应运而生。

2. 前期准备

2.1 服务号认证

抽奖活动至少需要服务号获得网页授权能力，这也意味着必须使用通过了微信认证的服务号才能玩得起来。而微信认证只针对个体工商户、企事业单位、政府组织等。这意味着你只要要能使用其中一种资质的证明材料。而对于一般的企业型账户，获取微信认证需要通过对公账户打款进行注册主体验证，也就是说至少要有对公账户。当然，对于正规的企业来讲，这些都不是问题，正常走流程跟公司申请对公账户打款即可。另外，每次认证需要缴纳 300元 费用，详见微信文档。

2.2 服务商平台

既然要做红包抽奖，那必须要有钱可以发放。服务商平台（https://pay.weixin.qq.com/）就是你可以充钱的地方，同样，申请服务商平台也需要提交对应资质，所有关于用户支付、企业打款、红包等功能均在此管理。对于开发人员来讲，发放用户红包还需要在此平台下载证书部署到服务器。

另外，大家可以参考下前一阵 @Javen 的 chat 《微信支付接入的那点事儿》，里面有详细的支付接入流程。

3. 界面设计 & 前端开发

3.1 界面设计

抽奖活动的界面设计主要要提现欢快热烈的活动氛围，但也不宜天马行空随意发挥，因为我们后面还有代码实现和运营的问题。比如整个页面的背景结构如果过于复杂，或者由于动效缘故要拆成若干部分，那么在更换抽奖活动主题的时候，就要做更多的改动。

3.2 转盘

对于抽奖动画我们也有很多选择，比如圆盘（指针转，圆盘转）、滚球、方盘跑马灯等。所有你在游乐场、澳门赌场等看到的抽奖玩法，都可以想办法移植到活动中来。这里值得一提的是，前一段时间京东凹凸实验室开发了一款推金币领券的游戏活动，其 3D 效果异常逼真，以至于被微信给屏蔽了… 感兴趣的读者可以搜索『凹凸实验室』公众号查看相关文章。

3.3 动画时机

这是个前端开发问题。对于动画执行的时机，最简单的实现就是先去请求服务器，拿到抽奖结果之后再执行动画。缺点就是，网络慢或者服务器响应慢的时候可能会有短暂等待。当然，也可以用有趣的进度条或者加载动画等缩短用户对这个时间的感知。类似的，先执行动画，当动画结束后再去请求服务器也是差不多一样的效果，当动画结束之后，也可能有短暂的等待时间需要处理。而最接近真实世界的方式，就是当用户点击抽奖时动画就启动，当获取到抽奖结果时动画就结束。

显然，这事儿没那么简单。首先，动画都是有过渡效果的，拿到抽奖结果后不可能戛然而止。其次，如果在请求抽奖结果的过程中网络卡顿一直拿不到结果怎么办？如果中间服务器报错了怎么办？请求没有响应要不要再尝试几次？在这个过程中动画怎么处理？最后，假设我们对外宣称是『100%中奖』，那么多次尝试之后服务器确实没有响应，转盘或指针要落在哪里？什么？落在最便宜的奖品吗？那么服务器没有记录可查，用户截屏过来要奖品，你给还是不给？

这里我们的策略是：用户点击抽奖则转盘开始转动，且开始请求抽奖结果。转盘从开始转动到最后结束分为三个阶段，即加速->匀速->减速。尝试多次请求或或网络延迟等问题，都可以在匀速阶段处理，如出现问题则适当延长匀速时间，对于用户来说只是感觉转盘转动比较久而已，想想《盗梦空间》中的陀螺。那么，如果最后真的报错了呢？你可以考虑让指针停在两个奖品中间，但是这样仍然会有争议。首先是太像 BUG，其次用户会说他一定会得到两侧的某个奖品，只是你这个东西出错了停在了中间。所以，最保险的方案，就是永远不要宣称『100%中奖』，永远保留『谢谢参与』用来兜底。

3.4 排行榜

多数情况下，抽奖界面上都会有个类似排行榜的模块，用来展示中奖用户和诱人的奖品。这里在界面上没有太多东西，不过是各种循环滚动动画、展示用户昵称头像等，如果是手机号，记得在 CGI 层面打码，不要泄露用户隐私就好。

3.5 用户信息收集

基本的表单提交需要前端的验证，对于抽奖业务中的实物奖品，则需要类似地址选择组件搜集用户收件地址。更严格一点，手机号需要验证码来