编辑导读：书写数据需求文档是在产品工作中经常遇到的一项任务，看似简单的文档背后也有值得注意的地方。本文将从四个方面进行分析，希望对你有帮助。

DRD（Data Raquirements Document）顾名思义同PRD一样，作为同研发团队沟通的一种凭借。便于管理当前数据埋点的状态和历史迭代逻辑的追述。也是建设公司良好数据体系管理的基础，那么如何写一份高质量的DRD文档呢？

首先，要明确数据需求。只有从业务本身实际需求出发，才能够采集满足业务所需要的真实数据。是想了解整个用户浏览页面内容的情况？还是想了解某个功能整体使用情况？只有需求清晰明确了，才能够合理设计埋点采集方案定义埋点指标。

数据是判断你工作目标是否达成的关键依据，是服务于每一次迭代上线后的效果衡量。通常指标定义好之后，围绕着定义好的一些指标进行事件和属性设计就可以着手写DRD文档了。

下面结合具体实例来说一下写好一份DRD文档分几步。

一、明确需求定义指标

通过需求拆分出核心的数据指标。定义指标前要了解产品的结构、用户行为来明确分析的范围。

实例：

数据需求：通过埋点采集用户行为，分析用户使用情况和选择偏好及流失原因。

指标类别：

• 常用报表指标：新增、日活、启动、周活、月活及注册数据、会员数据、使用时长、留存、系统稳定性。这些通常为日常关心的核心数据指标可以做到报表里供日常观察的指标。
• 营销指标：营销banner曝光、点击及各个营销位的点击排行、展示排行、业务转化等营销板块的数据指标。
• 用户价值指标：新用户的次日留存、7日留存、月留存、成本、用户的产品生命周期模型。
• 运营指标：会员和活动任务的热度、业务转化、会员新增、累计、续费等指标。
• 产品功能指标：导航栏、按钮点击、功能入口的点击和转化等指标。

通过指标常用的类别确定我们需要分析的数据指标，就可以进行埋点事件设计了。

二、事件设计

主要会从两个方面去进行事件设计一个锁定是核心要分析的页面所产生的行为，一个是锁定核心功能产生的行为。

页面事件：锁定要分析的页面和页面上的内容以及在这些内容和页面上产生的点击、浏览等行为。

功能事件：锁定要分析的功能比如：搜索、登录、注册、购买、会员付费、签到、扫一扫等，这些功能的入口、点击和完成行为。

三、属性设计

每个事件都有对应的事件属性来说明该事件具体分析的维度。属性可分为通用属性和具体属性。通用属性如：版本、设备、网络、IP等。具体属性如：各事件的来源、各页面加载时长、各内容的位置、各内容的ID等。

埋点时需要进行采集这些事件的参数和属性用来分析。事件属性维度的拆解可以依照4W1H（who、when、what、where、how）的方法去进行思考避免遗漏，这里就不在多说了，多多练习就好了。

通常的页面时间的属性参数会涉及到事件的来源位置、页面曝光时长、页面上曝光的内容、内容ID、内容类型、有无图片等。

功能按钮点击的事件属性设计时，一般只需要监控按钮点击数即可，不需要进行其他背后的属性说明，例如扫一扫、广告图片点击等。也有的时候可以把按钮所属的页面作为一个事件，把各个按钮名称作为参数，去设计埋点方案。

事件的采集就是在确定产品范围内找到用户的点击、曝光、完成等系列行为，最后针对各个行为进行属性和参数的细分说明。这样一份高质量的数据文档就完成了一大半。

这里值得注意的一点就是时刻清晰明确做数据埋点的目的是什么然后通过场景化思考进行方案设计，这样有效避免数据遗漏或复杂而无用造成的低效数据埋点方案。这一方法论不仅适用于埋点方案设计时也适用于在其他所有地方和场景中做产品方案设计时，值得大家牢记。

四、完善文档细节

正如本文开头说的，DRD是作为同技术研发沟通的一种凭借。是为了便于管理当前数据埋点的状态和历史迭代逻辑追述。那么就不可少了对文档一些细节说的备注，上线时间点，当前埋点时的状态，便于后续追溯。

所以一份完整的DRD具有的维度有：事件名、英文名、事件说明、事件属性名、事件属性英文名、属性值类型、属性说明、当前状态是否在线、埋点的形式是前端采集还是后端采集、及上线的版本记录及当时状态的备注说明，这样一份完整的DRD就完成了！

本文由 @云杉小主 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议