产品测量与试验：从一条事件到一个可信的决定

给产品接上分析面板，看到“完成率 100%”，很容易觉得导出流程已经没问题了。可点开记录，里面既有文件真正生成，也有旧版本的按钮点击；同一次请求重发、自己做的测试，也被加了进去。

报表有了数字，你却还不知道用户有没有做完。继续看更多图表不会自动回答这个问题；得先沿着数字往回走，找到它对应的动作、记录和筛选条件。

首次使用区分了做完演示和完成真实任务，持续使用解释了任务机会与未知。这一章接中间缺的一段：怎样把这些判断写成事件约定，验证采集，再把记录整理成可复核的报表。等数字有了来路，我们再决定是否值得做一次 A/B 试验。

下面用独立的 M-01 教学批次：仍是把 CSV 生成客户周报的 Web 工具，文件在浏览器处理，不上传、不接 AI，也没有云端报告历史。批次里有 6 次正式任务、1 次测试任务和 2 笔各 20 USD 的订单，其中一笔全退。记录、时间、金额都是合成的，不是前面章节用户的后续；这里的任务次数也不等于人数。

先写下你准备根据数字改变什么

如果下周只有 6 小时可以改产品，我会先回答：“输入检查有没有阻止用户拿到可导出的文件？”这比“全面了解用户行为”窄得多，却足以影响下一轮工作：检查提示不清楚，就改善输入与恢复；文件已经生成但用不上，就去看输出内容；两边都没有可靠记录，就先修采集。

为这个问题，先记开始任务、输入被阻挡、文件生成这三个动作。付款与退款从另一条可信记录接入，放在同一份复盘里，但不拿付款按钮点击代替交易结果。

Segment 在自己的采集指南中，把业务目标放在命名和接入之前；它描述自己最初从注册、发送数据和开始订阅等核心事件做起，再增加解释其他问题的事件。这能借鉴的是先让几条记录回答一个问题，而不是照抄它的事件名。你的 CSV 工具，关键动作未必是注册。^[1]

这个选择也会丢掉一些信息。如果下周才想到查“用户有没有打开字段帮助”，而这周没记录，就不能从现有日志还原答案。可以在下一轮加一个有明确用途的事件，或经用户同意观察一次操作；不要把没采集解释成没人需要。

自动采集适合另一种情况：你知道某一页有问题，却还不知道用户在哪个交互上受阻。它能少写一些代码、保留探索线索，但仍要核对采到了什么、页面改动后含义是否变化。截至 2026-10-10，PostHog 文档提供按 URL、元素和属性筛选的配置，也明确关闭交互自动采集不会同时关闭页面导航采集；不能只关一个开关就认定没有其他记录。文档也说明表单值并非全部自动采集，具体配置仍须实际检查。^[2]

对这个处理客户表格的小工具，我会先选显式的少量事件，加上有限的任务观察。维护成本比较可控，也容易核对哪些字段离开浏览器。代价是遇到新问题时，可能要等下一轮观察；如果产品已经有很多路径、有人维护采集范围和访问权限，再考虑有限的自动采集更合适。这里不需要先决定买哪一家分析工具。

事件名写的是事实，还是愿望？

“导出成功”听起来很清楚，写进代码却可能有四个位置：点下按钮、开始生成、生成文件、用户真正把文件保存下来。它们不是同一件事。

M-01 把事件命名为 export_ready：必要输入已经通过检查，导出内容已生成，程序拿到了可交给下载动作的文件。它不证明浏览器保存成功，更不证明报告已经发给客户。需要确认后两件事，就在试用回访里单独问，不能给这个事件换一个更令人满意的中文名字。

task_id 在本例只标识一次工作尝试。刷新后的恢复应沿用它，另开一份报告才创建新的任务；它不能替代长期用户编号。未登录的人换设备、清掉本地记录，你通常无法仅靠这些事件确定是不是同一个人。不要为了凑出“准确人数”把语言、时区或相似行为硬拼成身份。

出海场景还要分开三个容易混淆的维度：界面使用哪种语言、任务面向哪种工作，以及用户实际所在地区。英语界面不能证明用户来自美国；北京时间的工作日也不能直接代表对方的工作日。此处事件时间统一写成带 Z 的 UTC，报表说明观察窗口；若以后按本地工作日分析，先取得有明确用途的时区信息，再保留转换规则。

{
  "event_id": "a-ready",
  "kind": "export_ready",
  "task_id": "A",
  "schema": 2,
  "env": "production",
  "occurred_at": "2026-10-07T10:00:00Z"
}

采集成功，要沿整条路核对

开发工具里出现一个请求，说明浏览器发过东西；接口返回成功，说明接收方按自己的契约答复了。报表要用它做决定，还需要确认字段、重复处理、环境和计算口径都符合约定。

比如一次请求超时，你不能确定服务器是否已经收到了。重发时保留事件编号，接收方才有机会识别它；如果客户端每次重试都生成新编号，仅靠事件去重仍会多算。所以报表还需要按任务或交易记录归并，而不是直接数通知条数。

交易链尤其不能依赖通知到达顺序。Stripe 的文档明确说事件可能重复、也不保证按生成顺序送达，并说明验签和重复识别的处理；这是一类需要在真实接入中核对的契约，并非某个平台才会出现的报表问题。^[3]

M-01 把付款和退款分别留下，算报表时再按订单汇合。退款先到、付款还没有找到，就放进待核对项，不让它悄悄变成负收入，也不能丢掉退款。真实订单存在分次付款、部分退款或多个币种时，还要扩展这份约定；不能照搬本例“一笔付款、一种币种”的简化。

同一批记录，为什么会有三种结果

观察日是 2026 年 10 月 7 日 UTC。初报在次日 00:00 截止；修订报等到 10 月 9 日 00:00，补进属于原观察日的迟到记录。下面先显示初报。你可以切换到未经检查的粗报，再看每一条记录怎样改变结果。

把三份报表放在一起看：直接数通知得到 7 条“导出”、7 条开始，看起来是 100%；付款重发也让粗报净收变成 40 USD。初报清理后是 2 / 6，净收 20 USD。迟到修订后变成 3 / 6，金额不变。报表更准确了，产品本身并没有因此改变。

最值得停下来的是 B 和 F。B 有一次点击，却缺少同口径的生成结果；F 没有有效结果记录，可能中途放弃，也可能成功但采集失败。这两次都不能擅自填成“失败”，更不能从分母里删掉。D 则有明确的阻塞记录，但我们还不知道它有没有换回旧工具、是否需要帮助。

“未收到”跟“没有发生”之间的空白，只能靠新的证据缩小。先用合成任务重走对应版本，检查浏览器请求和接收记录；涉及实际任务的后续，再在取得联系许可的前提下询问。不要补造历史事件。若后来人工确认已交付，保留为人工确认及其时间，不能伪装成当时的浏览器记录。

付款也没有替你证明价值。一个人可以付过钱却没有完成任务，一个工作室也可能让多人共用一笔采购。M-01 只是把任务和金额放在同一份复盘中，没有计算“每位用户收入”，没有把 20 USD 净收当利润或银行到账；进一步核对接经营复盘和提现。

动手跑一次：让多余字段和重复请求真的被拦住

下载 M-01 本机演练。先阅读脚本，再用 Node.js 22 或更新版本运行；无需依赖包、平台密钥或真实表格。

node measurement-drill.mjs

它会临时监听 127.0.0.1 的系统分配端口，以 HTTP 发送上述合成事件，打印检查结果后关闭服务。所有记录只在内存中，不连接第三方；时间由固定夹具提供，不是对真实网络延迟的测量。下载文件包含事件数据、校验规则和报表计算，可以改一条记录观察哪项断言不再成立。

本书在 2026-10-10 实际执行了这个脚本：19 次初始请求对应 16 条新记录、2 次重复回执、1 次字段拒收。初报计入 12 条，迟到修订计入 13 条；15 项检查还覆盖了同编号改内容、浏览器冒充交易来源、未知版本、业务记录重复、未配对退款和过大请求。这里实跑的是合成 HTTP 处理，不是实际产品或支付平台。

有一个细节容易被“字段拒收通过”掩盖：第 19 条里的合成文件名已经抵达本机收集器，拒收不能让它从未离开过发送端。因此真实产品要在浏览器发送之前就只构造允许字段；接收端校验是第二层保护。演练故意送入这个假值，用来验证它不会进入接收记录或错误回显，并没有读取文件。

把这份约定接进自己的产品时，我会先走完一份不含客户信息的样本：开始任务、制造一个输入错误、修复、生成文件。每一步核对发送内容和接收记录，再断开连接重试一次、刷新恢复一次、跑一遍测试环境。核对的是同一任务有没有变成两次、错误是否泄露原始数据、测试是否进了正式报表；仅仅看到接口返回成功还不够。

随后再检查采集许可关闭时是否仍有请求或存储、撤回后怎样停止，核对访问权限、保存期限与删除路径。不要只查应用写出的 JSON：SDK 自动属性、请求日志和错误监控也在实际数据流里。具体告知、合法依据及跨境安排接合规章；这个内存演练没有替你完成这些事项，也没有做生产持久化或供应商验签。

数字可靠以后，也不能直接说改版有效

现在假设记录终于对上了，下一周生成率比这周高。它可能来自改版，也可能因为新来的用户更熟悉 CSV、有人帮他们整理了输入，或者这一周任务更简单。前后数字值得调查，但它们本身不能把其他解释排除。

Microsoft 在 2020 年公开过一段更曲折的经历。MSN 团队把图片轮播从 12 张增加到 16 张，试验初看反而降低了互动；同时，分到两组并进入分析的人数比例出现异常。追查后发现，新版里更活跃的用户触发了机器人过滤规则，被排除在分析之外。问题修复后，效果方向翻了过来。^[4]

这里最有用的动作是：在讨论版本好坏之前，先追查消失了谁。检查随机分组、版本实际出现、事件送达和分析过滤是不是一致；不是看见结果不理想就换指标。样本比例失配（Sample Ratio Mismatch，SRM）是这种质量问题的诊断信号，判断需要同时考虑预计比例和样本数，两组不恰好一半并不自动代表故障。^[4]

对出海小工具，分组单位也需要认真选。若三位同事共同做一份客户周报，把他们拆成三个独立用户，可能让同一个工作室同时看到两套流程，也让同一份工作的结果被多次计算。美团技术团队在履约实验中讨论过类似的单位问题：区域之间共享运力，会让一组策略影响另一组；重复行为和真正独立的样本不能混用。小工作室没有履约平台那么复杂，但“谁会互相影响”仍然决定能否这样比较。^[5]

如果要做受控试验，我会在开始前写明：谁符合参加条件、按人还是工作室分组、同一单位怎样保持版本、何时算实际接触到变化，以及最后一批要观察多久。主指标只回答本轮的关键问题，另外看错误、等待时间或支持负担，防止生成次数上涨却把工作转移给用户。只分析点击过新按钮的人，往往已经把变化造成的选择混进样本；入组条件应尽量在变化发生前确定。^[4]

只有几十个用户，先算这次比较等不等得起

“多跑几天”听上去容易，可能意味着等上半年。这期间产品、来源和任务都变了，原来那次微小改版已经不值得单独回答。

下面另做一项试验规划假设，不使用 M-01 的 6 次任务估计基线：假定历史稳定完成率为 20%，希望识别提高到 25% 的变化。这个变化是 5 个百分点，相对提升为 25%，两种写法不能混用。

Evan Miller 的分析给出一个固定样本规划的粗略规则：每组数量约为 16 × p × (1 − p) / δ²。这里用基线 p = 0.20，绝对变化 δ = 0.05，得到约 1024 个独立单位 / 组；它对应常见的双侧 5% 显著性、约 80% 功效的粗估思路，不能替代实际设计时的计算。^[6]

这张估算器的作用是尽早发现量级不合适。Miller 的独立计算器在基线 20%、绝对变化 5 个百分点、80% 功效、5% 显著性时显示每组 1030；与上面的粗估略有差异。真正开跑前要选定方法，并把指标分布、随机单位、预期损失、分组比例和多重比较一起考虑，不能把页面上的整数当成通用门槛。^[7][5]

同样不该反复查看固定样本检验，等它第一次“显著”就停。Miller 专门分析过这种停止方式为什么会增加假阳性；预先设计的序贯方法是另一套规则，不等于每天刷新普通报表。^[6]

运行期间当然要看数据是否漏记、分组是否出错、有没有严重损害。发现导出内容错误就应暂停或回退，不能为了凑样本继续让用户受影响。停止是产品决定，是否可以据此宣称效果，则要按原先的分析规则判断。到期样本仍不足，结论可以是“本轮无法区分”，而不是“证明没有效果”。

把这轮工作收在一份决定里

回到 M-01，眼前的问题还不值得启动 A/B。我们只有 6 次任务，旧版含义不同，还有未知。此时最有价值的投入，是让下一批记录可靠，并看清 D 为什么卡住；把按钮换个颜色再比完成率，绕开了已经看见的问题。

下面是基于这批合成材料填好的安排。它是下一轮的工作决定，不是已经执行的用户研究。

还可以把一个想做的试验先写完整，再决定暂缓。下面这份 E-01 草案沿用上面的独立规划假设，不从 M-01 推出流量或基线。

每次改动最后留下的，应当是一份能接着做事的记录：使用哪个事件版本、观察哪段时间、排除了什么、结果有哪些未知，以及据此决定修什么或暂缓什么。下次看见一条漂亮曲线，先能解释它与上一版是否在数同一件事，再讨论产品真的进步了多少。