“转化率跌了，肯定是新版本不好用。”
这句话跳过两个问题：指标真的可比吗？变化真的来自产品体验吗？在具体排查中，需要先排除口径、覆盖或分母变化，再判断业务本身是否发生了变化。
Data Analytics Skills 把这段工作分成两个 Skill：Metric Diagnostics 解释变化，Product & Business Analysis 把解释转成有证据的业务选择。前者对“发生了什么”负责，后者对“该做什么”负责。
第一步不是找原因，是复现变化
原文把诊断拆成一个明确顺序：先定义问题，再验证来源，再建立模式，最后才分解驱动。
“建立模式”这一步最容易被跳过。它要求先量化变化的规模、时间与范围：跌了多少、从哪天开始、影响哪些人群和粒度。在规模、时间和范围被验证或明确标记为不确定之前，不应该开始搜索原因。
原因是最容易“找”出来的东西。只要愿意，任何一次下跌都能配上一段听起来合理的故事。先复现变化，是用数据把可解释的空间收窄。
口径与来源要一起验证
Metric Diagnostics 要求确认指标定义、粒度、聚合逻辑、过滤、Join、排除规则、时效与血缘，并检查可信表面之间是否存在分歧。
它也提醒不要被熟悉的表名迷惑：当前上下文、命名语义层和常见表名都只是来源候选，不是来源选择。对于宽泛的指标问题，应该在可用的表、看板、指标文档和语义层中做一次实际发现，并同时检查一个业务表面和一个底层来源，然后说明为什么选定的来源控制这个答案。
这一步在实际工作里经常被压缩成“用我们平时用的那张表”。如果那张表的粒度或过滤和这次的决策不匹配，后面所有精致的分解都会建立在错误的基础上。
率、加总与分组：三种诊断路径
原文按问题类型给出不同的诊断方式：
- 指标变化：对比窗口与基线，排序列出分组贡献，检查同行与历史背景，区分结构变化与组内变化。
- 尖峰、回退或事故：锁定起点、峰值、恢复、分布形态（而不只看均值）、受影响切片，以及是否发生流量或失败行为变化。
- 集中度与最大贡献者：先定义“最大”，再排序、比较份额与变化，找出主要变动者、进入者与退出者。
- 对账与差异分析：对齐定义、过滤、粒度、分子、分母与排除项，量化各组成部分，并说明残差。
对率类指标，要先看是分子变了还是分母变了。对加总指标，要计算贡献份额。当结构变化与组内表现同时存在时，两者的区分往往决定解释的走向。
一个容易被误读的例子
教学设定：高转化渠道的转化率始终 20%，低转化渠道始终 5%。前期两个渠道访问量各占 50%，整体转化率 12.5%；本期访问占比变成 20% 和 80%，整体转化率降到 8%。
复算：
- 前期：0.5 × 0.2 + 0.5 × 0.05 = 0.125
- 本期：0.2 × 0.2 + 0.8 × 0.05 = 0.08
- 差值：−0.045，即 −4.5 个百分点
各渠道自身的转化率一点没变，整体却跌了 4.5 个百分点。这是典型的结构效应（mix shift）。
这个例子说明了诊断的边界：算术分解能说明“变化如何组成”，但不能证明渠道占比为什么变了。要回答后者，需要继续核实流量来源和业务动作。把结构效应直接写成“渠道质量下降”，就是把解释力用超了。
测量问题也是解释，不是清理工作
原文特别强调：日志变更、近期数据未齐、重复记录、分母漂移，都可能是变化的真实原因，而不只是需要“清理掉”的噪音。
这个视角的差别很大。如果一次下跌其实来自埋点改动，那么所有围绕用户体验的假设都白做了；如果一次上升来自回填，那么它根本不是业务改善。
因此，当新鲜度、粒度、Join、缺失、Schema 漂移、异常值或分布变化可能影响可信度时，原文要求调用 Analyze Data Quality，而不是在诊断里顺手绕过。
从诊断到行动：换一个起点
Product & Business Analysis 的起点不是数据，而是决定。它要求先写清楚：
- 这个分析要支持什么决定
- 谁会使用答案，他们能采取什么行动
- 什么范围和比较能构成有用的答案
- 哪个结果或行为对决定真正重要
- 需要哪些假设才能开始
这个顺序能防止一种常见失败：范围不清时，分析自动扩张成宽泛的探索，最后交出一堆切片，却没有建议。
原文给出的判断透镜包括当前规模、趋势、广度、集中度、强度、效率、可行动性、差异性、替代性、风险与依赖、覆盖度。这些是思考工具，不是检查清单——只保留会改变建议的那几个。
贡献最大，不等于最该行动
沿用前面的案例。高转化渠道的贡献值得查，但要不要增加预算，取决于成本、容量和可扩量性。诊断告诉你哪里变化最大；行动选择取决于你能动什么、动了之后会发生什么。
这是两个 Skill 分工的核心：诊断交付可复核的解释，业务分析交付有条件的选择。连接两者的，是“能改变决定的证据”。
建议要带条件交接
原文对交接的要求很具体：把已验证、可能解释和未解释分开；明确下一步、支撑证据、依赖和不确定性；证据不足时把建议标为暂定，并说明什么检查能提高信心。
分享前用 Validate Data 复核，再交给 Build Report 组织报告。同期发生的业务事件仍不能自动当成因果——时间吻合只是提出假设的条件，不是证据。
设计自己的诊断流程时
三个可以立刻用的检查：
- 在解释之前，能不能用一句话说清“跌了多少、从何时开始、影响谁”？
- 每个主要驱动，是否都有量化的贡献份额，并且能对上总量或明确说明残差？
- 建议里是否写清了条件？没有条件的建议，通常意味着证据还没到位。
诊断交付可复核的解释，业务分析交付有条件的选择。两者都不承诺“找到真相”，只承诺把证据的边界说清楚。