cohort-analysis

Cohort 分析技能

生成结构化的 Cohort 分析，涵盖留存曲线、LTV 估算、行为细分、流失先行指标和优先级干预措施。输出可直接用于向产品负责人汇报，或与增长和数据团队分享。

---

必填输入

开始前，请询问缺失的任何输入。不要编造数字、基准或架构详情。

输入	缺失时应询问的内容
分析目标	改善留存 / LTV 建模 / 行为细分 / 流失预测——选择一个主要目标
产品或功能	要分析什么？
Cohort 定义	按什么标准对用户进行 Cohort 分组？（获取月份、注册渠道、套餐层级、功能采用日期）
观察窗口	跟踪多少个周期？（例如，12 个月、8 周）
关键指标	每个 Cohort 要衡量什么？（留存率、收入、互动评分、功能使用情况）
可用数据	粘贴架构、表名，或说明有哪些指标——不要自行假设
基准或目标	有没有可用于比较的现有留存基准或目标？

如果用户无法提供实际数据，请生成包含明确占位符（[X%]、[£X]、[N users]）的框架，并注明哪些部分需要真实数据才能完成。

---

流程

按顺序执行以下步骤：

1. 确认输入——在生成输出前指出任何不明确之处（例如，Cohort 定义相互冲突、缺少观察窗口）。
2. 定义 Cohort——确定进入事件、退出标准和排除项，确保 Cohort 之间互斥。
3. 构建留存表——填写或创建按周期排列的矩阵模板；找出平台期。
4. 预测 LTV——仅使用观测到的留存数据；如果数据不足，请明确标记。
5. 按行为细分——创建互斥的行为细分；确定激活阈值。
6. 指出流失先行信号——列出可观测信号、提前量及对应的干预措施。
7. 比较不同时间段的 Cohort——评估产品变更是否反映在较新的 Cohort 中。
8. 确定建议优先级——将每条建议关联到具体的 Cohort 或细分发现。
9. 提供 SQL 参考——如果用户提供了实际架构，则根据该架构调整模板查询。
10. 执行质量检查——交付前核实所有检查清单项目。

---

输出模板

按顺序生成以下部分。仅在明确不属于范围时才省略某个部分，并注明省略情况。

---

Cohort 分析：[产品 / 功能]

分析目标： [留存 / LTV / 行为细分 / 流失预测] Cohort 定义： [例如，获取月份——按首次注册的日历月份对用户分组] 观察窗口： [X 个月 / 周] 主要指标： [指标名称和定义] 数据来源： [使用的表或指标——未提供时不要编造] 编制日期： [日期]

---

1. Cohort 定义

Cohort	周期	规模	描述
[Cohort 1]	[2025 年 1 月]	[N users]	[例如，通过自然搜索在 2025 年 1 月注册的用户]
[Cohort 2]	[2025 年 2 月]	[N users]	[描述]

Cohort 逻辑：

• 进入事件： [例如，首次注册 / 首次购买 / 功能激活]
• 退出 / 流失定义： [例如，30 天内没有符合关键留存事件的活动]
• 排除项： [例如，内部测试账号、数据不足 3 天的试用用户、用户数少于 [N] 的 Cohort——参见反模式]

注意： 如果任何 Cohort 未达到统计可靠性的最低规模阈值，请明确标记，并将其排除在趋势结论之外。

---

2. 留存曲线

阅读方式： 每个单元格显示该群组在第 N 个周期执行关键留存事件的百分比。周期 0 根据定义为 100%。

群组	P0	P1	P2	P3	P6	P12
[2025 年 1 月]	100%	[X%]	[X%]	[X%]	[X%]	[X%]
[2025 年 2 月]	100%	[X%]	[X%]	[X%]	[X%]	[X%]
[相较上一群组的趋势]	—	[↑/↓ X 个百分点]	[↑/↓ X 个百分点]	[↑/↓ X 个百分点]	[↑/↓ X 个百分点]	[↑/↓ X 个百分点]

留存平台期： [曲线在哪个周期趋于平缓？平缓时的留存率是多少？如果观察窗口过短，无法呈现平台期，请明确说明。]

关键观察：

• [例如：单周期最大跌幅出现在 P1 → P2，平均为 X 个百分点——这是需要重点应对的流失时刻]
• [例如：通过 [渠道] 获取的群组在 P6 的留存率比总体平均值高 X 个百分点]
• [例如：P3 留存率从最早群组的 X% 变为最新群组的 Y%——变化了 Z 个百分点]

留存图表 — 每个群组绘制一条线，周期为 x 轴：

{
  "type": "line",
  "title": "Retention by cohort (%)",
  "labels": ["P0", "P1", "P2", "P3", "P6", "P12"],
  "series": [
    { "name": "[Cohort 1]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] },
    { "name": "[Cohort 2]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] }
  ]
}

---

3. LTV 预测

如果没有收入数据，请跳过本节。没有数据来源时，不要估算 ARPU——请注明数据缺口并索取数据。

每周期 ARPU： [每位活跃用户每周期的币种和金额——来源：X] 使用的留存曲线： [所用群组或混合平均值，以及原因]

周期	留存率	每位留存用户的收入	累计 LTV
第 1 个月	[X%]	[£X]	[£X]
第 3 个月	[X%]	[£X]	[£X]
第 6 个月	[X%]	[£X]	[£X]
第 12 个月	[X%]	[£X]	[£X]

12 个月混合 LTV： [£X — 请说明包含哪些群组以及加权方法]

按细分群体划分的 LTV：

细分群体	LTV（12 个月）	相较混合基准	差异的主要驱动因素
[自然流量]	[£X]	[+X%]	[例如：P6 留存率更高]
[付费]	[£X]	[-X%]	[例如：激活率更低]
[企业]	[£X]	[+X%]	[例如：每周期 ARPU 更高]

---

4. 行为细分

细分群体根据用户做过什么来定义，而非他们何时加入。在分析人群中，各细分群体必须互斥且覆盖全部人群。

细分群体	定义	占群组比例	留存率（P6）	LTV（12 个月）
高频用户	[例如：在前 30 天内每周完成核心操作 ≥ 3 次]	[X%]	[X%]	[£X]
轻度用户	[例如：在前 30 天内每周完成核心操作 1–2 次]	[X%]	[X%]	[£X]
不活跃用户	[例如：曾登录但从未完成核心操作]	[X%]	[X%]	[£X]
从未激活	[例如：已注册但从未完成第 1 步引导流程]	[X%]	[X%]	[£X]

激活门槛（“顿悟时刻”）： [在最初 X 天内完成的哪项具体操作最能预测长期留存？请从数据中得出结论——不要套用泛泛的答案。]

---

5. 流失的领先指标

用户流失之前出现的信号，可用于提前干预。列出的所有信号都必须能在生产数据中观测到——仅属理论的信号请予以标注。

信号	流失前的提前时间	相关性强度	建议的干预措施
[例如：连续 7 天未登录]	[7 天]	[强 / 中 / 弱]	[例如：第 7 天发送自动召回邮件]
[例如：存在未解决升级问题的支持工单]	[约 14 天]	[中]	[例如：升级后 48 小时内由 CSM 主动联系]
[例如：核心功能使用量环比下降 >50%]	[约 10 天]	[强]	[例如：在应用内提示并链接至用例教程]

数据要求： 相关性强度必须基于观测数据。如果无法获得数据，请标记为 [假设 — 尚未验证]，并建议通过 A/B 测试或生存分析进行确认。

---

6. 队列对比：随时间变化的趋势

评估产品变更是否体现在较新队列的留存结果中。

指标	[最早队列]	[最新队列]	变化	备注
P1 留存率	[X%]	[X%]	[↑/↓ X 个百分点]
P3 留存率	[X%]	[X%]	[↑/↓ X 个百分点]
激活率	[X%]	[X%]	[↑/↓ X 个百分点]
前 30 天平均会话数	[X]	[X]	[↑/↓]

结论：[较新的队列表现更好还是更差？这段时间上线了什么内容可能解释这种变化？如果没有可用的因果解释，请明确说明——不要编造。]

---

7. 建议

每条建议都必须引用上述章节中的具体队列、细分群体或信号。删去适用于任何产品的泛泛建议。

#	建议	依据的发现	目标细分群体	预期影响	投入	优先级
1	[具体行动]	[第 X 节，发现 Y]	[细分群体]	[例如：P1 留存率提升 X 个百分点——估算依据]	[低 / 中 / 高]	P1
2	[具体行动]	[第 X 节，发现 Y]	[细分群体]	[例如：P3 留存率提升 X 个百分点]	[低 / 中 / 高]	P1
3	[具体行动]	[第 X 节，发现 Y]	[细分群体]	[例如：12 个月 LTV 增加 £X]	[低 / 中 / 高]	P2

如果无法根据现有数据估算预期影响，请明确说明——不要编造提升百分比。

---

8. SQL 参考

如果用户提供了实际架构，请据此调整此模板。替换占位的表名和列名——不要交付用户无法运行的查询。

-- Retention cohort query
-- Replace: users, events, created_at, event_date, user_id, event_type, [start_date], [key_retention_event]
SELECT
  DATE_TRUNC('month', u.created_at)    AS cohort_month,
  DATE_TRUNC('month', e.event_date)    AS activity_month,
  DATEDIFF('month', u.created_at, e.event_date) AS period,
  COUNT(DISTINCT e.user_id)            AS retained_users,
  COUNT(DISTINCT c.user_id)            AS cohort_size,
  ROUND(
    COUNT(DISTINCT e.user_id) * 100.0
    / NULLIF(COUNT(DISTINCT c.user_id), 0), 1
  )                                    AS retention_rate
FROM users u
JOIN (
  SELECT user_id, DATE_TRUNC('month', created_at) AS cohort_month
  FROM users
  WHERE created_at >= '[start_date]'
) c ON u.user_id = c.user_id
   AND DATE_TRUNC('month', u.created_at) = c.cohort_month
JOIN events e
  ON u.user_id = e.user_id
 AND e.event_type = '[key_retention_event]'
GROUP BY 1, 2, 3
ORDER BY 1, 3;

**适配你的技术栈：**BigQuery 使用 DATE_DIFF；Redshift 使用 DATEDIFF；Snowflake 使用 DATEDIFF 或 TIMESTAMPDIFF。运行前请确认方言。

---

评分标准（0–40）

交付前为本技能生成的任何输出评分；达到 32 分及以上即可交付。

维度	0	5	10
队列定义严谨性	边界含糊；同一用户可能属于两个队列	队列互斥，但进入事件缺乏充分依据	进入事件和日期边界明确无歧义，并说明该定义的权衡
平台期与时间窗口的准确性	根据过短、无法支持结论的时间窗口读取留存率	声称出现平台期，却未说明其位置	平台期清晰可见且已确定，或明确指出时间窗口过短、无法确认平台期
LTV 依据	LTV 基于假设的留存率或 ARPU	使用了观测数据，但未说明预测方法	LTV 基于观测到的留存率 × 观测到的 ARPU 构建，并说明预测方法和衰减假设
趋势与领先指标的价值	仅描述队列，未作对比	展示了队列间趋势，但未提供指标	正确解读不同获客时期的趋势，并结合行为领先指标识别流失

质量检查

交付前运行所有检查。只有在根据提供的数据可以验证为真时，才将检查标记为通过。

• **互斥性：**没有用户会出现在两个队列中——进入事件和日期边界明确无歧义
• **留存平台期：**曲线显示出清晰的平台期，或分析明确指出时间窗口过短、无法确认平台期
• **LTV 依据：**LTV 预测使用观测到的留存率和 ARPU——而非假设值
• **行为细分群体：**彼此互斥且完整穷尽——范围内的每位用户都恰好属于一个细分群体
• **队列最小规模：**低于可靠性阈值的队列均已标记，且未用于趋势结论
• **流失信号：**列出的所有领先指标都能从生产数据中观测到，或明确标记为假设
• **建议有据可依：**每条建议都引用具体发现——没有缺乏依据的增长建议
• **SQL 已适配：**如果用户提供了架构，查询使用其实际表名和列名

---

反模式

避免以下失败模式——它们会产出看似严谨、实则不可信或无法据此采取行动的分析。

反模式	失败原因	正确做法
群组成员资格重叠	无法比较不同群组的留存数据	定义单一、明确的进入事件；每位用户只属于一个群组
在 LTV 预测中假定 ARPU	掩盖细分群体的差异；得出的数字看似精确，实则并非如此	使用按细分群体拆分的、每位留存用户在每个周期产生的实际收入
根据样本量不足的群组得出结论	随机波动会被误认为信号	标明群组的最低样本量；排除低于阈值的群组，或注明相关限制
将登录与留存混为一谈	用户登录但未完成关键事件，按定义并不算留存	留存 = 完成所定义的关键留存事件，而非产生会话
编造提升幅度估算	缺乏数据依据的影响预测会误导优先级决策	如果无法根据数据估算影响，就如实说明并建议进行测试
泛泛而谈的建议	适用于任何 SaaS 产品的建议没有分析价值	每条建议都必须提及具体群组、细分群体或信号发现

---

触发短语

以下短语可触发此技能：

• “为 [product] 进行群组分析”
• “按获客月份分析留存率”
• “来自 [channel] 与 [channel] 的用户 LTV 是多少？”
• “根据以下内容构建群组留存模型