电商转化率低？90%用户行为数据被API埋没了

　　线上出问题的那一刻，我正盯着构建日志里那个卡在 87% 的进度条——编译器又在假装自己还活着。后端老张发了句“接口没动”，我就信了，信得比信我妈说“这菜不咸”还快。结果凌晨三点灰度切流，埋点平台炸出三千多条「空 referer + 空 utm + click 事件无 payload」，转化漏斗从首页到下单页直接塌成一条直线。不是崩，是被抽走了脊椎。

　　三个月前。那会儿产品推了个新购物流程，说要“提升决策效率”，设计交稿那天，UI组件库刚升了版，记不清哪个版，反正按钮点击区域缩了八像素。我扫了一眼埋点文档——“全量上报 user_action，字段含 page_type、element_id、duration_ms”。写的时候手没抖，但没写进 header 里的 x-ua-trace-id；后端那边说“API 层只透传，不加中间件钩子”，我也点了头。现在想，点得跟点头同意加班一样敷衍。

　　谁在群里发了张表情包？一只猫举着“这锅我不背”的纸条。我截了图发给设计，她回：“按钮尺寸合规啊，你拿的 Figma 版本是不是旧的？” 我说“不是尺寸的问题”，她回了个省略号。我没回。窗外在下雨，雨刮器节奏错乱，啪嗒…停顿…啪嗒啪嗒…像我们上周上线的订单状态轮询。

　　电商转化率低？90% 用户行为数据被 API 埋没了。这话站得住，靠的不是埋点覆盖率报表，是优胜劣汰——活下来的埋点，全是能被后端 parse 掉、能进 kafka 分区、能在离线 pipeline 里过掉 null check 的那批。那些卡在 fetch 中间态、卡在 abort() 后的 one rror、卡在跨域 preflight 失败后连 console 都不报的点击……根本没资格进数仓，连当残次品的编号都没有。它们不是丢了，是压根没出生。

　　我原以为只要 event.preventDefault() 捕获住，再 Promise.resolve().then(() => { track('click') }) 就万事大吉。结果发现某个 H5 页面用了 window.location.assign 跳转，而埋点上报用的是 navigator.sendBeacon —— 浏览器根本不等 beacon 发完就卸载了页面。查 MDN 查了四十分钟，查到一半外卖到了，袋子上印着“准时达”，可我连 beacon 的 timeout 都没设过。我删了那段代码，换成同步 fetch + .catch(() => {})，心里发虚：这哪是上报，这是祈祷。

　　旁边工位的风扇声嗡嗡嗡，调了三次档位还是一个调。后端说“你们前端埋点逻辑太重，建议把关键行为提到网关层做”——好啊，我立马答应。结果下个评审会上，网关组说他们日志打点只收 status_code 和 duration，加字段得走变更流程，排期“视 SLO 冲突情况而定”。我笑了一下，笑得自己都瘆得慌。后来我偷偷翻了他们去年的变更记录，加个 trace_id 字段，改了三版配置模板，熬到凌晨四点才合进主干。

　　前天招人，面试一个校招生，问他“怎么确认一个 click 埋点真的发出去了”。他说“看 Network 面板”。我说“要是页面跳转太快呢”。他愣住。我说“那就用 PerformanceObserver 监听 navigationStart，再往前塞一个 Performance.mark，mark 名字带时间戳和 action_id，之后所有埋点带上这个 mark 名——至少能知道它理论上该不该发出。” 他眼睛亮了。我立刻后悔了，怕他真去 implementation，然后某天因为 Performance.mark 的 key 太长，被安卓 WebView 里的 JS 引擎 silently ignore 掉……这事我吃过亏，但忘了写进 Wiki。

文章配图，仅供参考

　　其实最讽刺的是，上个月我们拆分了订单服务，把 address-select、coupon-apply、payment-gateway 全改成独立 API 域名。表面是解耦，实际是把原来能塞进一个 request.body 的行为链，硬生生掰成五六个异步请求。每个请求都带自己的鉴权头、自己的超时设置、自己的错误兜底——但没人管它们之间的行为时序怎么还原。产品经理想要“用户放弃优惠券的精确时机”，我们只能从 client_timestamp 猜，从 retry 次数反推，从 loading state 切换间隙里抠。这不是数据分析，是考古。

　　今天上午例会，产品又提了个需求：“希望看到用户在地址页停留超过15秒却没点击‘下一步’的原因”。我脱口而出“加个 idle 回调 + visibilitychange 监听呗”，话没说完就听见自己脑子啪一声——这玩意在 iOS Safari 上会被静默丢弃，在安卓低端机上会因为内存回收直接断掉计时器。我顿了两秒，说：“……我们先抓一周 raw log 看看真实分布？” 产品点头，没追问“怎么抓”，可能早就不信了。也是，连我们自己都开始信“数据质量是个玄学”。

　　算了，下午把 fetch 上报全切到 RTCPeerConnection 里试试——不是真建连接，就借它发个 datachannel message，至少生命周期绑定 page visibility。反正 chrome 实现里，datachannel.send() 不会阻塞主线程，也不会被页面卸载打断。我赌它比 sendBeacon 更野，更赖皮。要是不行，下周拉后端吃饭，边吃边聊网关要不要接个 tiny proxy layer，就转个 HTTP header，别的啥都不干。至于 design，让她把按钮再放大两像素。就这么办。

（编辑：我爱资讯网）

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