AI 产品指标体系：衡量与优化
构建 AI 产品的北极星指标体系，掌握 DAU/留存/LTV 在 AI 产品中的特殊计算方式与优化策略
构建 AI 产品的北极星指标体系，掌握 DAU/留存/LTV 在 AI 产品中的特殊计算方式与优化策略
一份可评审的产品证据：假设、原型、评测结果或上线决定。
写清产品决定、支持它的证据，以及进入下一阶段的门槛。
AI product 最危险的一种状态，是团队每天都很忙，但没人能准确回答“这个 feature 到底有没有变好”。只看 usage 不够，只看 thumbs up 也不够，只看模型 benchmark 更不够。AI PM 要管理的是一整套从 value 到 quality 再到 cost 的指标链条。
所以这页不是单纯讲 dashboard，而是帮你建立一套能驱动决策的 AI metrics system。
先说结论：AI 指标不能只看增长，还要看代价
传统产品常见的误区是：活跃涨了，就以为产品变好了。
AI 产品还要追问：
- 用户有没有真正完成任务
- 完成质量怎么样
- 为了这个结果花了多少 cost
少任何一块，指标都会误导你。
AI Metrics 更像一张三层结构图
| 层级 | 你该看什么 |
|---|---|
| Business | revenue、conversion、retention、ROI |
| Product / Quality | task success、satisfaction、accuracy、regenerate rate |
| Efficiency / Cost | latency、token usage、cost per task、margin |
如果 dashboard 里只有第一层和第三层，中间没有 quality，你会不知道为什么用户在流失。
如果只有质量没有成本，你会不知道为什么业务算不过来。
North Star Metric，别设计得太虚
很多 AI 产品喜欢用“AI 使用次数”当 North Star。这个指标通常太浅。
更合理的思路是：
North Star = successful task completion x quality factor
举例：
| 产品类型 | 更靠谱的 North Star |
|---|---|
| AI writing tool | weekly adopted output |
| AI support copilot | resolved tickets assisted by AI |
| AI search | successful answer sessions |
| AI coding assistant | accepted AI-generated code changes |
关键是“用户真的用了结果”，而不是“AI 只是说过一段话”。
先定义什么叫成功任务
AI PM 非常容易跳过这一步，直接上埋点。
但你必须先定义：
| 场景 | 什么叫 success |
|---|---|
| AI summary | 用户不用重写太多就能继续用 |
| AI drafting | 输出被采纳，而不是只生成 |
| AI support | 问题被解决，而不是聊天轮数变长 |
| AI search | 用户拿到可信答案并停止继续搜 |
没有 success definition，后面所有 metrics 都是半空的。
一套够用的核心指标
1. Value metrics
| 指标 | 说明 |
|---|---|
| task success rate | 任务有没有做成 |
| adoption rate | 用户是否愿意继续用 |
| assisted conversion | AI 是否真的推动业务结果 |
2. Quality metrics
| 指标 | 说明 |
|---|---|
| satisfaction / thumbs up | 用户主观感受 |
| regenerate rate | 用户对首答不满意的间接信号 |
| hallucination rate | 高风险内容是否在乱说 |
| edit distance / acceptance rate | 生成内容到底被改了多少 |
3. Efficiency metrics
| 指标 | 说明 |
|---|---|
| avg latency | 用户愿不愿意等 |
| tokens per request | prompt 是否失控增长 |
| cost per successful task | 这才是真正的经营指标 |
| model routing ratio | 小模型和大模型的分流是否合理 |
最容易被误读的几个指标
| 指标 | 为什么会误导 |
|---|---|
| session length | 长不一定好，可能是模型没解决问题 |
| total prompts | 多不一定代表价值，可能是用户在反复重试 |
| thumbs up rate | 没反馈的人不代表满意 |
| avg cost per request | 没结合 success 看，信息不够 |
AI PM 要养成一个习惯：任何单一指标，都要找一个反向指标一起看。
Dashboard 应该怎么搭更实用
一个更靠谱的 metrics board，至少分 4 块：
| 模块 | 主要问题 |
|---|---|
| acquisition / activation | 用户有没有真正进入 AI 场景 |
| task quality | 首答、复答、采纳质量如何 |
| cost / performance | 响应快不快，成本高不高 |
| risk / trust | 有没有 bad answer、安全问题、投诉 |
这比单独看一张“DAU 曲线”有用得多。
质量指标，一定要混合自动和人工
很多 AI 产品前期都没有足够好的自动评估，所以人审不能省。
更稳的做法是：
online metrics
+ sampled human review
+ labeled bad cases
+ weekly trend review
自动指标告诉你“哪里可能有问题”，人工 review 才能告诉你“问题到底是什么”。
成本指标要直连业务
只报 monthly API bill 没什么管理价值。
更应该看：
| 指标 | 更有用的问法 |
|---|---|
| cost per request | 每次调用花多少钱 |
| cost per successful task | 做成一件事要花多少钱 |
| AI gross margin | 扣掉 AI cost 后还有没有空间 |
| wasted generation ratio | 多少生成根本没被用上 |
如果你发现 usage 在涨，但 cost per successful task 也一起涨，那不一定是好消息。
一套简单但够用的 Weekly Review
每周复盘时，AI PM 最少回答这 5 个问题：
- 哪个 use case 的 success rate 变了
- 哪类 bad answer 变多了
- 用户是因为什么在 regenerate
- 哪条模型路由最烧钱
- 哪个指标变化值得进入下周 roadmap
把这 5 个问题固定下来，团队的数据讨论会清楚很多。
Practice
拿你现在在做的一个 AI feature，把现有 dashboard 看一遍，然后补 3 个问题：
- 现在有没有明确的 success definition
- 有没有
cost per successful task - 有没有稳定的人审抽样机制
如果这 3 个都没有，这个 metrics system 基本还停留在“看热闹”阶段。
每个指标都要有 Metric Contract
继续“先预览、后注册”的发布。只写“注册率”会让产品、数据和工程各算出一个数字。
| 字段 | 示例 |
|---|---|
| 指标名 | Preview-to-registration completion |
| 分母 | 看见结果预览且符合实验条件的独立用户 |
| 分子 | 在规定时间窗内完成验证并创建账号的用户 |
| 排除 | 员工、测试账号、机器人、已有账号 |
| 时间窗 | 首次预览后 24 小时 |
| 切片 | 渠道、设备、地区、验证码结果 |
| 数据源 | 事件表、账号表、实验分流表 |
| Owner | 产品定义，数据实现，工程验证埋点 |
| 决策 | 与基线和护栏一起决定继续、保持或回滚 |
指标定义一旦在实验中途改变，必须产生新版本，不能悄悄覆盖旧口径。
指标变好时，先查四个陷阱
- 分母变了：是不是少统计了一批失败用户？
- 流量变了：是不是新渠道本来就更容易转化？
- 价值被提前透支：用户注册增加，但后续留存下降了吗？
- 风险被平均数藏住：某个地区或设备是否明显恶化？
一个可以做决定的 Review 结论
已知：实验组注册完成率提高；验证码成功率保持稳定。
限制：移动端样本仍不足，且 7 日留存尚未成熟。
坏样本：部分用户误以为预览内容已经永久保存。
决定：保持 5% 流量，修正文案；不继续放量，等待移动端与留存证据。
完成标准
- 主指标有明确分子、分母、排除项和时间窗
- 至少一个质量、成本和风险护栏与主指标同行
- Dashboard 可以下钻到关键用户切片和失败样本
- 数据延迟、缺失和口径版本对读者可见
- Weekly Review 最后产生继续、保持、修正或停止决定
本章交付物
留下一个 Metric Decision Pack：指标合同、基线、护栏、切片、坏样本和本周决定。随后进入 AI Ethics & Compliance，检查“指标变好”是否以用户安全、隐私或公平为代价。
📚 相关资源
❓ 常见问题
点击问题，查看本章对应的实践答案。
AI 产品指标体系的三层结构是什么？
Business（revenue、conversion、retention、ROI）、Product/Quality（task success、satisfaction、accuracy、regenerate rate）、Efficiency/Cost（latency、token usage、cost per task、margin）。只有第一层和第三层、缺中间 quality 层，就不知道用户为什么流失；只有质量没有成本，业务永远算不过来。
把「AI 使用次数」当 North Star 为什么不靠谱？
太浅——它只衡量「AI 说过话」，不衡量「用户用了结果」。更合理是 successful task completion × quality factor：AI writing 看 weekly adopted output、support copilot 看 AI-assisted resolved tickets、AI search 看 successful answer sessions、coding assistant 看 accepted AI-generated code changes。
哪些 AI 指标看起来正常其实在误导你？
4 个常见陷阱：session length（长不一定好，可能是模型没解决问题）、total prompts（多不一定有价值，可能是用户在反复重试）、thumbs up rate（没反馈的人不代表满意）、avg cost per request（没结合 success 看信息不够）。任何单一指标都要找一个反向指标一起看。
AI 产品的 success definition 该怎么定？
按场景具体写：AI summary——用户不用大改就能继续用；AI drafting——输出被采纳而不是只生成；AI support——问题被解决而不是聊天轮数变长；AI search——用户拿到可信答案并停止继续搜。没有 success definition，后面所有指标都是半空的。
AI 成本指标怎么报才对业务有意义？
光报 monthly API bill 没管理价值。盯 4 个：cost per request（每次调用花多少）、cost per successful task（做成一件事的钱）、AI gross margin（扣掉 AI cost 还剩多少）、wasted generation ratio（多少生成根本没被用上）。如果 usage 在涨但 cost per successful task 也在涨，那不一定是好消息。