你的数据仪表盘还在正常刷新，但这可能是幻觉。Event在跑，报表在出，老板在看数——表面一切安好，直到某天系统真的挂了，你才发现团队里没人说得清这些埋点当初是怎么搭的。

这不是假设。Google Analytics 4迁移潮里，大量团队把UA的逻辑直接平移，文档？有的。完整？未必。更常见的是某个关键字段的命名规则，只有已经离职的工程师知道。

「如果追踪系统明天消失，你的团队能重建它吗？」一位数据负责人在近期内部分享中抛出这个问题，全场沉默。他带过三家公司，每次接手时都会发现同一类遗产：跑了两年的转化漏斗，注释栏里写着「TODO: 确认这个事件是否还在用」。

埋点系统的脆弱性在于，它活着的时候不需要解释，死了之后没人能解释。不像代码有版本控制，业务逻辑的衰减是隐形的——今天改一个字段，三个月后全团队都忘了为什么改。

有团队尝试过补救：强制要求每个事件配200字说明，三个月后文档库膨胀到没人愿意搜。更务实的做法是把「重建成本」写进季度检查清单，随机抽一个核心事件，让新人试着从头配置一遍。能配出来，知识才算真的传下去了。

那位数据负责人最后补了一句：他见过最健康的系统，是某个实习生误删事件后，两小时就恢复了——不是因为备份做得好，是因为负责人在白板前画过一遍架构，而当时记笔记的实习生，现在成了团队里唯一能讲清楚全链路的人。