05｜Data Requirement Clarification Playbook
用途：需求澄清页面的 source of truth。
目标：不是“教数据分析基础”，而是把一次模糊的数据需求压成一个可回答、可计算、可决策的分析问题。
适用：资深数据分析师的日常需求澄清、临时分析、PLG / 产品分析、实验、指标诊断。
1. 核心原则：Clarify the Decision, not the Data Request
业务方常说：
- 帮我看看最近转化为什么掉了
- 看一下 retention
- 做个渠道分析
- 拉一下这个数
- 看看这个功能有没有效果
这些都还不是完整分析需求。
数据分析师第一问应该靠近：
这个分析结果最终要支持什么决策？
例如“渠道分析”：
如果要决定砍预算
需要追：
Spend / Traffic
→ ICP
→ Activation
→ Retention
→ Paid / Revenue
如果要决定优化 landing page
更关注：
Traffic Intent
→ Landing
→ Signup / Activation
同样叫“渠道分析”，方法完全不同。
2. 把模糊需求改写成一句 Analysis Question
推荐格式：
我们要判断 [现象] 主要来自 [候选机制 A] 还是 [候选机制 B]，以决定 [Action A] 还是 [Action B]。
例如：
原始：
为什么 retention 下降？
改写：
判断 8 月 D30 retention 下滑主要来自 acquisition mix 变化，还是同类 activated users 的 post-value retention 恶化，以决定优先修 Acquisition 还是 Product Retention。
这句话已经包含：
- Outcome
- Comparison
- Hypotheses
- Decision
3. 需求澄清的 10 个核心对象
不是每次都问 10 道题，而是确保关键项最终明确。
3.1 Business Context
- 为什么现在问？
- 什么现象触发？
- 最近有什么变化？
3.2 Decision
- 这个分析支持什么决策？
- 谁拍板？
- 不同结果会触发什么动作？
3.3 Analysis Question
- 最终一句话到底要回答什么？
- 是描述、诊断、预测还是因果验证？
3.4 Grain
- User？
- Workspace？
- Account？
- Logo？
- Revenue？
3.5 Population
- 包含谁？
- 排除谁？
- ICP / Non-ICP？
- Self-serve / Sales-assisted？
3.6 Metric Contract
- Numerator
- Denominator
- Window
- Anchor
- Eligibility
- Exclusions
3.7 Comparison
- 与谁比？
- 上月 / 同期 / control / cohort / segment？
- 基准是否公平？
3.8 Segmentation
- 哪些切分真的可能改变业务机制？
- Must-have vs Exploratory
3.9 Data Feasibility
- 数据存在吗？
- 埋点什么时候开始？
- ID 能 join 吗？
- 口径可信度如何？
- 缺什么 proxy？
3.10 Deliverable
- One-off analysis？
- Dashboard？
- Dataset？
- Experiment readout？
- Decision memo？
- 需要多深？
4. Only Ask Materially-Changing Questions
不是把 checklist 逐条念给 stakeholder。
规则：
已知的，不问
上下文已经明确，不重复。
不影响分析框架的，不问
缺失后不会改变方法或结论，就先不打断。
可以安全假设的，声明后继续
例如：
“我先按 activation-based cohort 理解；如果你们内部口径不同我再切。”
只有 materially change analysis 的缺失信息，才值得问
例如：
- Grain 不清会导致完全不同结果
- 指标口径不清
- Decision 不清
- Sales-assisted 是否包含
- Cohort maturity 不够
5. 2–3 Question Rule
在很多即时业务场景里，第一轮只问最重要的 2–3 个问题。
例如：
“帮我看最近转化为什么掉了。”
第一轮可以只问：
- 这里的“转化”指 Signup→Paid 还是 Activated→Paid？
- 这次结果最后要决定优先修 Acquisition、Activation 还是 Paywall / Pricing 吗？
- 最近有没有渠道 / pricing / sales route 的明显变化？
足够开始建立分析框架。
不要一次发 15 个问题。
6. Decision-first 的好问法
避免：
“你想看什么数据？”
更好：
“这个结果出来以后，你最可能要决定什么？”
避免：
“需要切哪些维度？”
更好：
“目前最怀疑哪些人群或渠道遵循不同机制？”
避免：
“数据范围多久？”
更好：
“你希望比较哪批 cohort？D30 是否都已经成熟？”
7. 问“为什么现在”
这是很有信息密度的一问：
是什么现象触发了这次分析？
可能得到：
- Dashboard 下降
- 新功能上线
- Sales 反馈用户质量变差
- 新增投放
- Pricing 改版
- CEO 要做预算
它直接帮助形成：
- hypothesis
- comparison
- confounders
- urgency
8. 让 Stakeholder 暴露当前 Hypothesis
不要让它变成“你觉得是什么原因？”的甩锅感。
更自然：
“你现在最怀疑哪几类原因？最近产品、渠道、价格、销售流程有没有什么变化？”
这可以快速得到高价值搜索空间。
注意：
Stakeholder hypothesis 是 search prior，不是结论。
9. Grain Clarification：一句话能救很多分析
业务说：
客户留存下降。
追：
“这里我们按 user、logo 还是 revenue retention 看？”
因为可能：
User Retention ↓
Logo Retention 稳
NRR ↑
同时成立。
10. Metric Contract
推荐每个关键指标形成小型 Contract：
Metric Name:
Business Meaning:
Grain:
Numerator:
Denominator:
Anchor:
Window:
Eligibility:
Exclusions:
Source:
Known Caveats:
例如：
True Activation Rate
Business Meaning: 用户在首次使用阶段真实拿到核心价值
Grain: User
Numerator: 注册后 7 天内成功完成核心任务并导出结果
Denominator: eligible ICP self-serve signups
Anchor: Signup
Window: 7 days
Exclusions: employee / test / sales-sourced
11. Comparison Contract
一个数字不比较，通常很难解释。
先确认：
- vs Previous Period
- vs Same Season
- vs Control
- vs Non-activated
- vs ICP / Non-ICP
- vs Channel
- vs Plan
同时检查：
- 时间窗是否一样
- cohort 是否成熟
- segment mix 是否一样
- 定义有没有变
12. 时间澄清不是只问“看多久”
至少分：
Calendar Range
Jul–Aug。
Cohort Window
Jul signup / activation cohort。
Outcome Maturity
D30 是否已经成熟？
Natural Frequency
Daily / Weekly / Monthly？
常见坑：
当月刚过一半，就比较“本月 D30”。
13. Segmentation Scope
Stakeholder 说：
国家、渠道、行业、设备都拆一下。
不要机械全接。
先问：
哪些切分在业务机制上最可能改变结果？
优先：
- ICP
- Channel
- Use Case
- Plan
- Account Size
- Sales-assisted / Self-serve
建立：
Must-have Segments
直接服务 hypothesis。
Exploratory Segments
主分析后再看。
14. Data Feasibility Check
需求澄清结束后尽快检查：
- event 存在吗
- 历史多久
- tracking 版本有没有变
- account mapping 完整吗
- attribution 能做吗
- sales-assisted flag 有吗
- pricing history 有吗
如果缺失：
不要装作有证据。
改成：
- 使用 proxy
- 降低 confidence
- 调整分析问题
- 补埋点 / 数据需求
15. Monitoring / Diagnosis / Causal Validation 要先分清
Monitoring
发生了什么？
工具：
- Dashboard
- KPI report
Diagnosis
为什么发生？
工具：
- Funnel
- Cohort
- Segment
- Decomposition
Causal Validation
改 X 会不会导致 Y？
工具：
- Experiment
很多“看看这个功能有没有效果”其实是因果问题。
如果只有前后数据：
只能给 observational evidence，不要包装成 A/B 结论。
16. Decision Boundary：什么结果会改变动作
这是非常值得做的一步。
问：
If the answer is X, what will we do? If Y, what will we do?
例如：
X
Paid channel 的 Activated Retention 明显低于 SEO。
Action：
修 targeting / acquisition quality。
Y
所有渠道内部都下降。
Action：
查 product retention mechanism。
如果无论结果是什么，stakeholder 都不会改变行动：
这个分析需求可能没有真正决策价值。
17. Deliverable Scope
确认：
- 一个数字？
- 一个表？
- 一张 Funnel？
- 一页结论？
- 一个完整 report？
- Dashboard？
- SQL dataset？
- 长期 monitoring？
以及：
One-off vs Productionized。
工程量完全不同。
18. Accuracy vs Speed
可以显式分：
Directional
快速、带假设、回答方向。
Decision-grade
清洗、比较、敏感性分析、confidence 更严格。
Productionized
长期 KPI / Dashboard / Semantic Definition。
不是每个需求都做成博士论文。
19. Requirement Contract
澄清后，内部或对外形成：
Business Decision:
最终要决定什么？
Analysis Question:
具体回答什么？
Trigger / Context:
为什么现在问？
Primary Outcome:
核心结果指标是什么？
Population / Grain:
分析谁？
Metric Definition:
分子 / 分母 / Window / Anchor / Eligibility
Comparison:
Baseline / Control / Cohort / Segment
Core Hypotheses:
目前有哪些可能解释？
Key Segments:
哪些人群可能不同机制？
Data Constraints:
缺什么？什么 proxy？
Decision Boundary:
什么结果对应什么动作？
Deliverable:
最终交付什么？
Deadline / Confidence Bar:
需要 directional 还是 decision-grade？
20. 一个完整澄清例子
原始：
帮我分析最近 PLG 转化为什么变差。
澄清后：
目标：
判断 8 月 Signup→Paid 从 4.2% 降至 3.1% 的主要原因，
是 acquisition mix、activation deterioration，
还是 monetization efficiency 下降，
以决定下一轮优先修 Acquisition、Activation 还是 Paywall。
Population：
7–8 月 self-serve ICP signups，
排除员工、test account、sales-sourced。
Grain：
User；商业结果辅助看 Account。
Path：
Signup → True Activation → D30 Retained → PQL → Paid。
Segments：
Channel / ICP type / Account size。
Comparison：
July vs August mature cohorts。
Output：
Driver decomposition + priority recommendation。
不需要长期 dashboard。
这时已经可以开工。
21. Bad vs Better：常见需求澄清
Bad
“你要看哪些维度？”
Better
“目前最怀疑哪些人群遵循不同转化机制？我先只切会改变决策的维度。”
Bad
“Retention 是哪个口径？”
Better
“我先确认一下：这次是看 signup-based 还是 activation-based retention？如果是判断产品价值，我倾向后者。”
Bad
“要多长时间范围？”
Better
“你希望比较最近两批 mature cohort，还是看长期趋势？D30 的话最近一批是否已经成熟？”
Bad
“你觉得原因是什么？”
Better
“最近有没有渠道、价格、产品或 Sales route 的变化？我先把最可能的机制列成 hypothesis。”
22. 需求澄清结束前的 30 秒检查
问自己：
- 我知道最终 Decision 吗？
- 我能用一句话写 Analysis Question 吗？
- Grain / Population 明确吗？
- Metric Contract 清楚吗？
- Comparison 公平吗？
- Cohort 成熟吗？
- 关键 Segments 有边界吗？
- 数据能做吗？
- 什么结果会改变行动？
- 输出和 deadline 明确吗？
如果大部分明确：
开始分析。
不要继续为了“完整”而澄清。
23. 一句话总纲
数据分析师做需求澄清，不是问清对方想要什么数据，而是问清对方要做什么决策，以及什么证据足以改变这个决策。