电商风控新盲区：行为分析断层致92%转化流失

　　2025年2月14号凌晨三点十七分，我还在盯着控制台里那行Failed to fetch: /api/risk/decision?trace_id=xxx——不是报错，是没响应，timeout 都没抛，就卡在 pending 里，像被谁掐住了脖子。后台系统，纯 internal 管控页，没对外流量，就十来个风控运营轮班盯屏用。可那天凌晨，三个运营同时反馈“点了提交没反应”，我切过去看，首屏转圈、按钮点了没反应、控制台一片红——不是 JS error，是 network 面板里几十个 pending 的 risk 接口，在 performance 面板里卡在「Waiting (TTFB)」那一栏，稳得跟焊死了一样。

　　复盘？别提了。上午九点会议室，白板上还残留着上周画的埋点链路图，右下角用蓝笔写着「全量透传行为 ID」，墨迹都干了，但没擦。产品经理坐在那儿，左手捏着咖啡杯沿，右手在手机上回消息，头都没抬：“我们确认过，所有用户操作都上报了。”我指着屏幕里那段重复调用三次的track('click', { page: 'rule_edit', btn: 'save' })说：“上报是上报了，可风控决策层根本收不到页面停留时长、tab 切换频次、甚至鼠标悬停轨迹——你们发的 event 没带 context，risk-service 一收到，直接当裸 click 处理，连是否真点了‘确定’还是划过去了都分不清。”他终于抬头：“那加个字段？”我说：“加了也没用。你们昨天下午四点十五分改的 schema，把behavior_seq从 array 改成 string，但前端 SDK 没同步更新，现在上报全是 JSON.parse 报错后 fallback 成空对象。”他顿了顿，问：“SDK 版本是多少？”我没答。键盘上 Q 键早就掉了，只剩一个黑窟窿，我拿指甲抠了抠那个坑。

文章配图，仅供参考

　　不是他们不懂，是压根没人在意断层在哪。行为分析断层，不是漏埋几个点，是整段链路里，前半截在浏览器跑，后半截在风控中台算，中间那条缝，连 buffer 都没留。我们页面里每个输入框 blur 后自动 trigger 的validateRiskStep()，会攒一批事件发出去；可风控侧接的是另一个团队写的网关，硬生生把这批事件拆开、打乱、按自己的节奏 re-batch，最后喂给模型时，时间戳全漂移了——鼠标在「优惠券」区域悬停 3.2 秒，上报 timestamp 是 10:23:44.117，风控入库变成 10:23:45.893，而 model 跑 batch 是每分钟整点触发一次，等它看到这个行为，用户早关 Tab 了。转化流失？哪是什么流失，是决策根本没赶上人还在页面上。

　　背后椅子突然被人撞了一下，差点歪倒。回头看见是测试组小陈，端着保温杯站了快五分钟，水汽在镜片上糊了一层，他一直没说话，只把杯子放在我显示器竖屏支架底座上——那支架是去年双十二前抢修时焊的，歪了七度，现在整个屏斜向左下方。他说：“我昨儿拿三台测试机试，iOS Safari 17.4、安卓 Chrome 121、还有那台红米 Note12，behavior_seq 解析全挂。不是格式问题，是 SDK 里用了 Array.from(new Set(...)) 做去重，Set 对 Symbol 键处理不一致，iOS 上塞进去的 mousemove 序列，到安卓上就变空。”我没接话。外卖袋挂在工位隔板上晃了半小时，没人去拿，塑料绳勒进隔板缝隙里，发出吱呀声。

　　有人问：那你们加个实时 channel 不就完了？加啊。去年十月上线 WebSocket fallback 逻辑，结果风控网关开着 TLS 1.2 强制校验，我们 ws 握手直接被 nginx 502；后来切 SSE，又撞上公司 CDN 对 text/event-stream 缓存策略没关，event 流被缓存了 20 秒；再后来改用短轮询，QPS 一上来，API 网关限流熔断，返回 429——但错误码统一映射成 500，前端 catch 住，toast 弹一句“网络异常，请重试”，没人知道这“异常”其实是风控判定你“操作过于规律”，给你静默打标了。92%？我没记清具体数字，大概几秒前刚在日志里扫过一眼，某个时段下单失败率陡增，其中 87% 请求的风控返回里，reason: "behavior_inconsistent"，但对应前端行为日志全被 GC 回收了——因为 SDK 默认只存最近 200 条，而风控请求间隔比用户操作还慢。

　　我接下来打算干两件事：第一，把本地 dev-server 里那个 mock-risk-service 的 response 时间，从 200ms 硬拖到 3.2s（就是用户鼠标悬停那个数），看看页面是不是真会在这时候跳转或报错；第二，翻出二月份 Git 记录，找出 2月7号那次提交：feat(risk): add retry on 429，commit hash 是 7a9b1e8，看它到底 retry 了几次，retry 间隙有没有 sleep(0) 导致微任务队列炸锅。别的先不管。白板上的蓝字还在，没人擦，我也不擦。

（编辑：站长网）

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