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