在上一篇文章讲了数据分析的前置工作，这篇将详细介绍一下如何完成完成数据埋点的梳理和交接（细化到执行层面）。
定义数据埋点及其交接主要分为四个部分，梳理数据需求—定义数据指标—埋点整理—文档输出——埋点验收，前两个步骤在上文中已经详细描述过方法，本文不再赘述。
本文较为简洁，整理了梳理埋点的方法和与开发交接的方法，希望大家可以充分吸收。
埋点整理
一个埋点需要传输大量的用户数据，那么为什么要传输这些数据，都要传输那些数据则需要我们产品来定义。
定义：埋点的目的是为了收集可以体现用户场景和真实需求的行为数据。
方法：4W1H（who\when\where\what\how）—方法来自最近学习的数据课程。
某个用户在某个时间/某个地点通过某种方式完成了某个具体的事情。
A：who
目的：定位是谁完成了这个行为，用户ID应该唯一，可将行为与用户关联的指标。
常用数据：用户id（平台生成的唯一ID）、手机号、身份证、微信识别码。
B：where
目的：定位用户在什么地方完成该行为。
常用数据：IP(WEB 、手机)、GPS（手机）、自主填写位置（在乎用户希望在哪里发生这件行为，如买房/装修/当地美团）。
C：when
目的：定位用户什么时间完成该行为。
常用数据：时间戳、当地时间。
D：how
目的：定位用户发生行为时的周边环境/手段/设备尽可能还原用户所处环境即可。
常用数据：操作系统、设备版本、设备型号、网络环境（Wi-Fi、4g）、浏览器、上级页面。
E：what
目的：定位用户当前做了什么行为，行为越具体越好。
常用数据：根据业务功能需要进行设计，常用数据如下。
交易：商品ID、商品类型、购买数量、付款方式、付款金额。
搜索：关键词、搜索类型、是否为当时热词。
内容：内容ID、内容类型、浏览数、列表位置、是否喜欢。
Tips：以上内容的内容为埋点需要传输的内容（这仅仅是一个方法，帮大家整理需要包含的内容用户属性有哪些），和开发确认内容后一定要确认这些数据是在什么时间点传至后台。
事件发生时上报：用户产生某个点击行为，则将以上数据传输至后台；
某个时间点打包上报：每天、每小时上报一次用户的某些行为数据；
这个一定要确认，因为对数据的及时性要求不同，数据更新频率需要做特殊处理。
文档输出
文档输出的主要目的是为了与开发对某个数据的采集有一致的理解，同时不要有遗漏数据，同时最好记录是哪个版本有这些数据需求，以便于维护和查找。
文档必备的要素：
- 事件名称：埋点的事件名称，如文章阅读/文章评论/关注；
- 事件定义：用户点击社区—内容则上报该事件；
- 包含属性：用户进行了该行为，上报事件中需要传输那些内容，如用户ID、时间、应用版本、网络环境、手机型号、IP、内容ID、内容类型、第几篇浏览；如某些属性在所有事件中都需要上传则可以整理公共属性进行管理；
- 属性定义：说明属性的定义，如用户地址用用户主动上传的地址，如没有则用用户IP代替；
- 属性值类型：说明传输至的类型，字符串、数值、bool；
- 开发名称：对应的开发变量名，可以由开发进行补充。如userID、contentID；
- 当前状态：说明当前该变量的状态。如待开发、开发中、验收中、已上线、已下线；
- 上线版本：说明该内容在那个版本进行上线。如2.3.1；
- 备注：备注中可记录该属性的变动情况和常见值等内容。
案例：如当前根据数据需求确认数据指标为内容浏览量，则需要统计用户的每一次内容浏览行为，根据上述的埋点数据整理方法整理的需收集的内容如下：
- Who：用户ID，平台的用户唯一编码；
- Where：IP（根据IP解析国家、城市、区）；
- When：时间，事件触发事件；
- How：设备型号、网络环境、操作系统、使用版本；
- What：文章ID、文章类型、上级页面、文章浏览数、用户浏览数。
整理为Excel大致如下：
埋点验收
埋点验收的目的是因为如果埋点上线后有误则该过程的用户数据均会丢失无法记录。
验收方法：查看对应数据平台是否有对应事件产生，是否拿到相关属性。网页可点击F12查看数据反馈。与建立的Excel进行核对确认是否有遗漏。
总结
数据埋点的方法分享完毕啦，主要步骤为确认指标—整理埋点—文档输出—内容验收。
最后祝大家身体健康，百毒不侵。