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