埋点面试反问与陷阱题

陷阱 1：你说埋点很重要，那为什么很多团队最后还是一堆脏数据

我一般会说，问题不在“会不会发事件”，而在有没有把事件模型、字段规范和校验机制立住。没有 schema、没有命名约束、没有对账能力，埋点再多也只是噪音。所以我讲埋点时一直会强调，核心不是多埋，而是埋得稳、埋得准、后面还能用。

我不会直接说是。自动埋点的优点是接入快，但它更容易采到大量技术动作，语义不一定稳定。关键业务链路我还是会优先手工埋点或者半自动埋点，保证语义准确；自动埋点更适合做补充，而不是替代一切。

因为按钮点击太脆弱了。今天是按钮，明天可能换成快捷键、浮层或自动触发。如果只围着 UI 事件建模，交互一变，数据语义就散了。领域事件更稳定，后面的分析口径也更容易统一。

我会说底层 transport、上下文、队列这些能力可以复用，但目标完全不一样。监控 SDK 关注的是错误、性能、白屏和系统健康；埋点 SDK 关注的是行为、转化、漏斗和业务分析。底层可以共用，事件模型不能混。

这时候我不会只说“补一版埋点”。我一般会先看影响范围，再决定是修字段、补版本还是兼容迁移。也正因为这类问题代价很高，所以我才会强调开发环境调试、灰度对账和版本管理，尽量把问题挡在上线前。

我不会硬编业务指标。我会讲两层价值：第一层是工程价值，比如规范统一、接入成本下降、脏数据减少；第二层是业务价值，比如分析平台、转化分析、实验平台后面终于有一套稳定语义可依赖。对平台型项目来说，这种价值本身就成立。

埋点面试最容易踩的坑，是把它讲成“上报几个事件”的脚本题。我的思路一直是把它讲成“事件模型 + 数据质量 + 分析可用性”的平台题。