前段时间，突遇滑铁卢的砍价活动可让我头发秃了一大把。
砍价活动的业务线很简单，APP或小程序参与然后直接邀请微信好友助力，被助力成功后就可以领取限量奖品，先到先得，而账号是跟手机号绑定的。
总体看来功能也不算复杂，再到上线后的跟踪，前几期活动都没啥大问题。
但我总觉得有点太顺利了。。。
终于在开始第四期的活动时，发现一些数据很可疑。
1，线上监控日志发现很多异常调用接口的请求
2，存在部分新注册的用户头像一样，虽然手机号不一样
3，砍价过程中奖品库存数量减少得很快，一个奖品最快2-3分钟就砍完了（砍价主要是邀请新用户）。
4，活动接入的第三方风控没有预警
4，发现邀请的新用户助力时间分布间隔非常近
因为项目开发时就已经考虑了第三方风控，所以首先查看第三方风控的日志记录，发现风控后台的账号（手机号）检测正常，这就有点矛盾了。。。
第一期数据采集分析
因为正常流程是在小程序发起的，而且新用户助力需要在小程序登录，所以可以记录到用户的unionId，结合线上被刷接口的日志。
分析后做了以下优化：
- 助力请求包含用户的unionId，后端保存该unionId
- 前端增加第三方的数据埋点
接着是测试后第五期活动上线，并实时跟踪线上活动效果，发现原本能持续3天活动奖品，当天就被抢完了，这库存减少速度明显着异常，看来是遇到羊毛党了。
好了，第五期活动一结束就拉着相关人员开会，也算是风控的真正开始。
第二期风控优化
通过会议讨论，初步发现：
1，数据库中约80%的助力记录中没有unionId，小程序最新版本正常助力会传unionId
2，由于微信小程序更新存在延迟，线上存在部分老版本，故无法回传unionId
3，部分运营反馈的风险用户，其中部分助力数据显示正常（没有重复的unionid、手机号、ip等）
4，其中第三方埋点统计的按钮点击次数也与总助力次数相差极大（考虑到用户可能多次点击，正常情况下同一次砍价流程，埋点数>=助力次数）
5，第三方风控本次活动检测数为上期活动检测数的1/4，即大部分助力绕过了风控平台
6，由于活动助力仅能在小程序发起，即必定会绑定小程序，而unionId是用户绑定小程序的唯一凭证，所以unionId可以作为助力必传字段
由于第三方风控可是付费了的！先从这边入手。
发现当时为了提高性能，后端设计时，仅是在助力页面加载时做了风控效验，助力接口上没有效验。那么羊毛党获取到相关参数后，通过助力接口就可以绕过检测。
那么是否把风控效验放到助力接口上？
接着顺便找了几个账号对风控做了准确性测试，发现羊毛党账号中的全部助力用户仅能识别50%的用户为可信用度低，其他均为白名单用户，即返回数据存在误杀。
如果风控效验放到助力接口上，又不想误杀，第三方风控人员建议我们接入滑块效验，由于接入滑块可能需要更改业务流程，影响性能的同时改动周期比较长（涉及购买合同等等），暂时不考虑。
分析后做了以下优化：
- 前端助力接口必传unionId参数，且后端验证unionId是否已存在，不存在则判断用户助力失效，重复unionId用户的助力机会取活动的助力次数上限。
- 助力用户的IP地址的风控限制，由于切实存在IP地址相同的场景，该值上限可做配置化。
- 前端优化助力操作的第三方埋点事件（助力成功后才会统计），包括小程序的版本号。
- 由于效果一般，先去掉第三方风控。
异常订单处理，后置风控！
对照第三方埋点数据，通知运营对异常订单不发货，进一步避免损失吧！
我的头发开始掉了。。。
接着是测试后第六期活动上线（奖品数量较少），并实时跟踪线上活动效果，发现初期活动奖品的库存减少速度正常，后期库存减少速度异常，半天后活动全部奖品砍完。
可以看出：初期由于风控使羊毛党用户无法正常砍价，而后期怀疑羊毛党伪造脚本升级导致异常，即上期风控存在效果但还需要持续优化！
第三期风控优化
通过会议讨论，初步发现：
- 第一步是授权，其中授权后服务端就会保存该用户的unionId，只是此时不生成用户ID。
- 第二步是登录，老用户授权后自动为登录状态，如果是新用户登录，之前授权的unionId就会与用户ID生成绑定关系。
所以非法调用APP登录以获取到有效token，就能绕过小程序登录，也能正常助力，但该情况不会生成绑定关系。
于是助力人的unionId与该用户ID存在绑定关系才能助力成功！
此外还准备了两个杀手锏，一是页面接口加入身份校验参数A，助力时入参需要把参数A带上；二是助力接口入参PB化（Protobuff），门槛瞬间提高几丈。
- 针对助力接口，后端需要验证该unionId是否与助力的用户ID是否匹配，匹配正常才能助力。
- 登录接口与线上活动接口开启验签功能。
- 助力接口增加身份校验参数，并对接口入参进行PB化。
- 第三方埋点数据分析，用户砍价存在助力的埋点记录即为正常助力。
-
异常用户加入砍价黑名单，需要提供往期黑名单用户
继续异常订单处理！
和上次一样同步异常订单给运营，运营已经面露难色！
我的头发掉得更厉害了。。。
接着是测试后第七期活动上线（奖品数量多，但部分质量较低），并实时跟踪线上活动效果，发现活动共持续了3天，奖品的库存减少速度正常，到活动结束时仍然存在剩余奖品。
由于第三方数据平台会记录小程序端助力的埋点数据，补充分析如下：
1，活动完成后，统计第三方埋点数据与总的助力次数，发现99.4%的数据是正常的（埋点统计可能存在误差）——证明风控有较好效果
2，统计砍价成功的助力数据，如果助力次数<埋点次数，则用户存在砍价异常（埋点统计可能存在误差，5个以内可以接受）。
注：仅发现一个用户偏差较大（占0.2%），已同步给运营，综合分析后发现该用户的各种砍价行为正常，可能需要再次观察 ——证明风控存在较小风险
可以看出：活动期间库存减少速度正常，短期内使羊毛党用户无法正常砍价，总体来看这次风控是有效的（部分奖品价值较低，不排除羊毛党没参与本次砍价），所以下期活动可以放开点。
两天后第八期活动上线！
本期奖品数量多，但部分质量较低，原计划持续2天的活动仅持续了1天多点，结合反馈，第一天的凌晨后库存减少速度开始异常，用户助力时间分布间隔非常近。
。。。。。。so风控还需要再次优化！
第四期风控优化
通过会议讨论，初步发现：
1，本期活动所有助力成功用户记录有8万多条。
2，本期活动所有助力成功记录埋点有7万多条。
3，本期砍价成功的助力记录为7万多条，与神策次数对比，经过运营统计异常订单占33%。
4，存在非法用户购买了砍价工具，并发布了帮砍广告。
通过后台日志分析，发现小程序登录接口调用正常？
上图为官方说明，我们在前端授权后，服务端会把正确的sessionKey返回给前端（官方提示不能传），如果羊毛党知道正确的OpenId、UnionID及对应的sessionKey，是不是就能反向破解sessionKey了。。。
能不能破解已经不敢想了，必须马上隐藏sessionKey！！！
为了兼容老版本，sessionKey做了映射，相当于返回一个假的sessionKey并且每次使用后就会删除映射关系。
又是异常订单处理！
和上次一样不太一样的是，运营开始主动索要异常订单了！
已经来不及关注头发了。。。
第五期风控优化
先处理异常订单吧！
有人投诉我们了，运营说，能不能风控前置，避免异常订单！
头发一抓一大把。。。
要不考虑下跟第三方埋点平台打通？一条埋点数据对应一次成功助力！
- 需要第三方提供数据查询或支持数据回传的功能，第三方说都可以的，只不过要加钱。。。
- 埋点数据会有延迟，实时性不高，意味着可能会花费很长时间去判断一次助力是否正常！
- 埋点数据会有误差，可能客户端产生4次事件，而第三方收集的数据可能只有3条，2条。
- 打通第三方平台可能需要产品程度上重新设计。。。