数据分析系列——数据需求文档DRD

也。。。就是埋点需求

主体分了三大部分：业务需求描述、数据指标列表、埋点需求列表

写需求文档需要抓住的核心思想是：想清楚，搞清楚，然后说清楚

想清楚数据需求是为了要分析什么业务需求，业务目的是什么，搞清楚怎样的数据指标能满足，这些数据指标包含的各种属性研发又是怎么实现的，这些都搞懂了不要懒动手指头，该表达清楚的还是得写一下，毕竟一个词的定义可以有多种不一样的理解，清晰的需求文档可以避免很多返工和无效沟通。

下面我们来介绍下这三大部分：

一、业务需求描述

很多数据需求文档一上来就是一个excel表格，连需求背景描述也没有。

描述业务需求，可以让相关人员都搞清楚为了什么做这些埋点，我们数据分析是为了满足什么业务目的，那执行过程中就更容易达成一致并发现分别专业领域内需要注意的细节。

我们的业务需求可能来自于多个方面，有产品侧、业务侧和研发侧等等

例如：

产品需要知道

1、邀请功能新上线后对拉新的效果有多大

2、都是一些什么人邀请、哪里开始邀请的

业务想知道

3、用户都是什么时候邀请的，那可以针对那个时刻多推点活动

4、是哪些奖品让用户更愿意邀请

研发侧想知道

5、邀请的成功率

业务需求写清楚来源和描述需求目标就好

二、数据指标列表

根据业务的需求，梳理需要的数据指标，是一个从抽象逐渐到具体的过程，这一步需要简洁列出指标和描述就好，然而一个指标会包含很多属性，属性部分可以在埋点需求列表再展开

例如：

针对上面的需求整理成

1、每天从邀请功能来的新增用户数

2、每天使用邀请功能并成功邀请到新用户的用户的画像

3、各内容板块邀请功能的使用频次

4、不同时间邀请功能的使用频率趋势

5、每个奖品的邀请功能使用频次

6、邀请成功率

三、埋点需求列表

列出指标列表后，研发可以有多种方式、维度和深度去实现这些指标，为了避免有理解上的不一致，导致最后获得的数据不够完整或不是自己想象那样的，便需要和研发认真确认埋点的实现逻辑并写清楚怎么埋、埋什么，毕竟数据采集是个不可逆的过程，错过的数据要再收集回来是个极其复杂和费时的过程，但是一开始无度乱采集同样很浪费资源，下面我们分享下怎么列埋点需求和管理这些需求的一些技巧

1、公共属性

有些属性会经常被使用到，例如设备、用户身份、网络、地区等，这些只需要一份公共属性表维护就好，不需要每次新增埋点需求都列一遍了

不过要注意做好版本管理

2、新增埋点需求

以一个埋点需求模版为例，一般需要包含以下栏目

需要埋点的事件如果包含多个属性需要记录，则需要把各个属性都列出并和研发对清楚这些数据是从后端记录还是前段记录，描述清楚记录的节点和一些干扰因素的排除机制

随着上线前后的调整，埋点有可能会被变更，所以需要做好版本管理，如下表

好，一份数据需求文档就差不多了。

谢谢各位的学习，欢迎各种建议和纠正