站长亲测：移动端埋点失效的3大隐形陷阱

　　去年10月，凌晨两点十七分，我蹲在IDC机柜前拿手机扫二维码——不是测跳转，是看埋点上报有没有打到Kafka Topic里。风扇啸叫，像一台老式复印机卡了纸，但比那更钝，更缠人。监控大屏右下角弹出第十七条「/track/collect 502」，我没点开。工位上还压着昨天没拆的酸辣粉外卖盒，汤渍渗进键盘缝里，黏手。

　　第一个坑：WebView内核升级后document.hidden判断失灵。不是不触发，是触发时机错位十八秒——从页面onShow到首屏渲染完成，埋点早发出去了，但用户根本还没“看到”。我原以为是上报链路延迟，结果抓包发现，上报请求发得比Vue mounted还早。王磊在群里@我：“你们H5是不是把track()塞进beforeCreate了？”我回了个[捂脸]，其实不是。是uni-app那个patch过的webview，把visibilitychange事件压到了渲染队列末尾，而我们的埋点脚本绑的是addEventListener('visibilitychange')。这个我敢打包票——我把同一段代码扔进Chrome DevTools Console手动执行，它就正常；塞进APP壳里，就飘。你说巧不巧？

　　第二个坑：CDN缓存HTML模板时，把data-track-id这种静态属性当常量缓了。上周五备案刚过，运维切了新CDN节点，首页JS没动，但HTML多缓了三百七十二秒——结果所有按钮上的data-track-id还是三个月前A/B测试用的老值。张薇半夜发来截图，上面写着“点击【立即开通】→ 触发事件：btn_subscribe_v1”，可我们上个月就灰度v3了。她附了个龇牙笑表情包。我没回。翻了下CDN配置，cache-control里max-age写的是86400，但ETag居然是按文件哈希算的，HTML里那段script标签没变，整个页面就认定没更新。这事我说不准，因为缓存策略是外包团队配的，他们说“和上次一样”，我就信了。现在想想，可能他们连nginx.conf都没自己改过。

　　第三个坑最荒诞：iOS 17.4之后，SFSafariViewController里navigator.sendBeacon()直接静默失败，不报错、不reject、不进catch，就像被吸进黑洞。我们埋点SDK用的就是sendBeacon，为了保活。结果呢？用户点完按钮，页面一跳，数据全断。查日志全空。我让实习生拿三台真机跑：iPhone 13（17.3.1）、14（17.4.1）、15（17.5），只有中间那台漏数据。他录屏发我，手指点下去那一刻，network面板里根本没出现/beacon这条请求。我原以为是权限问题，查了半天SFSafariViewController的allowJavaScript，结果人家根本没禁。后来翻WebKit bug tracker，有人贴了个commit hash，说“fixed beacon in non-main frames”，但release note里只字不提。这哪是bug？这是藏在补丁里的彩蛋。

　　对了，昨天阿里云WAF又抽风，把我一个测试域名的Bot流量标记成CC攻击，封了两小时。不是重点，但监控又跳了一条报警，我顺手点开了。工位隔壁小陈在重装Mac系统，硬盘分区界面卡住，一直在敲command+R，键盘声咔咔的，比机房风扇还烦。

文章配图，仅供参考

　　李工刚在群甩了张图，是我们去年Q2的埋点覆盖率报表，标题栏写着“已100%覆盖核心路径”，Excel单元格边框线都加粗了。我截了屏，反色处理后发回去，底下加了行小字：“阴影区即未上报区域”。他没回。可能正盯着CDN缓存刷新进度条发呆。

　　现在我改了规则：所有移动端埋点，上线前必须过三关——真机冷启测、WebView内嵌测、iOS 17.4+ SFSafariViewController单测。不走CI，不走MR，我自己拿旧iPhone SE蹲厕所测。别的不敢说，至少能保证：当用户手指抬起来那一刻，数据已经飞出去了。至于飞到哪儿……呵，那是数仓的事。

　　今天下午三点，我约了CDN厂商来现场调配置。顺便让他们把机房那台嗡嗡响的空调修一下。不是为散热——是为让我能听见自己键盘敲空格的声音。

（编辑：站长网）

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