设计 “绑定手机号并发放奖励”功能时，需注意哪些易错点与细节
最近在推进小版本更新，更新的需求中有一个用户绑定手机号、发放奖励的弹窗功能，虽然是一个很小的需求，但是这其中的细节很多记录一下，同时也衍生一些设计细节。
需求目标：实现绑定+发放奖励。定制化针对某一段时间内注册的老用户、过去一年内arppu＞100元，且没有绑定手机的用户，弹出一个福利任务，用户绑定手机后获得巨量的奖励。
类似产品设计方法在其它地方其实是可以找到的，所以这文章里面主要提及一些产品经理设计过程的易错点。在文末谈一谈如何设计出让客户端、服务端、测试都不想怼你的设计。
一、用户异常
这里要讲的，说白了，就是防止被薅羊毛。做不到多好，但至少要做好“底线”。
1. 用户解绑手机号，后再次绑定
领取奖励的关键过程是：绑定手机号→发放奖励，一般来说有绑定就有解绑。要注意用户解绑手机号后重复领取的情况。
2. 条件限定为“手机号已绑定”or“已经领取奖励”？
同上介绍，绑定手机号和奖励领取都是关键流程。
用户领取的条件之一，是“user-id曾经绑定过手机”还是“user-id曾经领取过奖励？”如果是前者，有可能因为我们系统的发放奖励错误，导致用户无法领取到奖励。
更严重的是，user-id有时候是可以无限申请的，也就是可以通过不断的申请user-id然后绑定~解绑~绑定一个手机号，从而无限刷奖。
故，推荐后者。
3. 用户切换账号
一个用户可以有多个账号，且可以在app内随意切换（想像下qq切换账号）考虑：
- 切换账号是否刷新app？也即切换账号后彻底重开app，否则就有很多的上一次缓存和本地记录保留，干扰后续。
- 弹窗是否每次都弹出？用户如果有3个账号，重复弹出3次也会很让人讨厌的。
4. 用户切换设备
当存在用户切换设备的情况时，要区分某些本地数据，或者服务端传递的数据的区别。
比如，钉钉最近的问卷在A手机上填写完毕之后下次填写的时就是自动帮忙写好了，但是切换到B手机上就还需要重复填写，这就是在本地保存数据的情况。
5. 用户不给系统权限
举个例子，有时候我们会限定杭州地区的用户可以参加活动，但是当用户取消了“app获得定位信息”的权限时，这就是一个空数据，要考虑这种情况下的处理方法。
6. 奖励发放失败
要考虑奖励发放失败的情况。没有什么服务器都是百分百发放成功的，就算是失败率能维持在1%左右，用户100万，也是1万的失败数。处理方法：循环补发奖励。
这里推荐一个做法：如果用户绑定手机成功，但是奖励发放失败，也仍然标记该用户“已经领取”奖励。
7. 监控机器人
监控机器人很有必要，且钉钉自带钉钉群自定义机器人，非常好用。
- 监控机器人-发放异常（如短时间奖池下降5%）
- 监控机器人-奖励库存见底。
二、前后端交互
1. 文案设计
首先，我们要确定文案写在客户端还是服务端。这两种区别还是很大的，前者是写死的，后者是服务端传递参数。
其次，文案设计对不同人要有不同的视角。
2. 验证码处理
验证码一般都是要请求服务端接口的，不会写在客户端。
3. 数据的来源
首先，要知道某些数据是从服务端收集的还是写死在客户端。比如充值金额一般会上报到服务端，但是“用户是否为当天第一次登陆”、“用户在该设备累计登陆了多少次”就是后者。
其次，如果使用了其它部门的接口，就要考虑老数据的来源、检查，和新数据的储存地区。
三、通用型设计
1. 弹窗等级设计
比如，对于游戏来说弹窗是很多的（王者荣耀刚进游戏时点不完的弹窗）如果这个绑定手机的形式为弹窗，则一定要考虑到原先的设计中的弹窗等级，合理配置。
2. 点击返回按钮
还是讨论游戏产品，现在的手机游戏一般都屏蔽了游戏中点击返回键、菜单键、主页键的效果。当然我们也可以主动设置点击返回按钮的反馈。如，用户绑定成功后，可以点击返回键退出弹窗。
四、关于充值
这是一个比较偏门的点，工作内容不涉及到这块的读者可以直接略过。
- 用户的充值一般都是满的，比如一次充值10元、100元，所以条件最好是设置为“大于等于”。
- 考虑优惠券因素。如充值了10元，但是在某次活动中使用了优惠券，实际上只花费了9元。
- 取消的订单，是否算进充值金额？
- 公司的产品线如果很多的话，比如A、B产品公用一套账号，这种充值是否互通？
- 如果是不同类的产品呢？比如腾讯有MOBA游戏也有休闲游戏，休闲游戏和moba游戏的货币体系不同。
作者：小宇 Mikasa，产品新人；公众号：枯树梦呓，邮箱：zhouyupm@gmail.com
本文作者 @小宇 Mikasa 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
