第1章 数据产品需求分析概述
1.1 数据产品与传统产品的本质差异
数据产品的“产品化”对象是数据与算法，而非界面与流程。传统产品交付的是功能闭环，数据产品交付的是决策价值。理解这一差异是PRD编写的前提。
| 对比维度 | 传统产品 | 数据产品 |
|---|---|---|
| 核心产出 | 操作界面、业务逻辑 | 数据指标、分析模型、可视化 |
| 用户动作 | 点击、填写、提交 | 查看、筛选、下钻、解读 |
| 质量衡量 | 可用性、稳定性 | 数据准确率、响应速度、可解释性 |
| 需求变化 | 功能迭代 | 指标口径调整、维度扩展 |
| 验收难点 | 是否满足操作流程 | 是否反映业务真实状态 |
1.2 数据产品三大特点
- 强依赖数据资产：没有高质量、可追溯的数据源，产品等于空壳。需前置调研数据仓库、埋点规范、离线/实时链路。
- 决策闭环特性：用户不是“使用”产品，而是“信任”产品。需求分析必须覆盖 采集→计算→呈现→行动→反馈 全链路。
- 度量先行：每个需求都对应可量化的业务目标（如转化率提升0.5%），PRD必须包含明确的成功指标。
1.3 需求本质：从业务问题到数据指标
数据产品需求的本质是 “将模糊的业务问题转化为可计算的数据指标，再用产品形态交付给决策者”。典型转化过程：
- 业务痛点 → “为什么销售额连续两周下滑？”
- 拆解维度 → 按渠道、品类、区域逐层下钻
- 指标定义 → 日销售额、同比、环比、渠道占比
- 产品形态 → 趋势折线图 + 下钻表格 + 异常预警
关键认知：数据产品的PRD不是“功能说明书”，而是“度量-分析-行动”契约。需求分析阶段就要明确：谁（用户场景）、在什么情况下（业务问题）、需要什么数据（指标）、怎么用（交互方式）、怎么验证（验收标准）。
1.4 PRD在数据产品中的定位
PRD是连接业务、数据、开发、测试的唯一共识文档。在数据产品中，PRD需要额外承载：数据口径定义、异常值处理逻辑、权限粒度说明、SLA承诺。下图概括了数据产品需求分析全流程中PRD的输入与输出关系。
实战提示：在访谈业务方时，直接问“您希望看到什么数据？”往往得不到准确答案。改用“当您发现数据异常时，第一步会做什么操作？”才能挖掘出真正的场景。这份需求分析框架就是帮你从模糊到具体的一把剪刀。
1.5 PRD交付物模板预览
后续章节会展开每个模块的编写方法，先给出数据产品PRD的标准章节结构，形成全景印象：
1. 版本记录与审批
2. 业务背景 & 用户场景
3. 需求描述（包含数据口径、维度、粒度）
4. 原型设计（标注重点交互）
5. 指标定义 & 成功标准
6. 数据依赖 & 异常处理
7. 验收用例 & SLA要求
8. 风险与备注本章为全流程概述，后续29章将逐一拆解每个环节的编写技巧与避坑指南。