AI 产品 Time to Value 基线：从首次有效输入到可信结果要多久

用户注册成功、打开工作台或发送第一条提示词，都不一定意味着获得价值。AI 产品经常把“模型返回了文本”当作激活，但用户可能还要修正事实、补充上下文、等待同事审批，最后仍然回到旧工具。Time to Value（TTV）必须结束在一个对用户任务有意义且达到最低质量门的结果，而不是结束在接口返回 200。

建立基线的目的，是在改 onboarding、提示词或模型之前保留一个可比较的事实版本。否则团队只能看到新流程“感觉更快”，无法判断是用户更快完成了任务，还是系统降低了验收标准。

明确定义四个里程碑

对一个“把客服对话生成可发布帮助文档”的产品，可以定义：

• start：合格用户首次上传一份满足格式要求的对话；
• activation：系统成功解析输入并生成第一版草稿；
• first_value：用户确认关键事实无误，并导出或发布草稿；
• repeat_value：同一组织在 14 天内完成第二份文档。

TTV 是 first_value.timestamp - start.timestamp。注册到首次上传可另记为获客或引导时间，不能混入同一个指标。对于必须人工审批的高风险产品，审批完成才是 first_value；删掉审批只为缩短数字，会让指标失去业务含义。

如何判断用户真正的价值动作，可以对照AI 产品 onboarding 设计，但事件名称必须按自己的任务定义。定义发布后版本化，例如 valueDefinition=v2；改变终点时不能把新旧数据直接连成一条趋势线。

用同一条链路采集时间和质量

为每次价值尝试创建不含个人信息的 journeyId，在客户端、API、模型调用、人工复核和最终导出事件中传递。每个事件至少包含匿名组织、用户分群、时间戳、产品版本、模型版本、结果状态和失败原因。分布式步骤可以使用 trace/span 思路连接，但产品事件仍需保留业务语义。

除了时间，还要记录：开始人数、到达首个价值人数、放弃阶段、模型重试、人工修改分钟数、严重错误、单次成本和是否在观察窗内重复。没有质量护栏的 TTV 很容易被“默认生成一个结果”优化；没有完成率的 TTV 会只统计幸存者。

原始事件应满足三个可回放条件：同一个 journeyId 的阶段顺序可验证；重复事件有幂等键；服务端时间统一为 UTC，并保留客户端上报延迟。抽样检查时，应能从最终导出回到输入授权和每次生成，而不是只剩一条聚合曲线。

分位数比平均值更能暴露阻塞

假设 40 名合格新用户开始任务，30 人完成首个可信结果，完成率是 30 / 40 = 75%。30 个完成样本的 TTV 排序后，P50 为 11 分钟、P75 为 26 分钟、P90 为 74 分钟，平均值为 22 分钟。若只看平均值，会掩盖少数用户在权限配置或大文件处理上等待一小时的问题。

再按阶段分解：输入准备 P50 为 4 分钟，生成 P50 为 40 秒，人工校验 P50 为 5 分钟，发布 P50 为 1 分钟。此时把模型延迟从 40 秒降到 20 秒，对总体首次价值帮助很小；提供可下载的输入模板或减少无效返工更有价值。优化机会应该由阶段占比和失败数量共同决定。

同时计算未完成者：10 人中 4 人卡在数据授权，3 人输入格式错误，2 人认为结果不可信，1 人超时。每个分母必须固定为“符合画像并触发 start 的用户”，不能在报告里排除失败者。留存结果应与AI 产品留存与 churn连接，验证更快的首次价值是否真的带来重复使用。

基线采集需要冻结条件

选择一个固定观察窗，例如连续 14 天或至少 50 次合格旅程。期间冻结核心 onboarding、价值定义和默认模型；紧急修复要记录版本并分层报告。排除员工、自动化测试和已完成过任务的老用户，但要提前写下排除规则，不能看到数据后临时清理异常值。

基线报告至少输出：样本量、完成率、TTV 的 P50/P75/P90、各阶段耗时、失败原因、人工介入率、严重错误率、单次成本和 14 天重复价值率。样本小可以报告区间和原始分布，不要用“提升 37%”掩盖只有几个人的事实。

每次优化都做成可证伪实验

假设团队准备增加预填模板，目标是把输入准备 P50 从 4 分钟降到 2 分钟。预先规定主指标为首个可信结果完成率，时间指标为 TTV P75，护栏为严重错误率不增加、单次成本不高于基线 10%、人工介入率不增加。用 Feature Flag 分流合格新用户，确保两组价值定义一致。

如果新组 TTV P75 从 26 分钟降到 18 分钟，但完成率从 75% 降到 60%，就不能宣布成功。应回放放弃旅程，确认模板是否误导用户跳过必要信息。实验设计可参考AI 功能 A/B 测试，上线策略可参考AI 功能灰度与 Feature Flag。

基线验收清单

• start 和 first_value 是否对应用户任务，而非页面或接口事件？
• 结果是否经过最低质量或审批门，定义是否有版本？
• 完成与未完成旅程是否使用同一固定分母？
• 是否报告分位数、阶段耗时、错误、人工时间和成本？
• 随机抽取 5 个 journeyId 能否从输入回放到最终结果？
• 优化是否同时检查完成率、重复价值和质量护栏？

TTV 基线不是一个越小越好的秒表，而是一份价值交付诊断图。它让团队知道用户在哪一步等待、为什么放弃、快速结果是否可信，以及速度改善是否转化为后续使用。只有这些问题都能回答，缩短时间才代表产品变好。

延伸阅读

• AI 产品 onboarding 设计
• AI 产品留存与 churn
• AI 功能 A/B 测试
• Agent 在线评测指标