14年接口测试工程师解构推送注意力三步分发法

　　去年9月份那会儿，开发组推了个新接口，说是要搞什么"推送注意力三步分发法"。我原以为又是那种PPT上画得漂亮、落地就崩的玩意儿，结果测试的时候发现——嘿，这破玩意儿还真有点意思。那天机房空调坏了，嗡嗡响得跟拖拉机似的，我戴着降噪耳机都能听见运维在隔壁骂娘，监控大屏上的告警短信闪得跟迪厅灯球似的，就这环境里，我盯着接口日志看了俩小时，发现它居然真能按用户活跃度筛推送。

　　这分发法的核心就仨字：优胜劣汰。第一步筛用户，把三天没打开APP的直接踢出池子；第二步筛内容，点赞率低于5%的直接压箱底；第三步筛时机，用户刚刷完十条动态就塞推送？门都没有，得等人家退出应用半小时再发。我原以为这种"机械降神"的算法会漏掉不少边缘用户，结果测试数据甩我脸上——被筛掉的用户里，80%确实三个月内没产生过任何互动。开发小哥叼着冰棍凑过来看日志，说"看吧，机器比人懂人性"，我反手就把他手机里三十个未读推送截图发群里："懂人性？那这堆红点算怎么回事？"他缩脖子跑了，外卖盒还留在工位上，汤洒了一键盘。

　　但要说这分发法真完美？扯淡。上周运维说服务器负载突然飙高，查日志发现是第三步的"延迟推送"机制在作妖——有些用户退出应用后，系统会每隔五分钟查一次在线状态，结果赶上用户频繁切换网络（比如坐地铁），这机制就跟疯狗似的反复唤醒接口。我蹲在机房角落改测试用例，窗外天都黑了，开发组还在群里扯皮："是算法问题还是网络问题？"最后是SEO那哥们儿一锤定音："管他啥问题，先限流，别让老板看见监控大屏上的502。"

　　说到这儿，我想起个更离谱的。有次测试推送频率限制，发现这分发法对"僵尸用户"的判定特别死板——只要用户连续三天没互动，哪怕他第四天突然买了个五千块的课程，系统还是把他当僵尸处理，推送全给截了。开发组说这是"防止过度打扰"，我直接把用户投诉截图甩他们脸上："人家刚花钱，你转头就说不打扰？这他妈叫自杀式运营！"后来改规则加了"高价值用户白名单"，结果白名单里的用户又开始抱怨推送太多——得，又回到原点了。

　　不过话说回来，这分发法最狠的地方，是它把"优胜劣汰"玩到了极致。我测试过同一条推送，分别发给活跃用户和边缘用户，前者打开率是后者的七倍；同样的内容，早上八点发和晚上八点发，点击率能差三倍。开发组后来加了动态权重——比如用户平时爱看科技内容，但最近频繁搜索"育儿"，系统就会临时调高母婴类推送的优先级。我原以为这种"投机取巧"的逻辑会乱套，结果测试两周下来，用户停留时长反而涨了12%。运维小哥盯着监控大屏直嘬牙花子："这数据要是假的，我直播吃键盘。"

　　当然，这分发法也不是没软肋。比如它完全依赖用户行为数据，一旦数据采集出问题（比如用户清空了缓存），整个分发链就崩了。上个月就出过这种事——某安卓机型升级系统后，应用无法正常记录用户停留时长，结果系统把一堆活跃用户当成了僵尸，推送全给截了。等我们发现的时候，用户已经骂了三天娘，客服电话被打爆。开发组连夜修bug，我在旁边补测试用例，桌上的咖啡凉了都忘了喝，最后发现是系统没处理"无停留时长"的异常情况——这他妈也算优胜劣汰？劣到系统都分不清好坏人了！

文章配图，仅供参考

　　最近我在想，这分发法要是能再加点"人性化"的判断，比如用户明确标记过"不喜欢某类内容"，或者设置过"工作时间不接收推送"，那效果会不会更好？开发组说"这得改核心逻辑，风险太大"，我说"风险大也得试，不然等用户全跑光了，你们改不改都没意义"。他们没接话，低头改代码去了。我转头看见运维在擦键盘——就是上次说"数据是假的就吃键盘"那哥们儿，键盘缝里还卡着半片薯片。得，又是个不眠夜。

（编辑：PHP编程网 - 金华站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!