本文记录了我在设计一个用于峰会颁奖盛典的投票方案时的思考，主要内容为，在宽松投票政策的场景下的产品和运营设计，如何在尽可能不伤害多数用户体验的条件下，让产品目标最大化。我的运营技能还不成体系，望多指正。
1.我们和用户的目标
首先，我们做活动的目标，一是流量上的大幅提升，二是通过沉淀流量来扩张用户规模，三可能会有一定的品牌和影响力的收获。活动的主题，一定是与产品目标人群以及他们的朋友圈息息相关，才能在产品目标人群中进行了大规模的传播。
而对于颁奖投票产品，细分用户的目标大致如下。
2.产品设计上几个关键点
2.1 分享流程要围绕微信拉票场景来设计
对于投票来说，分享的目标必然是以拉票为主。我们的目标用户群，拉票这个场景大部分会在微信中进行，无外乎转发到个人、群组、朋友圈三个地方，所以最早是完全围绕微信中的webview来设计页面流程的。而从pc-web端进入的用户，分享按钮会引导用户用微信扫码打开该提名人的投票主页。用户扫码后从pc迁移到手机，只需要一次点击操作即可完成投票。考虑二次拉票的需求，完成投票后也做了分享引导（使用微信自带分享页面功能，微信本身没有js能调用的分享接口）。但要记得，我们分享出去的一定是该提名人的投票主页，如果投票成功后的分享引导是用独立页面完成的，需要跳转回去。当然，分享引导也可以直接用modal或者toast来做，这样就可以直接分享当前页面。建议使用modal，对用户的引导更强一点。投票和拉票的主要页面流程如下图（图中省略了申请参加评选等支线）：
在上线以后，我们收到反馈，有少量用户将pc端投票提名人列表的地址复制到工作群、公司群拉票。由于设计是考虑缩短操作路径，pc端没有个人投票主页，直接在列表中投票，所以该页面被分享地址后，用户还要从海量提名人中找出被邀请投票的人选。
尽管当事用户忽视已经很明显的分享拉票按钮，并把链接直接用PC复制并发到微信群里的这个操作，实际上欠妥。但这是个典型的大用户量让小概率事件高频发生的例子，你没法教所有用户按照最佳流程来，总有人会按照自己的习惯来操作。
所以我们针对这个情况，马上把跨奖项的搜索提名人这个功能上线了。这个功能允许用户输入关键词查出所有符合条件的参选人，同时支持一人参与多奖项评选的情况，让投票人为某一提名参选人所参加的所有奖项投票。
最重要的，既然是微信分享场景，那一定要起一个亮眼的页面title，转发出去会被观众直接看到，一要能说明是个什么事，二要能与观众产生关系使之点进来投票，三可以有一定的悬念或者竞争意味（数字），从个体拉票上升到用整个活动的结果来吸引观众。并且要短，否则会被省略，粗略测试，23个字以内可以看到，最好18字以内。
2.2 应对“微信诱导分享”问题
我们在微信端的分享流程上设计的足够短，所以页面上一定会有可以分享该页拉票的提示，所以不得不提前考虑，微信“诱导分享”的规则。第一当然很简单，我们一定要上这个提示文本，万一被封禁后撤下来，这时候第一波爆发式的传播应该已经结束，如何拉票的用户习惯已经培养起来，提示文本目的已经达到，扯下来申请微信团队解封即可。第二是，如果有其他意外情况，我们可能需要完整拷贝“提名人主页”到另一个地址，把原来的链接替换了即可。
上线后大概一周不到，果然所有带有提名人id参数的页面（即分享出来的提名人投票主页）被微信封禁，据了解有可能是被举报了。我们采用第一个方案平安度过，后续的用户也没有因为缺少引导，而不知如何快捷拉票。
2.3 尽量减少层级和页面更有助于活动场景的体验
在产品设计时，我们尽可能的采用了一些直观铺陈的方式，来减少页面层级和单页数量。同时也简化了信息架构，投票-拉票场景不必要的东西，比如个人详情信息都尽可能的省去了。其实，像这样的大众投票评奖，大多数观望者也无法基于一些能百度到的信息来做出自以为公允的评选判断，所以来投票的人中，大多数都是有一定利益相关的朋友，或者对这个圈子有一定了解。故而并不会太关心一些太细的信息，只需要提供最基本的信息，就能满足评选比较的需求。
本身活动页面是个长页面，颁奖部分必定是单页，在这个单页上，我们直接用走马灯导航+ajax来满足流畅地在不同奖项的提名人列表间快速切换浏览的需求。但同时，这样做需要在一次加载出所有奖项的首页候选人，对候选人列表中的图片大小处理会有一定要求，否则会极大的影响性能。
2.4 注意产品完整性
投票阶段也可能会有先提名再投票，也有可能可以同时提名和投票。截止投票后，以及结果揭晓的时候，产品的很多按钮、文本、链接、页面反馈都会产生相应的变化，需要提前规划好，定时上线。
3.策略权衡
3.1 如何看待刷票
我认为，刷票分为两种，第一是亲朋好友、同事熟人或者刷票群帮着手工点击，如果规则允许，可能在小范围内多投上几票，可能每天来投一票。朋友刷票是人性使然，只要身份验证得当，这都不算恶意破坏颁奖公平性。并且，通常为避免过度民主所带来的黑天鹅事件，在一个能够自由申请成为提名人的投票系统中，评选规则大多不是单纯依靠票数的多少，还会将最终得分的一定比例，赋予具有公信力的嘉宾，通过加权计算出最终结果。
而第二种，则是使用机器、在淘宝上购买、寻找漏洞大规模的注水刷票，这种方式，用通常的技术手段，只能防君子。但我们是一定要规避和处理的。
活动的目的其实在用户参与和传播上，在这种非严肃投票的场景下，没有必要有严格一人一票的规定，所以我们允许用户每人每天投一票。身份验证上，因为采用较为宽松的制度且没有不记名需求，就没有考虑RSA盲签名以及其他技术手段，直接使用了微信OAuth来认证授权。在这里解释两点：
一是为什么不用自有用户系统登录，是考虑尽可能的减少投票的操作成本，几经权衡，拉票操作的流畅程度，相较于本就不属于产品重度使用者的注册用户更为重要。当然，如果是一个用户重度参与的产品（区别于本文基于的媒体产品），如金融、社交等，是有必要用产品账号来登录的。
二是为什么开发提出用IP地址的方案后来被紧急替换，是因为公司群内拉票场景，同一个办公室的人共用一个IP，导致会有大量用户认为无法投票，并且手机4G，甚至还会遇到一些无法得知原因的错误。而如果要将就这点，将同一IP的每日投票次数提升，反而又使第二类刷票更加猖狂。所以经实践验证，是万万不能采用IP地址判定的。退一万步说，换个IP对于恶性刷票者来说，成本还是低于一个微信账号的。
3.2 如何处理实际发生的刷票
活动页上线后，我们确实收到不少投诉，明确指出某某的票数短时间飙升，经查询日志，确有如此多的微信号，此时需要向各方大力广播，我们将对刷票者进行严肃处理，并且有权威嘉宾最终评定，不会发生黑天鹅事件。
怎么处理票数异常者，是个比较棘手的事情。很多时候，票数异常者坚决不会承认，甚至要求组织方去查证为什么票数异常。而在淘宝上大批量微信号刷票又是我们无法控制的事情。最重要的事，微信刷票者比较专业，以至于很有可能会伪装是第一类刷票。没有一个响亮的办法，那么这就需要运营在不破坏公平感的基础上，酌情处理了。
但是我们仍然发现了一些想利用漏洞刷票甚至无差别投票来捣乱的人，而对于这种纯第二类刷票，直接运用技术手段封禁就好。
3.3 微妙的数据美化
刚上线的时候，要做一定的数据美化，帮助运营减少一点压力，避免在运营跟不上时，转发出去很多0票的尴尬情况。我们的思路是，考虑公平性，所以必然要天下大同，但需要分时段分批次去增加等量的票数，才有隐蔽性。比如可以利用提名人在系统中的id尾数，分为5个批次，每个时段轮流针对某个批次增加一定票数或随机范围票数（方差尽可能的小，如6-8票）。时段要尽量短一些，这样可以将每次增加票数压缩到小数字，更加隐蔽。这样就可以温和的将所有人的票数提升大致相同的数量，而又尽可能不破坏公平性。
为什么想要增大随机性，其实也是现实场景的要求，因为样本规模较大，那么我们的美化结果就具有足够的统计规律，很容易被看出来。如果要使用随机范围票数，来提升数据美化的隐蔽性，需要考虑获奖人员占整体参奖的比重了，如果竞争非常激烈的投票（如100人中仅3人获奖，其余全部没有），那么就一定不能采用。如果较为宽泛，如从100人中评选10-30位，那么就可以有一定的随机性。
4.运营思路
基于颁奖类投票活动来讲，可以有以下手段来炒热活动。
- 掌控节奏：通过对时程一张一弛的收放，循序翻炒社交平台的活动氛围。
- 传播渗透：制造自发传播动机，联系或触动非活跃用户和新用户。
- 刺激内容生产：对于核心用户，需有更多的参与和互动。
这里主要谈谈如何掌控节奏。颁奖投票，大家很明确有一个好东西在最后等着，本身也充满竞争意味，但一般时程较长，如果不温不热，是很难在目标用户群的社交平台获得跟风转发的。所谓节奏，就是为活动分阶段，每个阶段都需要有一个特定的目标/事件，用户需要在这个阶段做特定的事情，并等待下个阶段到来（留好悬念）。而在每个阶段之间的节点，都是我们集中传播的机会，要么用deadline来制造参与上的紧张感，要么用一些阶段总结数据的呈现来诱导分享，而这个数据最好也是能制造紧张感的，比如有竞争意味的排名。这样我们一个活动，可以有多个有料的爆发传播点，并且一张一弛，制造“观望-竞争-期待悬念-揭晓悬念-下一轮观望”的体验路线。
在具体操作上，一定要注意的是，这样的翻炒要明察参与者的心理。这是一个很微妙的活，比如说参与者会关注两类群体，一类是排名顶端，第二类是与自己相近相匹配的，那么我们做内容的时候可以营造一定的对抗场景。
