Track Before Launch
A feature without tracking might as well not have shipped. You don't know how many saw it, how many used it, how many got stuck at which step—you can only say "it shipped" on a hunch.
- 上线两周后老板问效果，你翻了半天只能说「用的人好像挺多」
- 想看新功能的转化，发现只埋了一个点击，中间几步全是空的
- 补完埋点又要排一个版本，等数据攒够已经是一个月后，那时功能都快下线了
- 数据有了，但是失败的人有多少、为什么失败，仍然不知道
When to define tracking
The answer is while writing the spec, on the same page as the acceptance criteria. Not after development, and definitely not after launch.
The test is simple: if this feature's spec doesn't answer "which numbers will I look at after launch to judge whether it succeeded," the spec isn't finished. This is the same thing as the three parts of defining a need—the acceptance criteria were always supposed to include the measurable part.
| 阶段 | 这一步要产出 | 没做的代价 |
|---|---|---|
| 写规格 | 列出这个功能要回答的 2~3 个问题，以及对应的事件 | 后面全部要返工 |
| 开发 | 事件和功能写在同一个改动里，一起提测 | 另开一个版本，多等两周 |
| 提测 | 用调试面板逐条看事件有没有上报、属性对不对 | 上线了才发现事件名写错，数据白收 |
| 上线后第 1 天 | 先确认数据量级正常，再看结论 | 拿着漏报一半的数据下判断 |
click_btn_2 was.The minimum tracking set
You don't need dozens of events on day one. Five events per feature answer most questions:
- Exposure. How many people saw the entry point. This is the denominator — without it, every conversion rate downstream is uncomputable.
- Start. How many people clicked in and began. A big drop from exposure to start points to the entry itself: unclear, intimidating, or in the wrong place.
- Success. How many people made it to the end. This is the number you actually want.
- Failure (with reason). Failure must carry a reason attribute: validation failed, API errored, balance too low. Tracking success but not failure means only hearing good news.
- Drop-off. Where the people who quit midway stopped. This one tells you directly which page to go fix.
These five events chain into a funnel. Wherever the drop-off is sharpest is where you focus next—no more guessing.
click_btn_2 was.What to specify per event
| 事件名 | 什么时候报 | 带哪些属性 | 用来回答 |
|---|---|---|---|
| order_batch_entry_view | 批量审批入口出现在视口里 | 页面、角色 | 多少人看到 |
| order_batch_start | 点开批量审批面板 | 角色、待审数量 | 入口有没有吸引力 |
| order_batch_submit | 点提交那一下 | 选中条数 | 一次批多少 |
| order_batch_success | 后端返回成功 | 条数、耗时 | 省了多少时间 |
| order_batch_fail | 后端返回失败 | 失败原因、条数 | 为什么没成 |
click_btn_2 was.Each event also needs two easily-missed things: who reports it (frontend or backend) and who will look at it. Anything tied to money or permissions is reported by the backend—the frontend can be intercepted, disabled, or spoofed. Events no one will look at shouldn't be tracked; they're just overhead.
Common pitfalls
- 只埋成功。最常见的一种。上线后一片祥和，因为失败的人根本没被记下来。
- 没有关联 id。事件里不带用户标识和会话标识，就只能看总量，没法看「同一个人有没有走完」，漏斗也就拼不起来。
- 埋了不看。埋点越堆越多，看板一个没建。定事件的时候就写清它回答什么问题，回答不上来的直接砍掉。
- 拿前端事件当账。前端的成功事件只代表「界面显示成功了」。真实成交、真实扣款，必须以后端记录为准。
- 改名不改文档。事件字典要跟着改。字典和代码对不上的那天，谁也不敢再用这份数据。
If you're using AI to write code, put the tracking directly into the same spec so it ships alongside the feature. Rules you have to restate every time are a good fit for the project constraints file (see Distilling Constraints)—no need to remind it each time.