小产品上线以后，访问量在涨，后台 PV 和 UV 看起来不错。但这回答不了最关键的问题：来的人到底用起来了没有。如果一批人注册完就再也没回来，我改价格页、改文案，可能都改错了地方。
PV 和 UV 告诉我「来了多少人」，回答不了「他们卡在哪一步」。我需要的是把访问到付费之间的每一步串起来，让流失的位置露出来。PostHog 做的正是这件事：把用户从落地页到付费的每一步记下来，连成一条漏斗，哪一段掉人一眼就能看到。
下面用一个假设的 PDF 转换工具举例。只埋四个事件，先把漏斗搭起来，再谈优化。
先定四个事件，尤其是「首次用成」
| 我想知道什么 | 什么时候记一次 |
|---|---|
| 有没有人来 | 打开产品落地页 |
| 有没有注册 | 服务端确认账号创建成功 |
| 有没有用成 | 第一次转换成功，结果可下载 |
| 有没有付费 | 服务端确认支付成功 |
四个事件里，「首次用成」最需要想清楚。「上传了文件」不算，用户可能传完就报错；「打开了结账页」也不算付费，他可能看了看就关掉。转换结果可下载才算一次成功，支付完成的服务端回调才算一次付费。这个定义定错了，后面的漏斗数字再好看也是虚的。
埋点前，先拿一个测试账号走完整条路
这一步最容易被跳过，但它决定漏斗可不可信。
用测试账号从未登录的浏览器打开落地页，注册、转换，再走一笔测试支付。然后回到事件列表核对两件事：
- 匿名访问和登录后的事件，能不能归到同一个人。PostHog 靠
distinct_id关联用户：前端匿名时生成一个 ID，登录后要调用identify把它换成你的用户 ID。少了这一步，注册前后的行为就会裂成两个「人」。 - 刷新结果页、重放一次支付通知，会不会重复计数。支付回调尤其容易被记两次，需要靠幂等键去重。
这两处没对，漏斗画得再漂亮，也解释不了用户到底走到了哪一步。
从掉人的那一步查起
先定一个观察窗口，比如访问后七天内依序完成四步。下面这组数字只是演示，不是真实业务数据：100 人访问、20 人注册、5 人转换成功、1 人付费。先看「注册到转换成功」这一步，因为这里掉得最多。
漏斗告诉我掉得多的一段，但不告诉我为什么。下一步是去找原因。
回放加错误记录，定位「为什么」
PostHog 能把漏斗和会话回放、错误记录连起来。有人在转换页反复上传，可能是格式限制没写清楚，也可能是接口报错。先对照失败日志：报错就修接口，没报错就更可能改提示文案。
会话回放适合看单个人卡住的操作，但开之前要先把敏感输入遮蔽掉，并确认用户告知和数据流向。PostHog 默认遮蔽输入框这类敏感内容，数据在浏览器端处理后才会发出。小流量阶段，只对卡在转换这一步的会话开回放就够了。
改法不确定，再用开关和实验
如果怀疑是上传引导的问题，想比较两个版本，可以用功能开关控制谁看到新版，再让实验比较结果。流量还小的时候，先修明显的报错，别急着上 A/B 实验——样本太少，结论也靠不住。
免费额度够起步，采集先做减法
按 PostHog 定价页，免费方案每月提供产品分析 100 万事件、会话回放 5000 次录制、功能开关 100 万次请求，错误追踪还有 10 万次异常。额度每月重置，达到上限就停，加卡才会继续。
所以我会先只采这四个关键事件，有排查需求再开回放。埋点只需要知道转换成功还是失败，不用把文件内容发给分析工具。
海外服务在国内的可访问性和延迟，需要从目标用户的网络环境确认，这一步我还没实测。