先埋点后上线
没埋点的功能，上线等于没上。你不知道有多少人看到、多少人用了、多少人卡在哪一步，只能凭感觉说「反正上了」。
你会遇到的现象
- 上线两周后老板问效果，你翻了半天只能说「用的人好像挺多」
- 想看新功能的转化，发现只埋了一个点击，中间几步全是空的
- 补完埋点又要排一个版本，等数据攒够已经是一个月后，那时功能都快下线了
- 数据有了，但是失败的人有多少、为什么失败，仍然不知道
什么时候定埋点
答案是写规格的时候，和验收标准写在同一页。不是开发完，更不是上线后。
判断标准很简单：如果这个功能的规格里没有回答「上线后我看哪几个数字来判断它成不成」，那这份规格就没写完。这跟需求定义的三段是一回事，验收标准里本来就该有可度量的那部分。
| 阶段 | 这一步要产出 | 没做的代价 |
|---|---|---|
| 写规格 | 列出这个功能要回答的 2~3 个问题，以及对应的事件 | 后面全部要返工 |
| 开发 | 事件和功能写在同一个改动里，一起提测 | 另开一个版本，多等两周 |
| 提测 | 用调试面板逐条看事件有没有上报、属性对不对 | 上线了才发现事件名写错，数据白收 |
| 上线后第 1 天 | 先确认数据量级正常，再看结论 | 拿着漏报一半的数据下判断 |
最小埋点集
不用一上来就埋几十个点。一个功能埋五个，就能回答绝大部分问题：
- 曝光。有多少人看到了这个入口。分母是它，没有它后面所有的转化率都算不出来。
- 开始。有多少人点进来、开始操作。曝光到开始这一段掉得多，问题在入口本身：没看懂、不敢点、位置不对。
- 成功。有多少人走完了。这是你真正想要的那个数。
- 失败（带原因）。失败必须带上原因属性：校验没过、接口报错、余额不足。只埋成功不埋失败，等于只看好消息。
- 放弃。中途退出的人停在哪一步。这一条能直接告诉你去改哪个页面。
这五个点连起来就是一条漏斗。哪一段掉得最狠，下一步就改哪里，不用再猜。
一个事件要写清什么
| 事件名 | 什么时候报 | 带哪些属性 | 用来回答 |
|---|---|---|---|
| order_batch_entry_view | 批量审批入口出现在视口里 | 页面、角色 | 多少人看到 |
| order_batch_start | 点开批量审批面板 | 角色、待审数量 | 入口有没有吸引力 |
| order_batch_submit | 点提交那一下 | 选中条数 | 一次批多少 |
| order_batch_success | 后端返回成功 | 条数、耗时 | 省了多少时间 |
| order_batch_fail | 后端返回失败 | 失败原因、条数 | 为什么没成 |
click_btn_2 是什么。每个事件还要写清两件容易漏的事：谁来上报（前端还是后端），以及谁会看它。跟钱、跟权限有关的关键结果一律后端上报，前端可能被拦截、被关掉、被刷；没人会看的事件就别埋，埋了也是负担。
常见的坑
- 只埋成功。最常见的一种。上线后一片祥和，因为失败的人根本没被记下来。
- 没有关联 id。事件里不带用户标识和会话标识，就只能看总量，没法看「同一个人有没有走完」，漏斗也就拼不起来。
- 埋了不看。埋点越堆越多，看板一个没建。定事件的时候就写清它回答什么问题，回答不上来的直接砍掉。
- 拿前端事件当账。前端的成功事件只代表「界面显示成功了」。真实成交、真实扣款，必须以后端记录为准。
- 改名不改文档。事件字典要跟着改。字典和代码对不上的那天，谁也不敢再用这份数据。
如果你在用 AI 写代码，把埋点直接写进同一份规格，让它和功能一起产出。这类每次都要重申的规矩，适合沉淀进项目约束文件（见约束沉淀），不用每次都提醒一遍。