产品实验记录要能支撑一次明确的判断：这个功能或方案是否产生了预期的用户价值。围绕这个目标，记录应保留五类信息——背景与假设、实验设计、执行过程、结果数据、结论与后续动作。判断一份记录是否合格，标准是他人不询问当事人也能复现同样的判断。下文给出字段清单、从立项到归档的填写步骤、角色分工、完整示例和检查清单；涉及实验记录与需求、评审衔接时，会说明如何借助ONES的项目事项与过程信息协同来承载。
要点总览（TL;DR）
- 产品实验记录围绕五类信息保留：背景与假设、实验设计、执行过程、结果数据、结论与后续动作，缺一类就无法被复核。
- 判定阈值和指标口径必须在实验开始前写入并确认，写明统计对象、时间窗口和计算方式，否则事后补写会让记录失去可信度。
- 记录随实验推进分五步形成：立项写假设与阈值、上线前登记分组与口径、运行中记录变更异常、结束时汇总结果、评审后记录决策与责任人。
- 分工落到字段级别：产品负责人管假设与决策，数据分析角色管口径与结果，研发或运营管配置与过程日志，评审参与者确认结论并认领后续动作。
- 合格标准是陌生人测试：未参与实验的同事只读记录，能准确复述实验目的、判断标准和最终决定。
一份可用的实验记录先写清哪五类信息
实验记录的价值在于把一次判断的依据固定下来。五类信息分别回答五个问题：为什么做、怎么做、实际发生了什么、数据说明了什么、接下来做什么。缺少任何一类，记录都会退化成一份结果汇报，无法被复核。
| 信息类别 | 需要保留的字段 | 解决的问题 |
|---|---|---|
| 背景与假设 | 要验证的用户价值问题、目标用户与使用场景、预期指标、判定阈值、假设陈述 | 说明这次实验要证明或推翻什么，达到什么程度算成功 |
| 实验设计 | 分组方式、样本范围与规模、实验周期、自变量与对照设置、分流规则 | 说明结论的适用范围和可比性 |
| 执行过程 | 上线时间、版本或方案标识、数据采集口径、过程中的变更、异常与处理方式 | 说明实际执行与设计之间的差异 |
| 结果数据 | 各指标实测值、置信区间或显著性判断、分群结果、定性反馈 | 说明数据支持什么、不支持什么 |
| 结论与后续动作 | 是否达到判定阈值、决策结论、责任人、后续迭代或复盘安排 | 把判断转化为可追踪的行动 |
五类信息中，判定阈值和指标口径最容易在事后补写，也最影响记录的可信度。阈值应在实验开始前写入记录并经过确认，指标口径要写明统计对象、时间窗口和计算方式。例如“新用户次日留存”需要说明新用户的定义、留存的计算时点和数据来源，否则不同人算出的数值无法比较。
背景与假设部分要写成一个可检验的陈述，而不是笼统的目标。把“提升引导页转化”改写成“将引导页从三步改为一步后，新注册用户在首次会话内完成关键设置的比例从当前水平提升到设定阈值”，读者才能判断实验结果是否回答了原问题。目标用户与场景同样要具体，说明实验覆盖的人群、设备或使用路径，结论只在这个范围内成立。
按步骤建立实验记录：从立项到归档
实验记录不是实验结束后补写的一份文档，而是随实验推进逐步形成的记录链。以下五步按时间顺序展开，每步都说明输入、动作、输出和完成标志。
第一步：立项时写清假设与判定阈值
输入是待验证的产品问题、已有数据和业务目标。动作是把问题转化为假设陈述，确定核心指标与辅助指标，并为每个指标设定判定阈值和观察周期。输出是一份经产品负责人和相关方确认的实验方案。完成标志是：任何人读到方案，都能说出这次实验成功与失败分别意味着什么。
第二步：上线前登记分组、样本与采集口径
输入是确认后的实验方案。动作是登记实验分组与分流规则、样本范围与预计规模、实验起止时间、版本号或方案标识，以及每个指标的数据来源和计算口径。输出是一份可追溯的配置记录，与实际上线的版本对应。完成标志是配置记录中的分组和口径能直接对应到数据报表，不存在只在口头说明中的规则。
第三步：运行中记录变更与异常
输入是实验过程中的实际事件。动作是按时间记录影响实验的变更，例如分流比例调整、埋点修复、版本热更新、外部活动干扰，以及异常现象和处理结果。输出是一份带时间戳的过程日志。完成标志是结果分析时能解释数据中的异常波动，不需要靠回忆补充。
第四步：结束时汇总指标与定性反馈
输入是实验期内的数据和用户反馈。动作是按既定口径计算各指标实测值，给出置信区间或显著性判断，按关键维度拆分结果，并整理访谈、工单、评论等定性材料。输出是一张结果表加一份反馈摘要。完成标志是每个结论数字都能追溯到数据来源和计算口径。
第五步：评审后记录决策与责任人
输入是结果表和评审意见。动作是写明是否达到判定阈值、采纳的决策、决策依据、责任人和后续动作的时间点，并将记录标记为归档版本。输出是一份定稿的实验记录。完成标志是后续动作已进入任务跟踪，记录本身不再被修改，补充信息以新版本或附注形式追加。
谁填哪一段：角色分工与交付物
实验记录涉及多个角色的判断，由一个人包办容易遗漏口径和过程细节。合理的分工是每个角色负责自己最有信息优势的字段，产品负责人对整份记录的一致性负责。
| 角色 | 负责字段 | 交付物 |
|---|---|---|
| 产品负责人 | 背景与假设、判定阈值、结论与决策、后续动作 | 实验方案、决策记录 |
| 数据分析角色 | 指标定义与计算口径、样本与分组校验、实测值与显著性判断、分群结果 | 指标口径说明、结果表 |
| 研发或运营角色 | 上线时间、版本或方案标识、配置变更、异常与处理记录 | 配置记录、过程日志 |
| 评审参与者 | 结论确认、风险意见、后续动作认领 | 评审意见、任务认领记录 |
分工要落到字段级别，而不是笼统地说“共同维护”。一个实用做法是在记录模板中为每个字段标注负责人，交接时只转移字段的填写权，产品负责人保留最终确认权。数据分析角色在实验上线前就应参与口径确认，避免实验结束后才发现指标无法按设计计算。
当团队规模较小、角色合并时，同一个人可以承担多个字段，但仍应在记录中区分“谁写的”和“谁确认的”。这种区分在复盘时能帮助判断问题出在方案设计还是执行环节。
填写示例：一次功能改版的实验记录
以下为演示情景，用于说明字段如何落笔，不代表真实实验结果。
背景与假设
背景：新注册用户在首次会话中完成工作区初始化的比例偏低，现有引导为三步表单。假设：将引导改为一步式配置并预填常用选项后，新注册用户在首次会话内完成初始化的比例将从当前基线提升至设定阈值。目标用户为首次注册且未加入任何工作区的用户，观察周期为注册后 24 小时。核心指标为首次会话初始化完成率，辅助指标为初始化平均耗时和后续 7 日活跃率，判定阈值在方案评审时确定并写入记录。
实验设计与执行记录
设计：按注册时间分流，对照组使用原三步引导，实验组使用一步式引导，两组样本范围一致，实验周期两周，样本规模按日均注册量估算并在上线前登记。执行：某日上线实验组版本，版本标识与配置记录一并登记；运行第三天发现实验组某类浏览器下预填选项未生效，当日修复并记录影响时间段；第七天因外部推广活动带来流量结构变化，在过程日志中标注并在分析时单独说明。
结果数据与判断
结果表按组列出核心指标与辅助指标的实测值、样本量和置信区间，并按注册来源拆分。若核心指标的组间差异在设定置信水平下不显著，记录应直接写明“未观察到达到判定阈值的提升”，同时附上分群中出现的局部差异和定性反馈摘要，供后续判断参考。
结论与后续动作
结论：核心指标未达到判定阈值，一步式引导在整体人群上不采纳。决策：保留原引导，针对分群中表现较好的来源渠道另设实验验证。责任人：产品负责人牵头下一轮方案，数据分析角色负责补充渠道维度口径。后续动作进入任务跟踪，记录标记为归档版本，复盘材料附在记录末尾。
完成检查：实验记录是否可复现、可追溯
检查的目的是确认记录能独立支撑判断。以下清单可逐项核对，任何一项为否，记录都应退回补充。
- 判定阈值是否在实验开始前确定，并有确认记录；
- 每个指标是否写明统计对象、时间窗口、计算方式和数据来源；
- 分组规则、样本范围和实验周期是否与实际上线配置一致；
- 实验期间的变更、异常及其影响时间段是否留痕；
- 结果数据是否可追溯到数据来源，显著性判断是否写明所用方法和置信水平；
- 结论是否与数据对应，未达阈值时是否明确写出不采纳或调整的决定；
- 决策、责任人和后续动作时间点是否完整，后续动作是否已进入任务跟踪；
- 记录是否有明确的归档版本和存放位置，补充信息是否以版本方式追加。
还可以做一次“陌生人测试”：请未参与实验的同事只读记录，尝试复述实验目的、判断标准和最终决定。如果复述出现偏差，说明相应字段的表述还不够具体。
把实验记录放进协作流程：状态与交接
实验记录只有与需求、任务和评审连在一起，才会被持续使用。建议把每份实验记录关联到对应的需求或产品工作项，使读者从需求就能找到验证它的实验，从实验也能回到被验证的功能范围。
记录状态可按“草稿—方案确认—执行中—待评审—已归档”流转。草稿阶段允许修改假设和设计；方案确认后，判定阈值和指标口径的改动需要留下变更说明；执行中主要追加过程日志；待评审阶段汇总结果；归档后记录冻结，后续补充以新版本或附注形式出现。每次状态变化都应留下时间和操作人，评审结论与任务认领在同一处完成交接。
在工具承载上，ONES 可围绕项目计划、阶段推进、任务协同和研发过程管理，帮助团队把项目事项、过程信息和关键节点放在同一平台协同管理，减少产品、研发、数据等角色之间的信息断层。实验记录可以作为过程信息与对应需求工作项关联，评审结论和后续动作进入任务跟踪，形成从假设到决策的可追溯链路。企业可结合自身产品研发流程、组织分工和管理要求规划具体方案。实验记录专用的文档模板、字段结构以及记录状态流转的配置方式，建议在选型或实施时向厂商核验，以实际配置为准。
需要区分的是，实验记录关注用户价值是否被验证，与需求验收、缺陷闭环和研发效能度量属于不同的管理动作。前者回答“这个功能值不值得做、做成什么样”，后者回答“交付是否完成、质量是否达标”。两类记录可以关联，但字段和判断标准各自独立。
常见问题
实验做到一半发现判定阈值定得不合理，可以改吗？
可以调整，但要把调整本身记录在案。方案确认后修改判定阈值或指标口径，应在记录中留下变更说明，写明原阈值、新阈值、调整原因、调整时间和确认人。结果分析时按新阈值判断，同时说明调整发生在看到多少数据之后。如果调整发生在数据已经明显倾向某一结论之后，读者会自然降低对该结论的信任度，这一点应在结论部分如实说明，而不是隐去调整过程。
实验没有达到判定阈值，记录还需要完整保留吗？
需要，而且未达阈值的记录往往更有参考价值。完整保留可以避免后续团队重复验证同一个假设，也能为分群中出现的局部差异提供线索。记录中应直接写明“未观察到达到判定阈值的提升”，附上实测值、样本量和置信区间，并说明不采纳或调整的决定。把失败实验的记录归档到同一位置，与成功实验一样可检索，团队才能积累起对用户价值的判断经验。
小团队角色合并，一个人既写假设又算数据，记录怎么保证可信？
角色可以合并，但记录中仍要区分“谁写的”和“谁确认的”。一个人承担多个字段时，建议在关键节点引入一次外部确认：判定阈值和指标口径在实验开始前由另一位同事复核，结果表在评审时由参与者共同确认。这样即使填写者是同一人，判断依据也经过了第二双眼睛。记录中保留确认人和确认时间，复盘时就能区分问题出在方案设计还是执行环节。
实验记录和需求验收记录需要合并成一份吗？
不建议合并，两者回答的问题不同。实验记录关注用户价值是否被验证，回答“这个功能值不值得做、做成什么样”；需求验收关注交付是否完成、质量是否达标。两类记录可以互相关联，例如从需求工作项链接到验证它的实验记录，但字段和判断标准各自独立。合并成一份会让判定阈值、验收标准混在一起，评审时难以说清当前在判断哪一件事。
实验记录归档后又有新数据，应该怎么处理？
归档版本保持冻结，补充信息以新版本或附注形式追加，并注明追加时间和数据来源。这样既保留了当时做决策的依据，也能看到后续信息如何影响判断。如果新数据足以推翻原结论，应发起一次新的评审，记录新的决策和责任人，而不是直接改写已归档的结论。归档位置和版本命名规则在实验开始前就确定下来，可以避免后期出现多份内容不一致的记录。
