一.什么是数据需求文档

数据需求文档简称DRD，英文全称Data Raquirements Document，工作中一般称之为“埋点文档”。

二.为什么要写数据需求文档

相信大家都做过埋点相关的工作，有此时候，当面对一些埋点需求时，我们往往不知道需要哪些数据，也不清楚这些数据有什么属性，有时候能梳理出来一些，但还是缺这缺那的，最后跟研发沟通时，研发根本听不懂我们在说什么，反过来我们还会被研发问住，而数据需求文档能很好的明确我们的需求及需求的要求和细节，让研发明确实现的结果。在后续的工作中也方便有据可查，如果有一天我们要离职，在交接上更容易，也显得更职业，也方便跟进者很清楚的了解之前的做法和过程。

三.一份出色的数据需求文档包括哪些内容？

一分出色的数据需求文档一般包括两部分内容：

part1.明确埋点需求

做埋点的最终目的是有能力观察及分析数据，在这之前，我们要先归纳需求，这个需求是产品自身的指标建模还是业务部门的分析需求呢，然后根据归类选择适当的埋点属性。

我们给事件添加属性时是有些方法的，有时候说不定我们还没想好以后怎么分析，我们就可以用4W1H这个方法去设计一条埋点中所需要添加的属性。

4W1H方法论

4W1H是指Who When Where How What，即某个用户在某个时间点、某个地方以某种方式完成了某个具体的事情，一个出色的埋点应该包括以上五种信息。

首先，我们来聊聊Who(某个用户）

1.Who

当我们需求定义到人时有两种方式：

第一、认设备

web：如果是网页，我们用网页上的一段cookie来定义，网页在进行任何操作上报埋点时把这段cookie带上，后面做分析时就能把不同的人给区分开。

iOS：如果用的是iOS的移动设备，可以用UUID、IDFV、IDFA这样的标识来进行区分用户。

Android：如果用的是Android的移动设备，我们可以用UUID、Android ID这样的标识来进行区分用户。

第二、认人

线上：如果我们是线上的采集场景的话，像UID、微信等第三方Union ID/ Open ID、手机号、身份证都能作为唯一的身份标识。

线下：一般用的手机号、身份证来作为唯一的身份标识。

在Who这一块儿我们的目的是：希望在埋点里面提供一个信息，这个信息可以帮助我们区分出来唯一的用户。

2.When

Where这一块有两个问题需要注意：

第一、哪个节点的时间

一个数据的产生是由事件发生-事件上报-事件接收-事件入库是分成四部分的，这四个部分时间都不相同，如果有时候我们跟研发的沟通不是特别的密切，有的研发就会采用错误的事件。

举个栗子：某个事件是在上午12点12分12秒发生的 ，在我们的理解了这个事件应该被记为12点12分12秒。但是为了给用户省电量或者节省流量，一般不会每产生一条记录上报一次，通常的策略是延迟上报，比如每30秒集中的打包一次，把这些30秒期间所有发生的埋点集中上报一次，如果研发实现的不太好，这个30秒内所有的事件上报时被打成同一个时间，这在我们后续研究用户行为序列时和做路径时就会非常尴尬。

第二、哪个时区的时间

现在很多公司都布局海外市场，如果做海外市场就会有时区的问题，比如都是12点12分12秒，但是全球各地关于12点12分12秒的定义不一样，这里有两种处理方式。

第一种：上报时间时，把时区直接带上。这样后面我们去处理和分析数据时比较方便。

第二种：使用Unix时间戳。这个时间戳有个特点：全球统一，不管在哪个时区，取出来都是唯一的值。因为时间戳运作的原理是：从1970年1月1日零晨0点0分0秒开始计数，每增加1秒加1，一直累加，直到现在。

3.Where

Where这一块儿我们有三种方法可以采集

第一、GPS

GPS是通过卫星去定位当前的经度和纬度，但我们做分析的时候一般不要经纬度，我们需要用户的详细地址，像国家/省/市/街道，这里我们可以运用转换工具，比如高德地图或百度地图，它们就会给出这个经纬度所处的国家/省/市/街道。

第二、IP

IP地址通常针对的是网站用户或者是移动端不把地理位置授权给我们的用户，但IP是统一分配给运营商的，所以通常来说比较粗略，一般能取到市就不错了。这里我们可以通过第三方软件去反查所属地。

第三、自主填写

有一种情况是用户实际在哪对我们业务来说不重要，我们更关心用户希望在哪儿，比如租房买房类的产品，这种情况我们更需要的是用户想要在哪儿的位置。像这种类型的产品呢我们可以让用户自主填写。

4.How

比如，用户用的是什么设备？装的是哪个版本？操作系统是什么？用的哪个浏览器？现在是4G还是wifi？从哪个页面跳过来的？从哪个渠道来的？这些信息我们都需要提前定义好，然后放在埋点里面准备着。How 这部分是用户在做这件事所处的环境，所用的手段，就是用户做这件事的所有环境尽可能多的全面的还原出来。

5.What

前面的某个用户在某个时间点、某个地方以某种方式这四步都是辅助的，最重要的在第五步，即完成了某个具体的事情。

比如购买这个事件中商品的名称、商品类型是什么，购买的数量是多少，金额是什么，付款方式是哪一种。把这些信息都记录下来之后，比如付款方式有三种：余额支付、支付宝支付、信用卡支付，当我们统计了足够多的事件之后，比如说昨天的余额支付从500降到200，这时我们就可以去按照不同的支付方式去拆解，发现这些支付情况的情况，我们就可以根据这些数据去分析原因。

我们在做埋点时能够把埋点的这五个方面都补充完，那么这个埋点就是一个完整的埋点，从而保证在后面分析时是有真正的东西可以分析的。而不是每次想分析时再去补。

最后需要注意的是：像who when where这三个是公共属性,公共属性统一取值、维护。研发直接去读公共属性的值就行。

part2.埋点实施过程中的细节

在跟研发沟通中最大的冲突时埋前端还是埋后端，建议：除非某个行为只在前端发生，否则，建议永远在后端采集。前端埋点是只有在前端才能采集到的数据，一些偏业务流程的偏场景的建议在后端埋点。

1.前端埋点的弊端

某些属性前端没有

where（都不一定有）/ what/ how 的许多信息，往往只存于后端。

比如IP：有时候网页是拿不到IP的，因为有时候你是处于重重的防火墙和路由器后面，网页不知道用户的IP是什么，用户请求到达服务器时，服务器知道网络IP是什么。

改动依赖产品发版

APPStore需审核、web发版也有排期，响应速度不如后端，如果在后端做这个埋点那就简单多了，我们可以随时改，随时发布。

事件上报时机略尴尬

有时候我们需要给用户省流量和省电量，这时就不能及时的上传事件，比如说30秒上报一次，那这就牺牲了数据的时效性。

2.埋点属性的来源

前端

调用API：从接口上取，比如：商品名、商品分类等。

取页面上的值：就是当前界面上我们能看到的文字和数值 

行为统计：（e.g.前台timer,自行触发&记录页面时长）：比如前端有计时器记录用户的使用时长。

后端

业务数据：比如从前端发过来的业务请求数据，

查关联表：比如前端发过来的商品ID数据，我想基于商品ID去查到这个商品的其他一些信息

前端送来的数据：有些数据是后端取不到的，前端把数据发送过来，后端存起来）

技术数据：（e.g.单次事件响应时间）比如发起一个搜索请求，那后端的逻辑是用户发送搜索请之后，多久把搜索结果反馈过去呢，这里可以把用户的搜索时间记录下来

3.埋点有效性的校验

校验埋点有效性的手段有两种：

第一、抓包：如果有web端我们就可以通过谷歌浏览器的开发者工具直接去看这个网页跟服务器发送的通信请求，埋点也都在里面。如果APP的话抓包就比较麻烦一些，这时可以借助一些工具。

第二、看数据平台是否显示对应事件：从接收方那看，现在很多平台都支持查看从用户那发过来的原始的埋点数据。

为什么要去做校验呢？因为用户行为的特征的数据不具备回溯性，信息损失了，后续再也补不回来了。因此在埋点上线之前我们一定要做好查验的工作。

好啦，本篇文章到这里就结束了，下面是一个简单的数据需求文档的样板，供大家参考：