数据产品经理和功能产品经理写出来的PRD经常是两种完全不同的东西。功能PRD可以围绕页面跳转、按钮交互、字段校验来写读者是前端、后端和测试大家对着原型图就能对齐。但数据产品的PRD如果还按这个套路写交付当天就会出问题——研发问你指标口径是什么你写的是“按业务需求统计”测试问你数据什么时候能查到你写的是“T1更新”下游用数的人问你为什么昨天的数字和今天看到的不一样你只能说“我确认一下”。这类返工我见过太多次根子几乎都埋在PRD阶段。这篇内容面向的是正在做或准备转做数据产品的同学尤其是需要独立输出数据需求文档、数据看板需求、指标平台需求、数据服务接口需求的人。我会把一份能真正落地、能减少扯皮的数据产品PRD拆开讲清楚它和功能PRD的本质差异在哪、一份完整模板应该包含哪些模块、每个模块里哪些字段是必须写死的、以及我在实际项目里反复踩到的五个坑。全文不空谈方法论重点放在“你打开文档该敲哪些字”这个层面。1. 数据产品PRD和功能PRD到底差在哪很多人写数据PRD写不好不是因为不会写文档而是因为脑子里还在用功能PRD的框架。功能PRD的核心是“用户操作后系统如何响应”数据PRD的核心是“数据从哪来、怎么算、给谁看、什么时候更新”。这两件事的验收标准完全不同。1.1 功能PRD验收的是交互数据PRD验收的是数字功能需求上线后测试点的是按钮能不能点、跳转对不对、异常提示有没有。数据需求上线后测试点的是这个指标算出来是不是等于业务方手工算的那张Excel。这意味着数据PRD里必须包含可验证的数值样例而不是只描述逻辑。我习惯在PRD里直接放一张“口径验证表”列出至少三组样本数据写明输入是什么、预期输出是多少。比如做订单履约率看板我会写某天创建订单100单其中95单在承诺时间内完成履约率95/10095%。研发和测试拿到这个样例就能自己反推逻辑对不对而不是上线后靠业务方肉眼发现数字不对。1.2 数据PRD的读者比功能PRD多一类人功能PRD的读者主要是研发、测试、UI。数据PRD的读者除了这三类还多了数据分析师、下游用数团队、甚至算法团队。不同角色关注的点完全不一样研发关注数据源和计算逻辑分析师关注维度和指标定义下游关注输出格式和更新时效。这就导致数据PRD不能只写一份给所有人看最好在文档开头就明确“本文档面向哪些角色各角色重点关注哪些章节”。我在实际项目里会在PRD第一页放一个读者指引表把研发、测试、分析师、下游分别对应到具体章节减少沟通成本。1.3 数据需求变更成本远高于功能需求功能需求改一个按钮位置前端改几行代码就完事。数据需求改一个指标口径可能意味着整条数据链路重跑、历史数据回刷、下游报表全部对不上。所以数据PRD在口径定义上必须做到“一次写死后续变更走正式流程”。我的做法是在PRD里单独设一个“口径变更记录”章节任何口径调整都要记录变更时间、变更原因、影响范围、是否需要回刷历史数据。这个章节在项目初期可能是空的但它的存在本身就是一种约束提醒所有人口径不是随便改的。2. 一份能落地的数据产品PRD模板长什么样下面这份模板是我在多个数据产品项目中沉淀下来的覆盖了从背景到验收的完整链路。你可以直接拿去改但要注意每个模块里的“必填项”不能省省了后面一定出问题。2.1 文档信息与变更记录这个模块看起来是形式主义但实际项目里非常有用。至少包含文档版本、创建日期、最后更新日期、作者、评审人、变更摘要。变更摘要要写清楚每次改了什么而不是只写“更新”。我见过一个项目因为没写变更记录上线后发现指标口径和三个月前评审时不一致但没人记得是谁改的、为什么改。最后只能全部重算浪费了两周时间。所以这个模块不是给领导看的是给未来的自己看的。2.2 业务背景与目标这部分要回答三个问题为什么要做这个数据产品、它解决什么业务问题、成功标准是什么。注意成功标准必须是可量化的不能写“提升业务决策效率”这种虚的。比如做供应链履约看板成功标准可以写业务方从提出数据需求到拿到结果的时间从3天缩短到10分钟履约异常发现时间从T3提前到T1。这种标准在项目结束后可以直接验证而不是靠感觉判断。2.3 数据范围与数据源这是数据PRD最核心的模块之一。必须写清楚数据来自哪些系统、通过什么方式接入、数据量级大概多少、有没有历史数据需要初始化。我习惯用一张表来呈现数据源接入方式更新频率数据量级备注订单系统数据库直连每日全量约500万行含历史3年数据物流系统消息队列实时日均10万条仅增量用户中心API接口每日增量日均1万条需处理接口限流这张表能让研发快速评估工作量也能让测试知道该准备多少测试数据。2.4 指标与维度定义这是最容易出问题的模块。每个指标必须包含指标名称、业务口径、技术口径、计算逻辑、维度、粒度、单位、精度、空值处理方式。我举一个实际例子。做“日活跃用户数”这个指标指标名称日活跃用户数DAU业务口径当日有任意一次有效行为的去重用户数技术口径在行为表中按用户ID去重筛选行为时间在当日00:00:00至23:59:59之间且行为类型属于有效行为集合维度日期、渠道、地区粒度日单位人精度整数空值处理当日无数据时展示为0不展示为空注意“有效行为集合”必须枚举清楚不能写“等有效行为”。我踩过这个坑当时写了“等”结果研发把浏览也算进去了DAU直接翻倍。2.5 数据输出与展示形式数据产品最终要输出给谁、以什么形式输出必须在PRD里写死。是看板、报表、API接口、还是数据文件输出频率是实时、T1、还是每周如果是API接口要写清楚接口地址、请求方式、请求参数、返回字段、返回示例、限流策略、鉴权方式。如果是看板要写清楚页面布局、筛选条件、默认展示维度、下钻逻辑、导出格式。我见过一个项目因为没写导出格式研发默认导出了CSV但业务方需要Excel带格式的上线后返工。这种问题在PRD阶段写一句话就能避免。2.6 数据质量与监控数据产品上线不是终点数据质量监控才是长期工作。PRD里要写清楚哪些字段不能为空、哪些指标有波动阈值、异常时通知谁、通知方式是什么。比如订单金额字段不允许为负日订单量波动超过30%触发告警告警通知到数据产品经理和企业微信值班群。这些规则写进PRD研发在开发阶段就会把监控逻辑一起做进去而不是上线后补。2.7 验收标准与测试用例验收标准要具体到可执行。我通常写给定某天数据指标A的计算结果等于手工计算结果接口响应时间小于500毫秒看板首屏加载时间小于3秒数据更新延迟不超过约定时间。测试用例要覆盖正常数据、空数据、异常数据、边界数据。比如日期边界、数值边界、维度组合边界。这些用例在PRD里写清楚测试同学可以直接拿去用不用再自己设计。3. 五个避坑点每一个我都真实踩过下面这五个坑是我在数据产品项目里反复遇到、反复踩、反复填的。每一个都对应着具体的返工场景写出来是希望你能跳过。3.1 口径写“按业务需求”等于没写这是最致命的坑。PRD里出现“按业务需求统计”“根据业务规则计算”这种话研发只能靠猜。猜对了是运气猜错了就是返工。正确做法是把业务需求翻译成技术语言。比如“按业务需求统计活跃用户”要写成“在用户行为表中筛选行为时间在统计周期内、行为类型属于[登录、下单、支付、分享]的用户ID去重计数”。每一个筛选条件、每一个枚举值都要写死。如果业务方自己也不确定口径那就先开口径对齐会把业务方、研发、分析师拉到一起当场确认。确认结果写进PRD所有人签字。不要怕麻烦口径对齐花两小时返工可能花两周。3.2 维度没枚举全上线后天天加字段维度是数据产品的骨架。PRD里如果只写“支持按渠道、地区筛选”研发可能只做了两个维度。上线后业务方说还要按版本、按用户等级、按支付方式筛选你就得一次次提需求、一次次改代码。我的做法是在PRD里列一张“维度清单”把所有可能用到的维度都列出来标注哪些是首期必须、哪些是二期规划。首期必须的维度做进去二期规划的维度在数据模型设计时预留字段。这样既不会首期工作量爆炸也不会后期频繁改表。维度清单示例维度名称维度类型首期必须二期规划备注日期时间是-支持日、周、月渠道枚举是-枚举值待确认地区层级是-省市区三级用户等级枚举否是预留字段支付方式枚举否是预留字段3.3 更新时效写“T1”但没写具体时间“T1更新”是一个模糊表述。是凌晨1点更新还是早上8点更新是数据全部更新完还是部分更新业务方早上9点打开看板看到的是昨天的数据还是前天的数据我现在的写法是数据更新时间窗口为每日02:00至06:0006:00后保证所有指标可查。如果某天数据延迟延迟超过1小时触发告警通知数据产品经理和值班研发。这样业务方知道什么时候来看数据研发知道什么时候必须跑完测试知道怎么验证时效。3.4 没写空值和异常处理上线后数据一片空白空值和异常处理是数据PRD里最容易被忽略的部分。比如某个维度下没有数据是展示0还是展示空某个指标计算出来是负数是展示负数还是截断为0某个数据源当天没更新是展示昨天数据还是展示空这些细节不写研发就按自己的理解处理。结果就是业务方看到看板上一片空白以为系统坏了其实是当天没数据。我的做法是在PRD里专门写一节“空值与异常处理规则”把所有可能的情况列出来逐条定义展示方式。3.5 验收标准写“数据准确”等于没标准“数据准确”不是验收标准因为无法验证。验收标准必须是可执行的测试用例。比如取2024年1月1日数据手工计算订单量为1000单系统展示为1000单取空数据日期系统展示为0取异常数据日期系统触发告警。我通常会在PRD里附一个“验收用例表”包含用例编号、测试场景、输入数据、预期结果、实际结果、是否通过。这个表在测试阶段直接填写项目结束时作为验收依据。4. 从PRD到落地评审和交付阶段的关键动作PRD写完只是第一步评审和交付阶段同样关键。很多问题不是PRD写错了而是评审没评到位、交付没交清楚。4.1 评审会怎么开才有效数据PRD的评审会不能只叫研发和测试必须叫上业务方、分析师、下游用数团队。评审的重点不是文档格式而是口径、维度、时效、输出形式这四件事。我习惯在评审会前把PRD发给参会人要求每个人把自己关心的部分标注出来。评审会上先过口径和维度再过时效和输出最后过验收标准。每个部分确认后当场记录结论会后更新PRD。评审会最容易出现的问题是业务方说“这个口径不对”但说不出哪里不对。这时候要追问你期望的口径是什么和现在写的差在哪能不能给一个具体例子把业务方的期望翻译成技术语言当场对齐。4.2 交付阶段要交什么数据产品交付不只是交代码还要交文档、交监控、交权限。我通常会在交付阶段确认以下事项数据字典是否更新所有指标、维度、字段的定义是否和PRD一致监控是否配置数据质量监控、时效监控、异常告警是否生效权限是否开通哪些角色可以看哪些数据权限申请流程是否明确使用文档是否编写业务方怎么用这个数据产品常见问题怎么排查验收用例是否执行所有验收用例是否通过未通过的是否有解决方案这些事项确认完项目才算真正交付。否则上线后业务方不会用、不敢用数据产品就变成了摆设。4.3 上线后怎么持续迭代数据产品上线后需求不会停止。业务方会提新维度、新指标、新筛选条件。这时候不要直接改PRD而是先评估影响范围改这个口径会影响哪些下游需不需要回刷历史数据会不会影响已有报表我的做法是维护一个“需求池”所有新需求先入池定期评审优先级。高优先级的需求走正式变更流程更新PRD、更新数据字典、更新监控规则。低优先级的需求排期到后续版本。这样既能响应业务又不会让数据产品变成一团乱麻。5. 几个让PRD更好用的实操技巧最后分享几个我在实际工作中总结的小技巧不复杂但很实用。5.1 用表格代替大段文字数据PRD里最怕大段文字描述逻辑。能用表格的地方尽量用表格。指标定义用表格、维度清单用表格、数据源用表格、验收用例用表格。表格的好处是信息密度高、对比清晰、不容易漏项。比如指标定义表每一行是一个指标每一列是一个属性。研发看一行就知道这个指标怎么算测试看一行就知道怎么验。比写三段文字描述高效得多。5.2 给每个指标配一个SQL示例如果研发和测试对口径理解有歧义最直接的解决办法是给一个SQL示例。不是让研发照抄而是用SQL把口径表达清楚。比如SELECT COUNT(DISTINCT user_id) AS dau FROM user_behavior WHERE behavior_time 2024-01-01 00:00:00 AND behavior_time 2024-01-02 00:00:00 AND behavior_type IN (login, order, pay, share);这个SQL写进PRD研发一看就懂测试也能拿去验证。比任何文字描述都管用。5.3 在PRD里预留“待确认项”章节写PRD时不可能所有细节都确认完总有一些待定事项。我的做法是在PRD里专门设一个“待确认项”章节列出所有未确认的问题、负责人、期望确认时间。每次评审会先过这个章节确认一项关闭一项。这个章节的好处是所有人知道哪些还没定不会误以为已经定了责任人明确不会互相推诿有时间节点不会无限期拖延。5.4 用版本号管理PRD变更PRD不是写完就不变的。每次变更都要升版本号记录变更内容、变更原因、变更人、变更时间。我习惯用V1.0、V1.1、V2.0这样的版本号小改升小数点大改升整数。版本号的好处是研发知道自己在看哪个版本测试知道该测哪个版本业务方知道最新版本是什么。避免出现“我看的是旧版你写的是新版”这种扯皮。5.5 把PRD当成沟通工具而不是交付物最后这一点是心态问题。很多人把PRD当成一个必须完成的交付物写完就扔给研发然后等着上线。但PRD的本质是沟通工具它的价值在于让所有人对需求有一致的理解。所以写PRD时不要只想着“写完了”要想“研发看了能不能懂”“测试看了能不能验”“业务方看了能不能确认”。如果做不到就继续改直到能做到为止。我在实际项目里的体会是一份好的数据产品PRD能让项目沟通成本降低一半以上。研发不用反复问口径测试不用反复确认预期业务方不用反复解释需求。省下来的时间可以用来做更有价值的事。