关于 pm-analytics
pm-analytics 是用于规划、执行或审视产品分析的技能,面向需要把产品数据转化为决策的团队。它从决策问题出发,强调可行动指标、分群、信号与噪声辨别,并以建议收尾。
主要功能
- 01从决策问题确定分析方向
- 02选择漏斗、队列、分群或路径分析
- 03辨别数据波动与可靠信号
- 04按用户群体拆分结果
- 05结合定量与定性证据
- 06将分析转成可执行建议
适用场景
- 01定位用户在注册流程中的流失环节
- 02比较不同用户群的留存表现
- 03评估产品指标变化并提出行动建议
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ uxcel-lab/ product-skills --skill pm-analytics安装后在 Claude Code 中输入/pm-analytics确认已加载。
详细介绍
产品分析技能
此技能的行为方式(请先阅读)
这是一项生成式流程技能(用于规划或执行分析,也可以评议分析)。分析是 AI 助手最容易自信地得出错误结论的领域:Claude 会报告虚荣指标(页面浏览量、注册总数),把相关性当作因果关系,把两天的峰值或n=20 的样本当作趋势,引用平均值(掩盖了所有有意思的细分群体),最后停留在“以下是数据”,而不是提出决策。没人会据此采取行动的仪表板,或建立在偏差上的洞察,还不如不做分析。
因此,此技能会把关以下事项:
- 明确背景——分析将为哪项决策或问题提供依据、对应的目标是什么,以及有哪些可用数据(这些因素决定要衡量什么以及采用哪种方法)。
- 应用始终适用的核心原则——先提问题,选择可执行的指标,区分信号与噪声,进行细分,结合定量与定性分析,并以建议收尾。
- 呈现取决于背景的决策(分析方法、领先指标与滞后指标、工具、归因模型、群组类型、留存窗口)及其权衡;由用户选择。
接下来会交由 pm-okr-metric-validity-audit 检查(所选指标是否有效,而非虚荣指标),并交由 pm-assumption-rigor-audit 检查(因果主张和分析结果是否经得起审视)。
范围:此技能负责分析流程——衡量什么、漏斗/群组/细分/用户旅程、从噪声中辨别信号,以及从数据到决策的叙述。它将指标定义是否严谨有效交由 pm-okr-metric-validity-audit,将受控变更的统计分析(样本量、显著性、护栏指标)交由 pm-experimentation-ab,将 OKR/KPI 产物交由 pm-okrs-kpis,并将用于探究定性“原因”的探索性研究交由 pm-discovery。
第 0 步——分析前明确背景
如果尚不清楚,请先询问;如果在未得到答复的情况下继续,请说明假设:
- 这项分析将为哪项决策或问题提供依据? 从问题而非数据出发——“为什么激活率下降了?”或“哪个新手引导步骤导致用户流失?”没有关联决策的分析只会产生噪声。
- 它对应什么目标? 将指标与业务/用户目标关联起来,确保衡量的是重要事项,而非方便追踪的事项。
- 有哪些数据,这些数据可信吗? 事件覆盖情况、时间范围、可用的细分维度、已知的追踪缺口。数据稀少或有偏,会改变你能够诚实得出的结论。
始终适用的核心原则(适用于任何分析)
衡量重要事项
- 先提问题,再看数据。 遵循分析生命周期:设定衡量目标 → 收集 → 分析 → 采取行动。每项洞察都为下一个问题提供依据。
- 优先选择可执行指标,而非虚荣指标。 页面浏览量和注册用户总数能让演示文稿更好看,却无法指导决策。检验方法是:“如果这个数字显著变化,我是否确切知道该怎么做?” 如果不知道,它就是虚荣指标。优先选择与行为相关的指标(首周激活、功能采用率、留存率)。
- 一个主要指标 + 护栏指标。 将分析与一项成功指标关联,同时监控健康度/护栏指标,避免为了“获胜”而牺牲其他方面。(这些指标是否严谨有效,应由
okr-metric-validity负责检查。)
诚实地解读数据
- 区分信号与噪声。 不要对小幅或短期波动过度反应;使用滚动窗口(30/90/365 天)和移动平均值,并在采取行动前,寻找不同时间段和细分群体中反复出现的模式。
- 避开数据陷阱——明确指出陷阱,并做好防范:
- 相关性 ≠ 因果关系——两个指标同步变化(推送通知 ↑、使用量 ↑),可能都由第三个因素驱动(例如节日活动)。寻找作用机制;通过实验确认原因(
experimentation-ab)。 - 幸存者偏差——只分析留下来的用户,会掩盖其他用户离开的原因。问问哪些人没有出现在数据中。
- 小样本诱惑——样本量 n=10 时提升 50%,到 n=1,000 时可能就消失了。等待数据充足后再下结论。
- 选择偏差——在查看数据 之前 确定成功指标;记录所有分析,而不只是那些看起来有利的分析。
- 相关性 ≠ 因果关系——两个指标同步变化(推送通知 ↑、使用量 ↑),可能都由第三个因素驱动(例如节日活动)。寻找作用机制;通过实验确认原因(
- 平均值会骗人——要细分。 “典型用户”通常并不存在。按设备、新用户与回访用户、获客来源和行为拆分结果;有意思的发现几乎总藏在某个子群体中(整体提升 10% 可能掩盖了移动端下降 5%)。
将数字转化为决策
- 先找出“为什么”,再结合定量与定性分析。 数字揭示了 发生了什么;与有趣模式背后的用户交谈(差点转化的用户、流失的重度用户),了解 为什么——然后回到数据中验证你听到的情况。
- 以洞察 → 影响 → 行动收尾。 先用业务语言说明问题,而不是直接给出原始指标(“新用户找不到核心功能,每月约损失 5 万美元”比“DAU 下降 15%”更好);选择能清晰呈现关键洞察的可视化方式,并以具体、明确负责人且可衡量的建议收尾。不能改变决策的分析,就还没有完成。
依具体情况决定(说明,不要自动应用)
逐项说明权衡,并给出与步骤 0 相关的建议;由用户选择。运行所有类型的分析,或提取所有指标,都是错误做法。
| 决策 | 适用情况 | 避免/调整的情况 | 默认建议 |
|---|---|---|---|
| 分析方法 | 对已知流程中逐步流失的情况使用 漏斗;对行为/留存如何随时间变化的情况使用 群组分析;对比不同群体的情况使用 细分分析;对非线性、跨触点行为使用 旅程/路径分析 | 将漏斗分析强加于探索性行为,或简单漏斗就能回答问题时仍使用路径分析 | 根据问题选择方法;转化用漏斗,留存用群组分析,用细分分析解释差异 |
| 领先指标与滞后指标 | 目标罕见/见效慢时,用领先指标(激活、功能采用率)尽早采取行动;用滞后指标(MRR、LTV)验证结果 | 仅依据滞后指标指导日常工作(行动太晚) | 两者结合:用领先指标指导行动,用滞后指标确认行动是否奏效 |
| 工具/平台 | 网站流量用 GA;产品事件/行为分析用 Mixpanel/Amplitude;用 Segment 统一数据管道;深入分析/历史数据用数据仓库(BigQuery/Snowflake);实时监控用实时工具 | 产品分析工具当下就能回答的问题,却过度设计数据仓库管道 | 使用现有的事件分析工具;只有在需要深入分析/历史数据时才添加数据仓库 |
| 群组类型 | 用 行为群组(是否执行了操作 X)寻找“顿悟时刻”;用 时间群组 隔离版本发布/季节性因素;用 获客群组 比较渠道质量 | 将某一种群组类型的结论当成能回答所有三类问题 | 用行为群组寻找激活驱动因素;用时间群组衡量变化的影响 |
| 留存窗口 | 日常使用的产品采用 N 日窗口;使用频率较低的产品采用每周/每月窗口;自然周期(如周日制定膳食计划)采用自定义窗口 | 对每周使用一次的产品采用日留存视角(造成误报) | 让窗口与产品自然的使用节奏相匹配 |
| 归因模型 | 简单转化归因采用末次点击;多个触点共同发挥作用时采用线性/时间衰减归因 | 用户旅程由上游渠道发起、却在其他渠道转化时仍采用末次点击(低估上游渠道贡献) | 用户旅程跨越多个渠道时采用多触点归因(线性/时间衰减);末次点击仅用于简单情况 |
| 定性研究深度 | 模式明确时采用轻量研究(支持工单、会话笔记);重大决策的关键在于弄清“为什么”时采用深入研究(访谈) | 面对代价高昂/不可逆的决策,仅依据定量数据采取行动 | 根据决策的重要程度安排定性研究深度;对于出乎意料的数据,始终用用户的原话进行合理性核验 |
验证结果(编排)
交接时使用每个视角对应的可安装技能
name。只有在该技能已安装时才调用;如果未安装,本技能的核心内容已包含这些规则,无需因此阻塞,直接继续。
产出或修订后,应将内容交给审计视角,而不是直接宣布完成。这些是候选视角——请根据 docs/orchestration-policy.md 中的方针来决定如何处理,或将整个文档交由 pm-product-review 审查。这里,assumption-rigor 是始终相关的视角(自动运行);其他视角则是可选项,根据文档实际包含的内容决定是否采用。如果用户调用此技能是为了处理某个特定事项,请遵守该范围。
pm-assumption-rigor-audit(自动运行)——因果关系是否成立(还是把相关性伪装成因果性)?解读是否客观(不存在选择偏差)?关键结论是否有证据支持,而非仅仅断言?pm-okr-metric-validity-audit(可选——如果文档提及或依赖指标)——这些指标是否可执行、有效(而非虚荣指标)、定义是否准确,且是否与目标相关?本技能将严格的指标定义标准交由该视角审查。
**组合方式(依据 docs/orchestration-policy.md §9):**若要以统计严谨性(样本量、显著性、护栏、窥视数据)验证某项变更,则后续可选用 pm-experimentation-ab(提议后续生成,不要自动生成);若要基于分析做出高风险、不可逆的决策,则由 pm-decision-quality-audit 检查决策流程。如果审计发现冲突,应以目标为准:分析旨在推动更好的决策——如果它依赖虚荣指标、未经细分的平均值或未经证实的因果关系,应在采取行动之前先修正。
常见的正确与错误做法
| ❌ 不要 | ✅ 应该 |
|---|---|
| 从数据说起 | 从决策/问题出发,再进行衡量 |
| 报告虚荣指标(页面浏览量、注册总数) | 使用可执行的指标——“指标一旦变化,我就知道该采取什么行动” |
| 把相关性当成因果性 | 寻找作用机制;通过实验确认因果关系 |
| 对两天的激增或 n=20 作出反应 | 使用滚动窗口;等待可重复的规律/足够的样本 |
| 只分析留下来的用户 | 追问哪些人不在其中——防范幸存者偏差 |
| 挑选有利于自己的细分结果 | 预先承诺成功指标;记录所有分析 |
| 只引用平均值 | 按设备/来源/行为细分——平均值会掩盖真相 |
| 只报告是什么,不解释为什么 | 将定量分析与定性分析结合起来,并用其中一方验证另一方 |
| 止步于数字 | 最后给出洞见 → 影响 → 行动,并明确负责人和可衡量的目标 |
| 在此处重新发明 A/B 测试的统计方法 | 将显著性/护栏交由 experimentation-ab 处理 |
| 未经检查就发布分析结果 | 交由 okr-metric-validity + assumption-rigor 审查 |