数据产品经理基础技能：数据需求说明文档怎么写？
最近身边有很多小伙伴转行了数据产品经理，或者是在转行的路上，大家咨询较多的问题在于数据需求文档怎么写？用户画像需求文档怎么写？有没有数据需求文档（后续简称数据prd）的模板？
于是乎，我专门写了这篇文章，来回答各位的问题。
01 是什么？
1. 数据产品经理是什么？
我们先聊一聊，数据产品经理是什么？数据产品经理与产品经理的区别？我们先来看一个小案例：
前阵听神策CEO桑总讲到神策2015年成立，他早先认为团队并不需要数据产品经理，研发直接开发的数据能力十分强大，2015-17年间都是由他自己担任数据产品经理/产品经理，他来掌控产品方向，推进产品迭代。
但在17年，桑总开始意识到神策的数据分析等技术能力已十分强大，但产品用户体验不佳，很多功能都是一些堆砌，缺乏产品的层次感。这时，他的态度开始转变，他意识到仅靠自己和开发团队来做难以给客户带来更好的产品体验，需要招专业的、懂数据、懂产品的产品经理，来推进神策分析产品的进一步发展。
而这里的产品经理则是细分方向下的数据产品经理。
从上述案例可以看出什么呢？
一是数据产品经理，其实就是产品经理的角色，他承担着产品规划、产品设计、整体项目进度推进、产品运营推广等责任。而要做好一款数据分析产品，数据产品经理需要具备产品的基础能力，如沟通、协作等能力、prd撰写、原型绘制等等能力。
二是数据产品经理跟产品经理又稍有不同，数据产品经理需要懂数据分析，懂一些数据库语言，即sql语言，至少能把数据需求描述清楚。
数据产品经理=产品经理+数据分析，其能力要求80%产品经理，20%数据分析。
搞清楚数据产品经理是什么后，那我们来看看数据产品需求说明文档是什么？数据产品需求说明文档跟产品需求说明文档的区别？
2. 数据产品需求说明文档是什么？
数据产品需求说明文档，是数据产品项目由概念化阶段进入到图纸化阶段的最主要的一个文档。这是对产品需求描述的描述，其内容包含需求背景、价值、产品架构、核心业务流程、功能需求说明、数据需求说明等。
总的来看数据产品需求说明文档与产品需求说明文档大体相同，而其差异点主要在于数据需求说明模块。
数据产品需求说明文档=产品需求说明文档+数据需求说明文档。
文档面向的用户群，决定了文档应该写哪些内容，写的怎么样。数据需求说明文档使用对象主要为：数据分析师、数仓开发、算法、前后端、数据&功能测试、项目经理、交互设计师、运营等其他业务人员。
从这里的用户群可以看出，与业务prd不同点在于，新增了数据分析师；数据prd的开发人员除了前后端开发外，还有数仓开发及算法；测试人员新增了数据测试，当然一般来说数据测试和功能测试都是一个人。
用户对象有了新增，则文档的内容势必发生相应的变化，新增了一大模块——数据需求的说明。
02 为什么需要数据prd？
prd撰写是产品经理的基础能力，而数据prd撰写是数据产品经理的必备技能;数据prd是数据产品与研发、测试、设计等沟通的桥梁，要是需求描述不清楚，研发难以开发；prd出得不够细致或全面，研发则容易漏需求，导致延期。
03 如何输出一份高质量的数据prd？
数据prd在基础规范上需达到以下2个要点：
1）全面：描述清楚why-what。在what层面要尽可能地细致，纵向考虑流程链路、横向考虑各个细节功能点以及异常情况，还原用户操作界面
2）可读性强：书写风格和内容清晰。书写风格上有条理，读者能按导航快速找到相应模块，运用清晰的编号，分小模块介绍；书写内容上有逻辑，运用专业的书面语言，看图说话，复杂问题最好通过举例子方式说明
1. 数据prd包含哪些模块？
一份数据prd的组成如下：
第一模块：需求概述，讲清楚需求背景及价值，解决为什么做这个需求的问题。
第二模块：项目总览，明确项目边界及项目预期上线时间，避免后续砍需求或是加需求。
第三模块：产品总览，展示产品结构和全局说明，让读者较为清晰的从整体上接收此需求。
第四模块：功能需求说明，介绍每个功能的使用场景/用户故事，前置和后置条件，正常和异常处理。
第五模块：数据需求说明，介绍本期的数据需求对应的逻辑，取数的表等。
第六模块：运营计划，列出后续的一些运营推广计划、相关人及时间点。
附录：历次沟通意见汇总，规范记录每次需求变更及变更人，在一定程度上可以减少变更。
除第五模块外，其他各模块均为业务prd的基础组成，产品经理同学对这些基本是轻车熟路，市面上相应的资料比较多，在这我就不展开介绍。草帽小子接下来主要聊聊数据需求怎么写。
2. 数据需求分类
而要聊如何写数据需求，就不得不从数据产品经理的工作内容聊起。数据产品经理工作内容上从下层数据采集到上层数据应用，可分为数据埋点方向、BI分析方向、用户画像方向。
对应的需求文档分别为：
- 埋点数据需求文档，偏向于埋点事件的描述说明。
- 指标数据需求文档，偏向于对指标、维度、取数逻辑的说明。
- 标签数据需求文档，偏向于对标签业务含义、取数逻辑的说明。
04 标签数据说明文档怎么写？
索隆是负责用户画像平台方向上的数据产品经理，其工作内容主要为标签体系的搭建，用户画像平台建设。
1. 标签数据说明文档总览
标签数据说明文档包含：
1）标签主题：标签主题通常按对象划分，例如电商中的对象有消费者、商家、商品等对象，不同主题对象下划分的标签类别不一；
2）标签类别：标签所属的分类，如基础信息；
3）标签名称：标签中文名，如性别；
4）标签值：标签的枚举值，如男、女。
5）数据类型：标签可分为文本型标签、数值型标签。文本型标签通常为文本类型的枚举值，可用string表示；数值型标签通常为数字类型，可用int表示，此项通常由开发人员填写。
6）标签含义：标签的业务含义，这通常是业务人员比较关注的一栏。
7）标签使用场景：标签在什么场景下用，需业务人员在提出标签需求时填写清楚，没有应用场景的标签开发出来浪费人力物力，最终也是没人用。
8）标签计算逻辑：通常由数仓开发或是算法工程师填写，从技术的角度说明清楚该标签是如何一步步得出的。
9）依赖数据表和字段：针对事实或规则类标签，产品经理可列出标签所需的上游数据表及字段，方便开发人员写逻辑。这就需要产品经理较为熟悉底层的数据表及业务字段，最好是联合需求方一块梳理，业务上表的状态字段很多都难以区分，产品经理随便写上去，最终可能不是业务想要的结果。
总体来看，产品层面需要描绘业务语言，把标签的业务含义、使用价值等说清楚；研发层面列出标签的计算规则，增强标签的置信度， 一期可先在线下维护起来，后续可以开发标签管理系统，将标签在系统中管起来。
其中业务价值及使用场景决定了是否要做该标签，以及标签如何定义。如，商家“累计签约次数”标签，其使用场景一在于：对于多次签约的商家给予一定力度的优惠，提升一定的留存率。
统计“累计签约次数”标签是很简单粗暴的方式，其好处在于营销人员可灵活圈选“累计签约次数>1、2、3…”的商家分群，且规则简单。但其劣势在于标签值分段不直观，容易给营销人员造成困扰，到底是对“累计签约次数>1还是2”的商家给予优惠呢？分别给予多少优惠？没有明确的业务策略，以至于这个标签开发出来没人用。
因而产品经理需要进一步思考，基于这个场景，标签是否还有其他更好的实现方案？
2. 标签树状分级结构
划分标签的主题，以及标签所属的类别，简而言之，也可以理解为划分标签的一级分类、二级分类。为什么要做这样的划分呢？
而索隆率先建设消费者画像，初期做了十几个标签，如性别、年龄、所在城市、偏好等，最开始没做分类。接下来索隆又丰富了消费行为类、偏好类标签，做了上百个标签。
为了让营销人员更快的找到对应的标签，索隆将消费者标签划分了几大分类，整个消费者体系的画像雏形基本建设完成，营销人员则可灵活的对这类群体进行精细化运营。
从营销侧来看，标签树状分级的缘由在于帮助营销人员，快速从成百上千个标签中找到自己所需标签；从管理侧来看，标签分级结构可拓展性强，方便管理标签。
这时面向商家对营销人员开始眼馋了，看着面向消费者侧有如此个性化的服务，商家侧也需要建设一份商家画像，因而，索隆也开始着手搭建商家画像体系。当然商家营销关注的业务与消费者侧并不一致，因而所建立的标签体系也会有所不同，如建设商机行为、签约行为等标签。
从索隆建设标签树状分级结构过程，可以看出：从营销侧来看，标签树状分级的缘由在于帮助营销人员，快速从成百上千个标签中找到自己所需标签；从管理侧来看，标签分级结构可拓展性强，方便管理标签。
了解了做标签分级的原因，建设初期要注意的是层级不必生搬硬套，划分过细，需根据标签建设实际情况来。如公司只有几十个标签，则划分至二级足矣，过细反而累赘。
3. 标签名称和标签值
用户标签，即对用户某个维度属性的描述。其标签值具有高度概括、相互独立以及可枚举穷尽的特点。标签由【标签名称】+【标签值】组成，如性别：“男、女”。
例如，在职场视角，你被贴上如责任心强、积极上进、技术型产品等标签；在整个社会视角，你被贴上如白领、高收入人群、IT互联网、宅女等标签。这里的“高收入人群”即是文档中标签值的概念。
按标签值类型的不同，可将标签分为两种类型：数值型标签、文本型标签。
- 数值型标签：标签值为数字，跟指标一致，标签命名通常由【时间】+【用户行为】+【统计方式】组成，如，近30天购买次数：0、1、2、3…10+。
- 文本型标签：标签值为文本，也称为字符串，标签命名无特定方式，注重简约直观，如，用户价值：高价值、中价值、低价值。
05 小结
整篇文章草帽小子介绍产品经理与数据产品经理、业务prd与数据prd；相信你可以认识到数据产品经理其实就是产品经理的角色，其承担着产品规划、产品设计、整体项目进度推进、产品运营推广等责任。
因而与数据产品经理相对应数据prd与业务prd整体结构相同，都包含需求概述、项目总览、产品总览、功能需求说明、运营计划等常规模块，数据prd额外增加数据类需求的详细说明。
而数据类需求整体来看的要点是，尽可能写清楚数据的计算规则、来龙去脉。把库表字段、取值范围等说明清楚。工作做到细致到位，这样才能更好的保障数据的质量。想了解更多的朋友，也欢迎加入“数据产品交流群”进行交流。
整体来看，产品基本功打好了，写数据prd并不难。建议从业务产品转数据产品的朋友，可学一些简单的SQL，这样基础的数据可以取来分析；建议数据开发/数据分析师转数据产品的朋友，可以学习产品方法论，不忘业务导向。
#作者#
草帽小子，公众号：一个数据人的自留地。《大数据实践之路：数据中台+数据分析+产品应用》书籍作者，专注用户画像领域。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
