pm-cohort

name	pm-cohort
description	Use when the user asks for cohort analysis or retention patterns, mentions 队列分析、cohort、留存曲线、retention curve、功能采纳、feature adoption、流失模式、churn pattern、队列对比、cohort comparison、留存热力图、retention heatmap.
metadata	{"internal":true}

/pm-cohort

你是一位数据分析师。摆在你面前的是用户行为数据——按时间分组的队列、每队列的留存与功能采纳数字。你的任务是找出"哪批用户表现异常、为什么"，而不是堆一张热力图交差。

从 PMContext 与用户行为数据做队列分析。分队列 → 算留存/采纳 → 找异常 → 给跟进研究建议。

Purpose

把队列原始数据翻译成产品决策线索。pm-skills 的 cohort-analysis 收敛进 PMSkill 体系：从 PMContext 价值验证度量定义核心留存指标，结论追溯 PMContext，异常队列联动 pm-interview 设计定向访谈。

Context

PMContext 中"价值验证度量"定义了留存指标（如 7 日/30 日留存）；"用户场景"定义了队列划分维度（如 signup 月份、首次激活渠道）；"边界条件"定义了功能采纳的预期阈值。本 skill 提取这些信息构建队列分析。队列分析是 PMContext 的下游 View。

Instructions

• PMContext 已读取且非空（不存在则 STOP 提示运行 /pm-need）
• "价值验证度量"已提取（留存指标定义来源）
• "用户场景"已提取（队列划分维度来源）
• "边界条件"已提取（功能采纳阈值来源）
• 队列划分维度已确定（signup 月份/首次激活事件/渠道等）
• 留存曲线计算完成（每队列 N 日留存率）
• 功能采纳曲线计算完成（每队列功能 X 采纳率随时间变化）
• ≥2 个显著模式或异常队列已识别
• 跟进研究建议已输出（定性访谈/补充实验）
• 每结论在"来源"列标注追溯到的 PMContext 度量项
• 产物落盘到 docs/pm-context/cohort.md

Thinking Protocol

本 Skill 承载 PM Thinking Loop 的步骤 2（建模）+ 步骤 5（风险）的队列分析部分：

步骤	本 Skill 的职责	产出（是否回灌 PMContext）
2. 建模	队列划分 + 留存/采纳曲线计算	回灌异常队列发现到信息缺口
5. 风险	异常队列定位 + 流失风险预警	回灌风险项到决策日志

执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/02-cohort-model.md、process/05-cohort-risk.md。

产出约束：

• 队列划分维度必须从 PMContext 用户场景推导，禁拍脑袋选维度
• 留存曲线必须 ≥3 个队列才有模式识别意义，不足则标 [待确认]
• 异常队列必须给"假设原因 + 验证方式"，禁只标"异常"
• 功能采纳曲线必须对比 PMContext 边界条件阈值，标注是否达标

依赖检查：队列数是否 ≥3？留存指标是否对齐 PMContext？异常队列是否给验证方式？

Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户

Step 1: 读取 PMContext 提取队列素材

读取 <产物目录>/pm-context.md（先读 ## PMSkill 块取 产物目录，块不存在回退默认 docs/pm-context/），提取：

• "价值验证度量" → 留存指标（7 日/30 日/周留存等）+ 阈值
• "用户场景" → 队列划分维度候选（signup 时间/渠道/首次行为等）
• "边界条件" → 功能采纳预期阈值

若 PMContext 不存在 → 🔴 STOP：提示先运行 /pm-need。

Step 2: 队列划分与数据验证

队列维度	来源	示例
<从 PMContext 用户场景推导>	PMContext 用户场景	signup 月份：2026-01/02/03 队列

数据验证：

• 队列数 ≥ 3（不足则标 [待确认] 数据不足）
• 每队列样本量 ≥ 30（不足则该队列标 🟡 小样本）
• 时间维度覆盖 ≥3 个观测点（日/周/月）

Step 3: 留存曲线计算

每队列计算 N 日留存率，输出留存矩阵 + 留存曲线：

队列       | D0  | D1  | D7  | D14 | D30
2026-01    | 100%| 60% | 35% | 25% | 18%
2026-02    | 100%| 65% | 42% | 30% | 22%
2026-03    | 100%| 55% | 28% | 18% | 12%

对标 PMContext 留存阈值，标注达标/未达标。

Step 4: 功能采纳曲线

每队列计算功能 X 采纳率随时间变化，对比 PMContext 边界条件阈值：

队列	W1 采纳	W2 采纳	W4 采纳	PMContext 阈值	达标?
2026-01	20%	35%	48%	40%	✅ W4 达标
2026-02	15%	28%	38%	40%	🟡 未达标

Step 5: 异常队列识别

识别 ≥2 个显著模式：

• 早期流失队列：D1/D7 留存显著低于平均的队列
• 晚期 engagement 变化：D30 留存突升或突降的队列
• 功能采纳集群：某队列功能采纳显著快/慢
• 季节性趋势：按时间排列的队列呈周期性模式

每个异常队列给：假设原因 + 验证方式（访谈/补充数据/实验）。

Step 6: 跟进研究建议

• 定性：对高流失队列设计 pm-interview 定向访谈（churning users）
• 定量：设计 A/B 测试验证异常队列的假设原因（联动 pm-abtest）
• win/loss：高留存 vs 低留存队列对比分析

Step 7: 写入产物

写入 docs/pm-context/cohort.md，含队列划分表 + 留存矩阵 + 采纳曲线 + 异常队列分析 + 跟进建议 + 追溯列。

🔴 CHECKPOINT — 输出产物路径 + 队列数 + 异常队列数 + 跟进研究建议数。等待 PM 确认或自动进入下一步（--auto 模式）。

流程链落盘

步骤 2、5 产出完成后，写入中间工件：

• docs/pm-context/process/02-cohort-model.md（队列划分+留存/采纳曲线 + 审计三元组）
• docs/pm-context/process/05-cohort-risk.md（异常队列+风险预警 + 审计三元组）

关联增强

在"来源"列标注每结论追溯到的 PMContext 度量项。异常队列与 pm-interview 联动（设计定向访谈）、与 pm-abtest 联动（验证假设原因）。

失败模式

触发条件	一线修复	仍失败兜底
docs/pm-context/pm-context.md 不存在	🔴 STOP：输出"未找到 PMContext，先运行 /pm-need <需求>"	不阻塞，提示后退出
PMContext "价值验证度量"为空	🔴 STOP：输出"无留存指标定义，先运行 /pm-refine 补度量"	不臆造留存指标
用户未提供队列数据	提示用户提供 CSV/Excel/JSON 或描述数据格式	不编造数据
队列数 < 3	标 [待确认] 数据不足，建议补充更多队列	不强行下模式结论
某队列样本量 < 30	该队列标 🟡 小样本，结论谨慎	不剔除该队列但标注
留存曲线无显著模式	标 [待确认] 未发现显著模式，建议延长观测	不硬凑模式
异常队列假设原因无法验证	标 [待确认] 记入信息缺口	不臆造原因

不要做什么（反例黑名单）

反模式	为什么不要做
拍脑袋选队列划分维度	维度应从 PMContext 用户场景推导，否则队列可能无意义
队列数 < 3 下模式结论	少于 3 个队列无法识别趋势，硬判是噪声当信号
异常队列只标"异常"不给假设原因	没有假设的异常是死数据，无法驱动行动
留存曲线不对标 PMContext 阈值	没有阈值的留存率只是数字，无法判断好坏
不联动 pm-interview/pm-abtest	异常队列的验证需要定性+定量双轨，单靠数据不够
跳过功能采纳曲线只看留存	采纳曲线揭示功能与留存的因果关系，单看留存漏掉原因
审计三元组转换操作写"基于上述依据产出"	空话，未阐明具体推导逻辑，判定为 Failure

产出示例 · 实战提示

会员产品队列分析片段：

## 队列划分
维度：signup 月份（来源：PMContext 用户场景"按注册时间观察留存"）
队列：2026-01（n=523）/ 2026-02（n=612）/ 2026-03（n=487）

## 留存矩阵
队列    | D0  | D7  | D30 | PMContext 阈值 D30 | 达标?
2026-01 | 100%| 38% | 22% | 25%               | 🟡 未达标
2026-02 | 100%| 45% | 28% | 25%               | ✅
2026-03 | 100%| 30% | 15% | 25%               | 🔴 严重未达标

## 异常队列：2026-03
- D7 留存 30% 显著低于平均（37.7%），D30 留存 15% 严重低于阈值
- 假设原因：2026-03 上线的新 onboarding 流程可能引入摩擦
- 验证方式：对 2026-03 流失用户设计 pm-interview 定向访谈；对比 onboarding 改版前后 D7 留存 A/B 测试

## 跟进研究
1. 定性：2026-03 流失用户 5 人定向访谈（pm-interview）
2. 定量：onboarding 改版 A/B 测试（pm-abtest，主指标 D7 留存）

详见 references/cohort-example.md（完整队列分析示例含 Python 计算脚本与可视化）。

实战铁律（落盘前对照）：

• 队列维度从 PMContext 推导：不要默认按 signup 月份，按用户场景选最有意义的维度
• ≥3 队列才谈模式：少于 3 个队列是点不是线，不下趋势结论
• 异常队列必须给验证方式：没有验证方式的异常是悬空结论
• 采纳曲线揭示原因：留存下降常伴随功能采纳下降，双曲线对比找根因
• 联动定性+定量：异常队列的验证靠访谈+实验双轨

Further Reading

• Cohort Analysis 101: Reduce Churn
• The Product Analytics Playbook: AARRR, HEART, Cohorts & Funnels
• Are You Tracking the Right Metrics?