企业官网建设流程全解析

数据产品经理和功能产品经理写出来的PRD，经常是两种完全不同的东西。功能PRD可以围绕页面跳转、按钮交互、字段校验来写，读者是前端、后端和测试，大家对着原型图就能对齐。但数据产品的PRD，如果还按这个套路写，交付当天就会出问题——研发问你指标口径是什么，你写的是“按业务需求统计”；测试问你数据什么时候能查到，你写的是“T+1更新”；下游用数的人问你为什么昨天的数字和今天看到的不一样，你只能说“我确认一下”。这类返工我见过太多次，根子几乎都埋在PRD阶段。

这篇内容面向的是正在做或准备转做数据产品的同学，尤其是需要独立输出数据需求文档、数据看板需求、指标平台需求、数据服务接口需求的人。我会把一份能真正落地、能减少扯皮的数据产品PRD拆开讲清楚：它和功能PRD的本质差异在哪、一份完整模板应该包含哪些模块、每个模块里哪些字段是必须写死的、以及我在实际项目里反复踩到的五个坑。全文不空谈方法论，重点放在“你打开文档该敲哪些字”这个层面。

1. 数据产品PRD和功能PRD到底差在哪

很多人写数据PRD写不好，不是因为不会写文档，而是因为脑子里还在用功能PRD的框架。功能PRD的核心是“用户操作后系统如何响应”，数据PRD的核心是“数据从哪来、怎么算、给谁看、什么时候更新”。这两件事的验收标准完全不同。

1.1 功能PRD验收的是交互，数据PRD验收的是数字

功能需求上线后，测试点的是按钮能不能点、跳转对不对、异常提示有没有。数据需求上线后，测试点的是这个指标算出来是不是等于业务方手工算的那张Excel。这意味着数据PRD里必须包含可验证的数值样例，而不是只描述逻辑。

我习惯在PRD里直接放一张“口径验证表”，列出至少三组样本数据，写明输入是什么、预期输出是多少。比如做订单履约率看板，我会写：某天创建订单100单，其中95单在承诺时间内完成，履约率=95/100=95%。研发和测试拿到这个样例，就能自己反推逻辑对不对，而不是上线后靠业务方肉眼发现数字不对。

1.2 数据PRD的读者比功能PRD多一类人

功能PRD的读者主要是研发、测试、UI。数据PRD的读者除了这三类，还多了数据分析师、下游用数团队、甚至算法团队。不同角色关注的点完全不一样：研发关注数据源和计算逻辑，分析师关注维度和指标定义，下游关注输出格式和更新时效。

这就导致数据PRD不能只写一份给所有人看，最好在文档开头就明确“本文档面向哪些角色，各角色重点关注哪些章节”。我在实际项目里会在PRD第一页放一个读者指引表，把研发、测试、分析师、下游分别对应到具体章节，减少沟通成本。

1.3 数据需求变更成本远高于功能需求

功能需求改一个按钮位置，前端改几行代码就完事。数据需求改一个指标口径，可能意味着整条数据链路重跑、历史数据回刷、下游报表全部对不上。所以数据PRD在口径定义上必须做到“一次写死，后续变更走正式流程”。

我的做法是在PRD里单独设一个“口径变更记录”章节，任何口径调整都要记录变更时间、变更原因、影响范围、是否需要回刷历史数据。这个章节在项目初期可能是空的，但它的存在本身就是一种约束，提醒所有人口径不是随便改的。

2. 一份能落地的数据产品PRD模板长什么样

下面这份模板是我在多个数据产品项目中沉淀下来的，覆盖了从背景到验收的完整链路。你可以直接拿去改，但要注意每个模块里的“必填项”不能省，省了后面一定出问题。

2.1 文档信息与变更记录

这个模块看起来是形式主义，但实际项目里非常有用。至少包含：文档版本、创建日期、最后更新日期、作者、评审人、变更摘要。变更摘要要写清楚每次改了什么，而不是只写“更新”。

我见过一个项目因为没写变更记录，上线后发现指标口径和三个月前评审时不一致，但没人记得是谁改的、为什么改。最后只能全部重算，浪费了两周时间。所以这个模块不是给领导看的，是给未来的自己看的。

2.2 业务背景与目标

这部分要回答三个问题：为什么要做这个数据产品、它解决什么业务问题、成功标准是什么。注意，成功标准必须是可量化的，不能写“提升业务决策效率”这种虚的。

比如做供应链履约看板，成功标准可以写：业务方从提出数据需求到拿到结果的时间从3天缩短到10分钟；履约异常发现时间从T+3提前到T+1。这种标准在项目结束后可以直接验证，而不是靠感觉判断。

2.3 数据范围与数据源

这是数据PRD最核心的模块之一。必须写清楚：数据来自哪些系统、通过什么方式接入、数据量级大概多少、有没有历史数据需要初始化。

我习惯用一张表来呈现：

这张表能让研发快速评估工作量，也能让测试知道该准备多少测试数据。

2.4 指标与维度定义

这是最容易出问题的模块。每个指标必须包含：指标名称、业务口径、技术口径、计算逻辑、维度、粒度、单位、精度、空值处理方式。

我举一个实际例子。做“日活跃用户数”这个指标：

• 指标名称：日活跃用户数（DAU）
• 业务口径：当日有任意一次有效行为的去重用户数
• 技术口径：在行为表中，按用户ID去重，筛选行为时间在当日00:00:00至23:59:59之间，且行为类型属于有效行为集合
• 维度：日期、渠道、地区
• 粒度：日
• 单位：人
• 精度：整数
• 空值处理：当日无数据时展示为0，不展示为空

注意“有效行为集合”必须枚举清楚，不能写“等有效行为”。我踩过这个坑，当时写了“等”，结果研发把浏览也算进去了，DAU直接翻倍。

2.5 数据输出与展示形式

数据产品最终要输出给谁、以什么形式输出，必须在PRD里写死。是看板、报表、API接口、还是数据文件？输出频率是实时、T+1、还是每周？

如果是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 更新时效写“T+1”但没写具体时间

“T+1更新”是一个模糊表述。是凌晨1点更新还是早上8点更新？是数据全部更新完还是部分更新？业务方早上9点打开看板看到的是昨天的数据还是前天的数据？

我现在的写法是：数据更新时间窗口为每日02:00至06:00，06: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，能让项目沟通成本降低一半以上。研发不用反复问口径，测试不用反复确认预期，业务方不用反复解释需求。省下来的时间，可以用来做更有价值的事。