度量从问题开始：六个决策与十二个指标

看板不是用来证明你在做数据驱动，是用来在十分钟内回答一个具体问题。

一、四十个数字，一个回答不了的问题

陈默做那款发票整理工具「零票」已经八个月。看板是他第三周搭的，一开始只有六个数字，每加一个功能就加一行，到第八个月变成了四十个：注册、激活、会话时长、页面浏览量、每个按钮的点击、每种导出格式的使用次数。他每周一早上打开它，平均停留二十分钟，真正会看的是「付费用户数」那一格，其余三十九个扫一眼颜色，绿的就往下滚。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

十月的产品周会上，有人问他：「要不要做导出功能？」他打开看板，翻了十分钟，发现自己找不到能回答这个问题的数字——导出次数有，但他不知道那些次数来自几个人，也不知道用过导出的人有没有留下来。他最后说：「我觉得可以做。」散会之后他意识到，「我觉得」三个字就是这套看板的全部产出。

数字多不等于看得清。 四十个数字并列在一屏上，看起来每个都同等重要，实际效果是每个都不重要。人对一排绿灯的注意力会在三十秒内耗尽，剩下的时间只是在确认「没有红灯」，而不是在判断「该做什么」。

指标要挂在决策上。 一个数字如果没有对应的、即将要做的决定，它就只是背景。背景可以有很多，决策一周只有几个。看板的格子数应该等于决策数乘以每个决策需要的证据数，而不是功能数乘以能埋的点数。

一人产品的看板贵在少。 大团队可以养一个分析岗，让二十个人各看自己那一段。一个人的时间预算里，看数据这一项每周只有十几分钟，超过这个预算的部分，会先从「深读」退化成「扫一眼」，再退化成「不打开」。

先有 12 个，再谈扩展。 12 不是一个神秘数字，它是「六个决策 × 两个指标」算出来的容量。先把这 12 个用满六周，用出「哪个指标真的改变过决定」的记录，再谈第二批。扩展的依据应该是缺口，不是好奇。

二、六个决策，每个两个指标

把看板倒过来设计：先写决策，再写指标。一个人做产品，每周真正要拍板的事情基本落在下面六类里，多出来的通常是这六类的变体。

这张表有两个用法。第一个是正向的：要拍板时先找到对应的行，只读那一行的两个数字，读完就能给结论。第二个是反向的：看到某个数字异动，先问它属于哪一行，如果找不到归属，说明这个数字暂时不该留在看板上。

有两行值得单独说明。「做不做」用的是首次创建和邀请率，而不是「有多少人点了这个按钮」——按钮点击只能证明有人好奇，首次创建证明新方向真的被用起来了，邀请率证明它好到值得告诉别人。「哪步卡住」把整链转化和首屏 P95 放在一起，是因为链路漏得厉害时，第一件要排除的事往往是「人根本没等到页面加载完」。

指标要能被同一个人读两次。 六个决策里有四个每周都会出现，这意味着同一行会被读几十次。如果两个指标的口径在两次读之间变过，你看到的「变化」有一半来自口径。所以每个指标除了名字，还要固定写清分子、分母和统计周期，写在看板标题旁边，而不是藏在文档里。

六个决策不必每周全读。 平静的一周通常只有「有没有人用」和「坏没坏」需要看，其余四行在发布前和月末各读一次就够。把阅读频率也写进表里，能进一步压缩每周的固定成本。

三、三层：结果、驱动、护栏

十二个指标不是平铺的，它们分三层。分层的理由不是好看，是这三层回答的问题完全不同，混在一起读会把「现在怎么样」和「为什么这样」搅成一句话。

结果层只有三个数字，因为它们对应三件最终要成立的事：有人从访客走到付费、来的人留得下来、留下来的人在付钱。这三个数字以周为单位看几乎没有变化，用它们指导本周的动作会一直迟到。

驱动层是结果层的原因。激活率决定整链转化的第二段，首次创建决定激活之后有没有价值，WAU/MAU 决定月留存的分母结构，续费率和邀请率分别决定收入与传播。它们的共同点是：一次产品改动可以在一到两周内让它们动，而且动了之后能解释清楚是哪次改动。

护栏层必须单独一层，理由是它不能进目标。把崩溃会话占比设成「本周要降到 1% 以下」，团队就会开始把崩溃会话算成正常退出；把退款率设成 KPI，客服就会开始劝用户别退。护栏指标的读法是 veto：它破线时，无论结果层多好看，本周的结论都是「先修」。

三层之间只有一种合法运算：同层相除、跨层描述。驱动层上升可以说「这可能解释结果层的变化」，不能说「驱动层涨了 5%，所以结果层会涨 5%」。这条规则在只有一个人的产品里尤其重要，因为没有第二个人来提醒你这句话不成立。

层与层之间会出现矛盾，这正是分层的用途。 结果层持平时驱动层在涨，说明改动起了作用但还没穿透到最终结果；结果层在涨而护栏层破线，说明增长是拿稳定性换的。矛盾不是数据出错，是需要解释的信号。

四、复算：四十个与十二个的每周成本

成本不只是读的时间，还包括「读完之后仍然不确定」的时间。下面只算前者，因为后者无法用秒表量。

读取成本（每个数字按 30 秒计，含找到位置、判断是否异常）：
  40 个数字 × 30 秒 = 1,200 秒 = 20 分钟/周
  12 个指标 × 30 秒 =   360 秒 =  6 分钟/周
  每周差额 = 14 分钟
  14 分钟 × 52 周 = 728 分钟 = 12.1 小时/年

使用密度：
  40 个数字里，每周真正进入决策的 4 个
  4 ÷ 40 = 10%
  12 个指标 ÷ 6 个决策 = 每个决策 2 个

扩展节奏：
  第 1 周：上线 12 个，其余全部折叠归档
  第 1–6 周：每周记一行「这周哪个指标改变了决定」
  第 7 周：只加有缺口证据的第二批

20 分钟和 6 分钟的差别，单看一周不算什么。乘到 52 周是 728 分钟，也就是 12.1 小时。这个数字的意义不在于「省下了一天半」，而在于一天半可以拿去做一次真正的用户访谈，或者把某个高流失页面的空状态改完。

12.1 小时不是省下的时间，是换成了看对数字的时间。 如果砍掉 28 个数字之后，那 12 个仍然只是扫一眼，这 12.1 小时就没有被换走，只是被浪费得更安静。真正的换法是：省下的 14 分钟里，拿出 6 分钟读那 12 个，剩下 8 分钟用来做「读完之后的动作」——查一个异常、写一条假设、改一处文案。

10% 这个比例比 12.1 小时更值得警惕。 四十个数字里有三十六个每周不进入任何决定，它们不是中性的，它们会稀释注意力：当一屏上全是同等大小的格子时，人会用「有没有变红」代替「这个数字说明什么」，而前者只需要一秒钟。

12 ÷ 6 = 2 是一条自检线。 随便指一个指标，你应该能在十秒内说出它服务哪个决策、读它之后会做什么。说不出来，它就该离开看板，不管它多么容易埋点。这条线对「看起来很专业」的指标特别有效，比如会话时长和页面浏览量，它们几乎从不单独改变一个决定。

六周是扩展的最短观察期。 少于六周，你还没经历一次完整的发布、一次月末结算和一次至少一周的平静期，加进来的指标很可能只是在重复已有的信息。第二批判据不是「我想知道」，而是「过去六周里，有哪次决定因为缺这个数字而做错了」。

30 秒是一个偏乐观的假设。 如果你每读一个数字要花两分钟——先确认口径、再对比上周、再想起这个数字上周是不是也这样——那么 40 个数字是 80 分钟/周，结论只会更强。反过来，如果某个数字你三秒就能读完并且每周都用，它就不该被砍，12 个是容量，不是上限。

五、行动清单与复算验收

这八条按顺序做，前三条一个下午能完成，后五条要六周。

先做减法，再做加法。 顺序不能反：如果先设计新指标，你会在旧看板上再加十个格子，两周后回到原点。先把四十个折叠起来，你才知道 12 个的空位在哪里，也才会认真对待每个空位。

把口径写进看板，不要写进记忆。 口径写在文档里等于没写，因为读数字的人不会先打开文档。写在同一屏上，抬头就能看见，三个月后的你才可能读对同一条线。

• 写下最近一个月真正拍过的板，合并同类项，压缩到六个决策。
• 给每个决策选两个指标，优先选能在一到两周内被改动影响的那个。
• 把现有看板截图，把不属于这 12 个的格子全部折叠到一个「归档」页。
• 给每个指标写一行口径：分子、分母、统计周期、数据来源。
• 标注哪 4 个是护栏指标，并在看板上把它们和另外 8 个在视觉上分开。
• 每周一记录一行：本周哪个指标改变了哪个决定。
• 第六周统计这 12 个里有几个从未出现过，写下去留理由。
• 第七周只根据缺口证据决定是否加第二批，不因为「好奇」加。

验收标准：随便点一个指标，你能在十秒内说出它服务哪个决策、读完之后会做什么；说不出来的指标，本周就该从看板上撤掉。

使用边界与实操验收

本文不覆盖事件怎么埋。 指标口径和事件字典是两件事，前者决定读什么，后者决定数据从哪来。事件命名、属性与变更记录在下一篇，本篇只假设你已经有一个能按人、按时间聚合的事件表。

12 个是这一组基线的容量，不是行业标准。 基线是月访问 4,800、注册 1,150、付费 120 的产品，整链转化 2.5%。如果你的产品还在前 100 个用户，六个决策里可能只有「有没有人用」和「哪步卡住」有数据，其余四个先留空比填假数字好。

指标不是 KPI。 这 12 个数字的用途是让一次决定有依据，不是给谁打分。一旦某个指标变成考核项，它就会开始被优化而不是被观察，护栏层尤其如此——这也是它必须单独一层的现实原因。

验收看行为，不看图表。 合格的标志不是看板做得多漂亮，而是开会时你能在十分钟内给出「做」或「不做」以及依据哪一个数字。做不到，就回到第二节的表，检查是不是有决策没配指标。

工具选择放在最后。 如果一张表格能装下 12 个指标和六周记录，就先不要引入按事件计价的第三方服务。工具的价值在协作与历史留存，一个人的产品在前六个月通常用不到这两样，却要先付出一笔固定成本。

关键参考与核验范围

核验日期：2026-10-26。以下链接用于核对指标分层、事件采集与服务端指标命名的通用做法，本文的 12 个指标与全部数字均为本系列基线的教学演示。

• Plan your taxonomy | Amplitude Docs ：用于核对「先定义要回答的问题、再定义事件与指标」的规划顺序。
• OpenTelemetry semantic conventions ：用于核对 5xx 率与首屏 P95 这类服务端与前端护栏指标的通用命名口径。
• Events - Docs - PostHog ：用于核对事件、属性与用户标识在采集侧的最小集合。

引用口径。 外部链接只用于确认通用概念与命名，不引用其产品价格、套餐限制或具体实现细节；本文出现的所有比例、金额与时长均来自本系列统一基线，或由基线在本篇内四则运算得出。

可访问性。 三条链接均在 2026-10-26 当日实测可访问，页面标题与用途一致；若日后链接失效，以页面存档或同一产品的文档目录重新定位，不要凭记忆补写条款。

核验范围。 未核验任何第三方分析工具的当前版本功能与计费方式，也未引用行业基准报告中的留存或转化中位数。三层结构是本文的组织方法，不是某个工具的官方模型。

如何自行复核。 用你最近四次真实决策回填第二节的表：每次决策当时读了哪些数字、结论是什么、后来对不对。如果某次决策读的数字不在 12 个里，把它加进候选；如果某个指标四次都没被读，把它移出。这比照抄任何模板都准。

系列导航

• 上一篇：无，本文是系列第一篇
• 下一篇：事件字典：二十四个事件、六个属性与一张变更表
• 回到目录：一个人的产品度量：事件字典、指标口径与决策看板
• 相关阅读：决策记录：写清做什么，也写清不做什么