一个（相对）完整的抽奖活动，都需要考虑哪些东西？ 首先附上文章整体大纲结构：
（右击，在新标签页中打开即可查看大图） 抽奖活动，应该算是最古老的运营活动之一了，无论线上还是线下，商场还是超市，大转盘都无处不在。 然而，在微信红包出现以后，抽奖活动便发生了质的飞跃，因为用户抽到的红包可以直接发放到零钱中，这可是真金白银的活动，而且立马可以体验到好处，刺激反馈非常实时。所以，基于微信的红包抽奖想不火都不行。 早在 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 用户信息收集 基本的表单提交需要前端的验证，对于抽奖业务中的实物奖品，则需要类似地址选择组件搜集用户收件地址。更严格一点，手机号需要验证码来验证真实性，确保能够联系到用户。 再进一步，可以利用 GPS 定位能力，自动获取用户所在区域，只需要补充详细地址即可。现在许多快递公司或者有外送服务的服务号，都实现了类似功能，具体不再展开。 4. 接口设计 对于接口的设计，首先要考虑平台是否有需要整合的基础能力，比如公司主站的登录态与微信授权打通等，这里每个公司具体业务不同，不便展开讨论，我们只讨论一下抽奖强相关的接口设计。 4.1 微信网页授权 基于服务号的微信网页授权可以获取用户在该服务号下的 openid，作为用户在该服务号下的唯一标识，具体可以查看服务号开发文档。 至于 openid 是否作为用户的唯一标识，有许多种处理方法，一般还是建议自己维护一套用户 id 系统，不要直接暴露 openid 为好。 起码在数据库中，int 的查找要比 string 快。至于具体的授权流程以及 token 维护等，则是微信服务号开发的内容，不展开。 4.2 授权后操作 微信授权只是获取 openid 或其他用户信息的第一步，根据自身业务的需要，可能还需要用户继续注册或绑定手机等，才能真正算是你的用户。 在本文的案例中，我们也曾尝试过不要求用户注册，只要简单的授权即可抽奖的活动，但事实证明，这会带来许多问题。 一来只用 openid 标识用户，容易被羊毛党刷单，二来如果对于价值比较高的有价产品，可能还是希望他注册。而注册之后还要绑定之前的抽奖结果，而这个过程就可能带来安全风险。 因此，经过一段时间的尝试和权衡，我们把抽奖活动改成了必须先关注和绑定手机才能抽奖的形式。虽然参与度会有所下降，但也避免了许多不必要的麻烦。 对于授权后的绑定手机，手机登录还是帐号密码登录，是否需要验证码等，请参考自身平台的用户体系建设。 4.3 抽奖主接口 抽奖主接口主要用来获取中奖状态、奖品信息等。这个接口将会是承受压力最大的一个接口，因为总会有人试图单独刷这个接口，所以所有的防御机制都要体现在这个接口上，具体我们后面再聊。 对于接口吐出的信息多少也是要严格控制的，比如奖品的库存、中奖概率等信息。基本上，如果是简单的抽奖，那么这个接口只需要告诉用户是否中奖即可，也可以加上剩余抽奖资格等信息。 4.4 获取可抽奖次数 一般情况下，抽奖资格的获取可以混合到抽奖主接口中，不过也有一些场景需要单独判断抽奖资格，即是否允许抽奖以及能抽几次。比如用户刚刚进入抽奖界面时，或者执行了 “关注”，“绑定” 等操作后刷新资格的时候。 另外，部分安卓手机可能会缓存页面，如果在下一步操作中改变了抽奖资格（次数，积分变化等），再直接点击左上角返回，次数可能就不会变化。 因此，最好再抽奖动作之前先强制更新一下抽奖资格，而不是直接等待抽奖主接口返回不能抽奖的错误，因为这样会导致用户看到界面上有资格，但是每次点了之后又不能抽。这种情况下，还不如一次就让用户死心，如果真有投诉就如实相告，告诉用户手机有缓存问题。 4.5 更新奖品状态 如果你的奖品设置了领取状态（抽奖领奖动作分离 / 注册前抽奖 / 微信卡包领取状态 / 优惠券领取状态） ，那么还需要一个更新奖品状态的接口，用来修改奖品的领取状态。 举个例子，如果你用了微信卡包的 API 去实现发券功能，那么用户会进入微信实现的卡券领取界面，在这个界面用户也可以选择不领取，当然你也可以就此视为用户放弃。 但如果你希望再给用户开放领取入口，比如在类似 “我的奖品” 这样的页面再次领取的话，就需要判断用户是否领过此卡券。 而当用户终于点击了领取，把卡券放到自己的微信卡包之后，微信会执行一个回调函数，在这里，你可以去更新用户的奖品状态并关闭领取入口了。 4.6 关联用户 这个接口只在一种情况下使用，即 “未注册” 之前允许抽奖，“注册” 之后领奖的情况。注意这里的 “未注册” 和 “注册” 都加了双引号，是因为这两个词对于不同的平台不同的业务意义也不同，需要您自己去界定，什么是注册，什么是未注册。 关联用户有一定的风险，尤其是对于价值比较高的奖品。因为你只能根据某个特定的条件来判定注册前后两个账户是否真的是同一个人。比如通过 openid 判定注册前后用了同一个微信号；再比如用特定算法生成的机器码判定注册前后是同一台设备等。 以 openid 为例，如果每个用户进来，我们都使用微信授权接口去微信那里授权，势必会有严重的性能瓶颈，因为微信的接口对于我们来说是外部接口。更严重的情况，还有可能达到微信 API 的每日调用上限，导致全部 API 无法使用。 因此，我们最初的简易版方案并没有每次都去授权获取 openid，而是缓存了第一次授权的 openid，且没有其他辅助的 ukey 来综合校验，导致用户在抽奖的时候，我们实际上并不能确认这是个真实的用户，甚至不能确认这是个真实存在的微信号的 openid，只能说明这段字符串符合 openid 的长度。 这个漏洞的可乘之机是要刷微信红包，如果不是真实的 openid，是无法收到微信红包的。所以，羊毛党来刷红包的时候，一定用的是真实的 openid，因此这个 bug 不能造成太大的伤害。不过我们还是及时加入了 ukey 验证。 并且，对于抽中后再来实名关联的用户，也会再次验证其微信账户是否有疑似作弊行为，这就是为什么所有活动都要加上 “最终解释权归 xx 所有” 的缘故，因为总有羊毛党来捣乱。 注意，羊毛党一般都是有大量真实微信号在手里的，这种大量真实微信号的操作，是无法通过简单手段识别出来的。 4.7 运营文案接口 该接口是否需要以及其复杂的程度，取决于您的业务需要，即抽奖活动在线时有多少需要实时运营的内容。比如用户欢迎语、抽奖成功 / 失败后的引导语等等，重点是如何能与自身的运营系统结合，方便运营同学使用。 4.8 清除缓存 抽奖活动往往有类似排行榜，参与人数等信息的展示。对于访问量较大的抽奖活动，这种信息一定是有缓存方 |
 |
