1. 数据产品PRD到底难在哪先搞清楚它和普通PRD的本质区别干了这么多年数据产品我最大的感受是数据产品的PRD和功能型产品的PRD压根就不是一个物种。很多从功能产品转过来的朋友拿着写增删改查那套模板去写数据产品需求文档最后要么被研发怼回来要么上线后发现数据口径全错返工成本高得吓人。普通功能型PRD的核心是“用户点了什么按钮系统给出什么反馈”逻辑是确定的、可穷举的。但数据产品的PRD核心是“这个指标怎么算、数据从哪来、口径怎么统一、异常怎么兜底”。你写“用户点击查询按钮展示近30天销售额”研发看完第一反应是哪个销售额含不含退款含不含税下单口径还是支付口径时间字段用哪个时区怎么处理——这些问题不写清楚代码写出来就是错的。所以数据产品PRD的本质是一份数据契约。它不只是给研发看的还是给数据分析师、数据开发、测试、甚至业务方对齐认知用的。一份合格的数据产品PRD应该让一个完全没参与过需求讨论的数据开发看完之后能独立把数据链路搭出来而且口径和业务方理解的一致。这篇文章我结合自己踩过的坑和带团队的经验把数据产品PRD的写法拆透。适合三类人看一是刚转数据产品的新人二是被数据需求折磨过的研发和数仓同学三是想规范团队需求流程的产品负责人。我会给出一套可直接套用的模板结构再重点讲5个最容易翻车的避坑点每个都配真实场景和排查方法。2. 数据产品PRD的整体框架设计从“给谁看”倒推“写什么”2.1 先明确读者角色再决定文档结构很多人写PRD是打开模板就填填完发现研发问的问题文档里全没写。问题出在你没有从读者视角倒推内容。数据产品PRD的读者至少有四类每类人关注的点完全不同。数据开发/数仓工程师关注数据源、表结构、ETL逻辑、调度依赖、口径计算、异常处理。他们需要的是“可执行的规格说明”。前端/后端研发关注接口字段、交互逻辑、筛选条件、分页、权限、性能要求。他们需要的是“可实现的接口契约”。测试工程师关注边界条件、数据准确性验证方法、异常场景、回归范围。他们需要的是“可验证的验收标准”。业务方/运营关注指标定义、展示形式、更新频率、使用场景。他们需要的是“可确认的口径说明”。所以一份数据产品PRD的结构应该让这四类人都能快速找到自己关心的部分。我的做法是文档前半部分写业务背景和口径定义业务方和产品看中间写数据逻辑和表设计数据开发看后半部分写接口和交互前后端看最后附验收标准和异常处理测试看。2.2 一套可直接套用的PRD模板骨架下面这套结构是我在多个数据产品项目中迭代出来的覆盖了从需求背景到上线验收的完整链路。你可以直接拿去改。第一部分需求概述需求背景与业务价值为什么做不做会怎样目标用户与使用场景谁用什么场景下用核心指标与成功标准怎么衡量做得好第二部分数据口径定义指标字典每个指标的名称、口径、计算公式、时间维度、过滤条件维度定义维度名称、枚举值、层级关系、默认值数据来源与血缘源表、中间表、目标表、更新频率第三部分功能需求详述功能模块清单与优先级每个功能的交互逻辑、筛选条件、展示形式权限与角色控制第四部分数据逻辑与表设计源数据说明表名、字段、分区、更新策略ETL处理逻辑清洗、关联、聚合、去重规则目标表结构字段名、类型、含义、是否可空调度依赖与SLA第五部分接口设计接口清单与请求/响应字段分页、排序、筛选参数错误码与异常返回第六部分非功能需求性能要求响应时间、并发量、数据量级数据安全与权限监控与告警第七部分验收标准与测试要点功能验收清单数据准确性验证方法边界与异常场景第八部分上线计划与回滚方案上线步骤、灰度策略、回滚条件这套结构看起来长但实际写的时候很多部分是表格化的填起来并不慢。关键是每一部分都要写到研发不用追问就能动手的程度。2.3 为什么数据口径定义要放在最前面我见过太多PRD把口径定义藏在文档最后结果业务方看到原型图就确认了研发按自己的理解写了SQL上线后数据对不上三方扯皮。口径定义必须前置而且必须让业务方书面确认。举个真实例子我们做过一个“日活跃用户数”的指标。产品经理写的是“当天登录的用户数”。研发理解成“当天有登录行为的用户去重数”。业务方理解成“当天至少访问过一个页面的用户数”。三个理解三个结果差异能到20%以上。后来我们在PRD里把口径写成“统计日当天00:00:00至23:59:59内至少有一次有效页面浏览行为PV0的用户ID去重数排除内部测试账号时区为UTC8。”这才把三方拉齐。所以口径定义部分我建议用表格来写每个指标一行列包括指标名称、业务口径描述、计算公式、时间维度、过滤条件、数据来源、负责人。这样一目了然也方便后续维护。3. 核心细节解析数据产品PRD里必须写死的几个关键点3.1 指标口径别用“大概”“通常”这种词写数据产品PRD最忌讳的就是模糊表述。什么叫“近期”什么叫“活跃”什么叫“有效”这些词在业务方嘴里是感性的但在数据开发眼里是必须量化的。我要求团队写PRD时口径描述必须满足三个条件可量化、可复现、可验证。可量化是指所有条件都有明确数值或枚举可复现是指换一个人按这个描述写SQL结果一致可验证是指测试能构造数据验证结果对不对。比如“高价值用户”这个指标不能只写“消费金额较高的用户”。要写成“统计周期内自然月累计支付金额≥1000元且支付订单数≥3笔且退款率≤10%的用户。”这样研发才能写代码测试才能造数据。还有一个容易忽略的点时间维度的边界。是自然日还是滚动24小时是包含当天还是截止昨天跨时区怎么处理这些不写清楚数据每天对不上。我们的做法是在PRD里专门加一节“时间口径说明”把所有涉及时间的指标统一约定。3.2 数据来源与血缘写清楚“从哪来、到哪去”数据产品的数据不是凭空产生的它依赖上游的源表、中间表。PRD里必须写清楚每个指标的数据来源包括源表名、字段名、分区字段、更新频率。我见过一个坑产品经理写“用户订单数据来自订单表”但订单表有三个——订单主表、订单明细表、订单扩展表。研发选了订单主表结果发现金额字段在明细表里又得返工。所以PRD里要精确到“库名.表名.字段名”。另外血缘关系也要写。比如“目标表A依赖中间表B中间表B依赖源表C和DC每天凌晨2点更新D每小时更新”。这样调度依赖才能配对不会出现上游还没跑完下游就开始跑的情况。3.3 ETL逻辑清洗、关联、聚合的规则要写死ETL是数据产品的核心加工环节也是最容易出bug的地方。PRD里要把清洗规则、关联规则、聚合规则写清楚。清洗规则包括空值怎么处理异常值怎么过滤重复数据怎么去重比如“用户ID为空的数据直接丢弃”“金额为负数的记录标记为异常并排除”“同一订单号多条记录取最新更新时间的那条”。关联规则包括用什么字段关联关联类型是inner join还是left join关联不上怎么处理比如“订单表和用户表通过user_id关联采用left join关联不上的用户归入‘未知用户’维度”。聚合规则包括按什么维度聚合聚合函数是什么是否去重比如“按日期和商品类目聚合销售额用sum订单数用count distinct order_id”。这些规则不写清楚研发只能猜猜错了就是数据事故。3.4 异常处理与兜底方案数据产品必须考虑“数据没了怎么办”功能型产品怕的是报错数据产品怕的是数据不准或数据缺失。PRD里必须写清楚异常场景的处理方案。常见异常场景包括上游数据延迟、上游数据缺失、数据量突增突降、指标计算结果为负或超出合理范围。每个场景都要有对应的兜底方案。比如“上游数据延迟超过1小时页面展示上一次成功计算的结果并标注‘数据更新延迟’”“指标计算结果环比波动超过50%触发告警并暂停自动刷新”。这些内容不写上线后数据一波动业务方就来问研发就得临时查非常被动。4. 实操过程从零写一份数据产品PRD的完整步骤4.1 第一步需求调研与口径对齐写PRD之前先做需求调研。调研对象包括业务方、数据分析师、数据开发。业务方讲场景和痛点分析师讲现有口径和数据问题数据开发讲技术可行性和成本。调研的核心产出是口径对齐纪要。把业务方嘴里的“活跃用户”“高价值客户”“有效订单”全部翻译成可量化的定义让业务方确认。这一步不做后面全是坑。我通常会用一张“指标澄清表”来推进对齐列出业务方原始表述、待澄清问题、建议口径、业务方确认结果。比如业务方说“我要看每天的活跃用户”澄清问题包括活跃的定义是什么登录算不算浏览算不算时间范围是自然日还是滚动24小时确认后写成正式口径。4.2 第二步数据探查与可行性验证口径对齐后别急着写PRD先让数据开发做数据探查。探查内容包括源表有没有数据数据量多大字段是否完整更新频率是否满足有没有脏数据这一步的目的是验证需求能不能实现。我遇到过业务方要“实时看每个用户的累计消费金额”探查后发现订单表是T1更新根本做不到实时。如果PRD写完才发现返工成本就大了。数据探查的产出是一份“数据可行性说明”附在PRD后面说明每个指标的数据来源是否可靠、有没有已知问题、需要做什么预处理。4.3 第三步PRD撰写与评审调研和探查完成后开始写PRD。我建议按第2节给的模板结构来写重点把口径定义、数据逻辑、接口设计三部分写详细。写完后要组织评审。评审参与人包括业务方、数据分析师、数据开发、前后端研发、测试。评审的重点不是看文档格式而是逐条确认口径和逻辑。每个指标过一遍口径对不对数据源对不对计算逻辑对不对异常处理对不对评审要留会议纪要把确认结果和待办事项记下来。评审通过后PRD才能进入开发排期。4.4 第四步开发跟进与验收PRD评审通过不代表产品经理就没事了。开发过程中研发会有各种疑问产品经理要及时解答。同时要跟进开发进度确保按PRD实现。验收阶段产品经理要联合测试做数据准确性验证。验证方法包括与现有报表对比、与业务方手工核算对比、构造边界数据测试。验证通过后才能上线。上线后还要做数据监控。监控指标包括数据更新是否及时、数据量是否正常、指标波动是否合理。发现异常及时排查。5. 五个避坑点每个都是血泪教训5.1 避坑点一口径不写死上线后扯皮这是数据产品PRD第一大坑。口径模糊导致业务方、产品、研发三方理解不一致上线后数据对不上互相甩锅。避坑方法所有指标口径必须量化、可复现、可验证。口径定义要业务方书面确认。PRD里加一节“口径变更记录”后续任何口径调整都要记录在案。我自己的习惯是每个指标后面都加一个“口径负责人”字段明确谁对这个口径负责。口径有争议时找负责人拍板。5.2 避坑点二忽略数据血缘调度依赖配错数据产品依赖上游表上游表的更新时间和依赖关系如果不写清楚调度就会出问题。我见过下游任务比上游任务先跑结果每天数据都是空的。避坑方法PRD里画出血缘关系图用文字或表格描述标明每个表的更新时间和依赖关系。调度配置要写进PRD包括依赖的上游任务、超时时间、重试策略。5.3 避坑点三异常场景没兜底数据一波动就崩数据产品最怕数据异常。上游数据延迟、数据量突增突降、指标计算结果异常这些场景不处理页面直接展示错误数据业务方就会质疑产品可靠性。避坑方法PRD里列出所有可能的异常场景每个场景给出兜底方案。比如数据延迟展示旧数据并标注、数据波动超阈值触发告警、数据缺失展示“暂无数据”而不是0。5.4 避坑点四接口字段不明确前后端联调返工数据产品的接口字段往往比较多如果PRD里不写清楚字段名、类型、含义、是否可空前后端联调时就会反复改。避坑方法PRD里用表格列出所有接口字段包括字段名、类型、含义、示例值、是否必填。接口的请求参数和响应结构都要写清楚。最好附上JSON示例。5.5 避坑点五验收标准模糊测试不知道测什么数据产品的测试和功能产品不一样不是点一点看报不报错而是要验证数据准确性。如果PRD里不写验收标准测试只能测功能通不通测不了数据对不对。避坑方法PRD里写清楚每个指标的验收标准包括预期结果、验证方法、边界条件。比如“日活跃用户数验证方法为取某日数据与业务方手工核算结果对比误差不超过0.1%”。6. 常见问题与排查技巧实录6.1 数据对不上时怎么快速定位问题数据对不上是数据产品最常见的问题。排查思路是从下游往上游逐层排查。先看目标表数据对不对如果不对看中间表中间表不对看源表源表不对看上游系统。每一层对比数据量和关键字段定位差异出现在哪一层。常见原因包括口径理解不一致、过滤条件不同、关联方式不同、去重逻辑不同、时间边界不同。排查时要把这些因素逐一排除。我通常会做一个“数据比对表”列出每个环节的数据量、关键指标值、差异原因。这样排查起来有据可依。6.2 上游数据延迟怎么保证页面可用上游数据延迟是常态不能因为延迟就不展示数据。兜底方案是展示上一次成功计算的结果并标注数据更新时间。如果延迟超过阈值触发告警通知数据开发。PRD里要写清楚延迟的判断逻辑和展示文案。比如“如果当前时间超过预期更新时间1小时页面展示‘数据更新延迟当前展示为XX时间数据’”。6.3 指标波动异常怎么判断是业务变化还是数据问题指标波动异常时先判断是业务真实变化还是数据问题。方法包括对比多个相关指标、查看明细数据、与业务方确认。如果多个相关指标同时波动可能是业务变化如果单个指标波动且明细数据异常可能是数据问题。数据问题的常见原因包括上游数据重复、过滤条件失效、关联丢失。PRD里可以约定波动告警阈值比如“日环比波动超过30%触发告警”这样能及时发现异常。6.4 需求变更频繁怎么管理口径版本数据产品的口径不是一成不变的业务调整、数据源变化都会导致口径变更。如果没有版本管理新旧口径混用数据就乱了。避坑方法PRD里加“口径版本记录”每次口径变更都记录变更时间、变更内容、变更原因、影响范围。目标表可以加版本字段区分不同口径的数据。我自己的做法是口径变更必须走评审业务方、产品、研发、分析师都确认后才能改。变更后要通知所有下游使用方。6.5 常见问题速查表问题现象可能原因排查方法解决方案数据为空上游未更新、调度失败、过滤条件过严检查上游任务状态、查看调度日志、放宽过滤条件测试修复上游、重跑调度、调整过滤条件数据重复关联方式错误、去重逻辑缺失检查join字段、查看明细数据调整join方式、增加去重逻辑数据偏大过滤条件失效、重复计算对比源表和目标表数据量修复过滤条件、检查聚合逻辑数据偏小关联丢失、过滤过严检查join类型、查看关联不上的数据调整join类型、放宽过滤条件指标波动异常业务变化、数据问题对比相关指标、查看明细确认业务原因或修复数据问题页面加载慢数据量过大、查询未优化查看查询耗时、检查索引优化查询、增加缓存、分页加载7. 我个人的实操心得与建议写了这么多最后分享几个我自己的习惯都是踩坑踩出来的。第一PRD不是写完就完了要当成活文档维护。口径变更、逻辑调整、异常处理补充都要及时更新到PRD里。我见过太多团队PRD写完就扔后面全靠口口相传新人接手一脸懵。第二口径定义要让业务方签字确认。不是不信任业务方而是口头确认和书面确认是两回事。书面确认后后续有争议时有据可依。第三数据产品PRD要配数据探查报告。光写需求不写数据可行性研发做不了。探查报告说明数据从哪来、质量如何、有什么坑研发看了心里有底。第四验收标准要可执行。不要写“数据准确”这种虚的要写“与XX报表对比误差不超过0.1%”这种可执行的。测试才能照着验。第五异常处理要前置。不要等上线后出问题了再补PRD阶段就要把所有异常场景列出来给出兜底方案。这样上线后数据波动系统能自动处理不用人工介入。数据产品PRD的写法没有绝对标准但核心逻辑是一致的把数据口径写死把数据逻辑写清把异常场景写全。做到这三点研发不返工测试有依据业务方不扯皮项目就能顺利推进。