拆指标树，先给结果指标固定人群、时间和计数规则，再用加法或乘法把它拆到能够解释的子指标。每条连线都要说明关系：可以算回父节点的是公式，“改善它可能带动结果”则是假设。把这两类关系分开，指标树才有助于选择下一项工作。
例如“本周有效导出成功数下降”，不必马上做新功能。先确认有多少人发起任务、每人发起多少次、其中多少成功，再判断问题主要出在哪里。可以在白板中连接指标、公式与口径，让产品与数据同事对着同一棵树讨论。
把“成功一次”说清楚
下面用一组自拟的文件导出数据练习。统计对象是本周进入成功或失败终态的导出任务；同一任务因网络重试发起多次请求，仍按一个任务ID计数。取消、测试账号和重复上报另行排除，尚在运行的任务单独观察，不混入本例的分母。
这里的“本周”按任务结束时间划分，不是创建时间。发起人数也只计算这批任务对应的去重用户。如果另一张报表统计的是本周所有点击过导出按钮的人，两张表的人数就不能直接互换。
| 指标 | 示例数值 | 统计含义 |
|---|---|---|
| 发起人数 | 100人 | 上述终态任务对应的去重发起人 |
| 导出任务数 | 200次 | 按任务ID去重，成功与失败都计入 |
| 有效成功数 | 180次 | 产生可用导出文件的成功任务 |
| 失败数 | 20次 | 已结束且没有产生可用文件的任务 |
“有效成功”还要与产品规则对齐。仅返回成功状态码，但文件为空、用户无权访问或内容不完整，是否算成功，应在采集和验收时明确。不要为了让报表好看，把这些情况静默归入成功。
先画一层能算回去的乘法关系
本例人均任务数为200÷100＝2，任务成功率为180÷200＝90%。因此：
有效成功数 = 发起人数 × 人均任务数 × 任务成功率
180次 = 100人 × 2次/人 × 90%这条关系是由同一批数据的定义得到的。人数、次数和比率的单位能消去，最后回到成功次数。若算不回180，先检查去重、时间窗口和分母，不要立即认为数据异常是产品行为造成的。
Amplitude公开的指标树方法也将数学拆解与假设分支分开，并要求给比率配上规模。方法的价值在于看清数字关系，不在于把节点画得越多越好。
在白板里，把180次放在结果节点，下一层排列100人、2次/人和90%，连线旁标“相乘”。每个节点补充数据来源、负责人和更新时间。计算仍应在数据表或分析工具中完成，白板用于呈现关系与共同讨论。
加法分支要先排除重叠
成功次数可以按互斥的任务类型拆开。例如同一批180次成功任务中，PDF导出120次，表格导出60次；每个任务只有一个类型，120＋60＝180成立。如果一个操作同时产生两种文件，应先决定统计单位是“导出任务”还是“文件”，不能在两种单位间切换。
人数通常更容易重复。假设100名发起人中，70人用过PDF导出，50人用过表格导出，其中20人两种都用过，那么总人数是70＋50－20＝100，而不是120。两条产品线的用户数不能因为画成两个分支，就自动视为可相加。
| 想画的关系 | 可以成立的条件 | 需要回查的情况 |
|---|---|---|
| 总成功数＝各任务类型成功数之和 | 类型互斥、覆盖完整、单位相同 | 同一任务进入多种类型，或存在未分类任务 |
| 成功数＝任务数×成功率 | 成功率分母就是这批任务 | 任务数按创建周，成功率按结束周 |
| 总用户数＝两群用户数之和 | 两群用户互不重叠 | 同一用户可进入两群，需要集合去重 |
类似地，把两个渠道的成功率直接平均也常会出错。一个渠道10次任务全部成功，另一个渠道90次任务成功72次，总成功率应为82÷100＝82%，不是把100%与80%平均得到90%。需要平均比率时，先找到正确的权重。
“有关系”不一定能写成公式
“进度提示更清楚，用户就更少重复点击”是一个可能有用的解释，但它不属于前面的恒等式。提示是否真的影响重复点击，需要操作观察、日志或实验支持；不能直接在树上写“新增进度提示＝成功率提高”。
可以将这类节点放在成功率旁，用虚线连接，并写明推测和证据状态。例如：“假设H1：用户误以为导出没开始而重复操作；依据：三条脱敏反馈，尚未观察操作过程。”接下来先验证误解是否存在，而不是让一条虚线替团队做出开发决定。
若任务ID无法区分原任务与重试，眼前的工作是补齐统计基础。可按事件设计与埋点验收方法确定字段和上报时机。指标定义和事件实现需要对应，但本页的树不必展开成整套埋点文档。
用同一组数比较可能的改善空间
在其他因素保持不变的假设下，成功率从90%升到95%，会得到100×2×95%＝190次成功，比示例多10次。若人数从100增加到110，而人均次数与成功率不变，则为110×2×90%＝198次，多18次。
这两项都是条件演算，不是效果预测。新增用户可能更不熟悉操作，成功率未必不变；为了提高人均次数而鼓励重复导出，也可能浪费用户时间。数字较大的方案不自动拥有更高优先级，还要比较问题严重性、证据、成本和团队能影响的范围。
本例20次失败是已观察到的损失，可以先按原因查看。其中若有一类失败集中在某种文件，应回到任务记录查找触发条件；不能仅凭该类型的失败率高就认定它最值得做，因为任务规模与修复成本也会改变判断。
让树留下下一项具体工作
讨论结束时，选一个节点并写明下一步。例如：“核对20次失败中，有多少来自用户重复点击后新建的不同任务ID；同一任务的网络重试仍然去重。数据同事确认数量，产品查看操作记录，判断重复发起是否与进度反馈不清有关。”这比“提高成功率”更能安排实际工作。
在树旁保留三个区域即可：当前口径、待补数据、正在验证的假设。每次更新数值时写清时间范围，公式与规则变化也同步更新。想继续了解漏斗、分群或对比方法，可阅读产品经理数据分析方法；指标树负责拆清组成，后续分析负责解释为什么变化。
