数据埋点是数据分析师，数据产品经理和数据运营，基于业务需求或者产品需求对用户行为的每一个事件对应位置进行开发埋点，并通过SDK上报埋点的数据结果，记录汇总数据后进行分析，推动产品优化和指导运营。本文作者结合自己一些经验，围绕数据埋点的属性与设计流程发表了自己的看法，与你分享。
一、背景
用户在使用产品过程中，通常会产生过程数据与结果数据这两大类数据。结果数据，顾名思义就是最终的结果。而过程数据就是用户从始至终的所有操作数据
结果是唯一的，过程可就千千万了。如果将过程数据全部记录下来，也是没啥必要
- 开发成本大
- 也不是所有的过程都是有价值的
问题来了，如何获取想要的数据？
用数据埋点
埋点是如今常用的数据分析方式，是针对产品需要关注的特定事件进行数据采集和上报的解决方案
用户在产品里使用了什么，是怎么使用的，具体的使用流程是什么……都可以从埋点数据中分析出结论
而科学有效的埋点可在一定程度上给产品的优化迭代提供方向
二、关于埋点
1、埋点模型
埋点使用什么样的模型，决定了产品按照什么架构收集用户信息。事件模型是现在比较主流的一种埋点模型。所谓事件模型，可以简单的理解成「事件」与「用户」之间关系的模型，它将用户的行为分别记录在事件表和用户表中。事件表中记录Who、When、Where、What、How，即谁在什么时间、什么地点、用什么样的方式、做了什么事。用户表里记录的是用户的属性，例如：年龄、性别、设备……
1.1、 Who：人物
参与事件的用户，可将事件与用户关联起来。常用数据有用户ID、设备ID……
准确的定义用户身份是精确分析的基础。拿页面访问来说，我们不仅仅想要知道PV，还想要知道UV（PV去重）。UV对于评估用户量级来说更加准确，UV越大，越值得产品资源的倾斜。
1.2、When：时间
事件是什么时候发生的。常用数据有时间戳、当地时间……
记录事件发生的时间，可以了解某一事件发生的时间分布规律，进而在用户活跃高峰时段展开特定的运营活动，毕竟多一位用户看到，就可能多一丝转化。
1.3、Where：地点
事件操作的位置。常用数据有经纬度、省市区……
记录发生事件的位置，可以了解同一时间不同地区的业务增长情况，指导市场工作方向。
1.4、What：内容
事件操作的具体内容。常用数据，就根据业务各有千秋了
1.5、How：怎样
事件操作时的环境，包括硬件环境和软件环境。常用数据有网络环境、操作系统、产品版本、手机厂商、手机型号……
记录用户是怎样操作事件的，可以了解目标用户的手机配置情况。若配置较低，则应避免在功能上设计复杂的交互。
2、埋点类型
常见的埋点类型主要有：点击类、曝光类、页面事件类
2.1、点击类
用户点击了某个元素，如按钮、链接、区域……通过点击事件，我们一般可以拿到点击PV，点击UV。
2.2、曝光类
当我们需要计算某一区域的点击率的时候，应该先确认，到底多少用户看到了这个区域。
例如：用户点击活动链接，进入活动落地页，该活动页就记录一次曝光。一般点击率的计算公式是：CTR=点击数/曝光数。
2.3、页面事件类
最常见的应该就是页面浏览PV和UV了。
3、埋点文档?
下图表格展示了常规埋点文档内需要包含的信息，除了内容本身，有两点可以额外关注一下
3.1、预设属性
埋点时常常有一些通用参数，即无论什么事件都需要上报的参数。为了避免重复劳动，通常会将这些参数预先定义，每一事件埋点都默认上报。
常用的有：用户ID、设备ID、手机型号、操作系统、网络状况、事件发生时间……
3.2、属性值类型
类型本身有很多，我常用的就仨。
字符串：文本内容，可以是中文，也可以是英文；
布尔：表示true（是）和false（否）；
数值型：包括整数型和浮点型（小数型）；
三、埋点文档的撰写
数据需求文档（Data Requirements Document，简称DRD），大家一般会叫它的小名儿：埋点文档。
埋点文档本质和产品需求文档一样，是与研发维持良好沟通的工具。一份完整的埋点文档，不仅需要定义埋点的事件，还需要说明每一个事件的埋点方式、触发时机、包含属性、属性值类型、上报时机、归属版本、备注信息……
稳定的常态化业务使用埋点文档无可厚非。不过，短平快的测试项目就不太适合完整的埋点文档了，建议在需求文档中简单表明需要的数据，交付需求和研发确认一下即可。
举个例子：本次功能埋单需求
- 统计页面PV（页面浏览量）和UV（按照IP去重的页面浏览量）
- 统计页面中A和B两个按钮的点击量（按钮点击的PV）和点击人数（按钮点击的UV）
四、写在最后
大多数的产品应该都需要在日常工作中负责埋点文档的输出。本文是根据自身经验总结的一点儿想法，无关于行业规范。希望不久的将来可以对埋点有新的想法。
