编写数据埋点文档

文档参考链接网址

一、目的

a. 前端埋点：记录用户在客户端使用数据；　　　　
b. 后端埋点：程序接口调用情况。

二、埋点的三种方式：

代码埋点、可视化埋点、无埋点。

2.1 代码埋点

加入需统计的字段特征，当用户触发时，记录用户行为。　　　　　
》》优点：可自定义数据属性，根据需求获取所需用户行为数据；　　　　　　
》》缺点：需求方对业务的深入了解，开发人员工作量，用户版本不更新无法实时记录（数据缺失）。

2.2 可视化埋点

第三方数据平台提供，通过圈选页面元素来实现数据的收集。　　　　　　
》》优点：更新埋点的时候并不需要等待程序更新，而是把数据统计的代码在应用程序启动的时候通过网络更新配置，解决了产品临时想要加入或修改埋点的需求；　　　　　　
》》缺点：不能灵活的自定义事件，只能使用平台提供的一些通用性事件。

2.3 无埋点

无埋点又叫全埋点方案，是尽可能的收集所有控件的操作数据。　　　　　　
》》优点：可以解决数据的回溯问题，当有某一特征数据需求时，直接调用即可；　　　　　　
》》缺点：不能灵活的自定义事件，所有数据收集对服务器负荷影响较大。

三、埋点文档撰写：

3.1 选择数据平台

绝大多数公司的前端埋点会使用第三方数据平台来进行，极少数的大公司会有自己开发的数据平台，不想自己开发但又想确保数据安全的公司会选择购买数据平台进行私有化部署。

3.2 查看平台技术文档

不同的平台对于数据上报可能会有不同的限制，同时字段的命名也可能有一定的差异。

3.3 埋点文档实例

根据平台技术文档明确数据平台事件+事件下的操作字段名称。　　　　
a. EventID（定义页面ID和名称）；　　　　
b. Label （字段，定义的是用户在这个页面上的使用行为，Label是从属于前面EventID的，功能点编号上也要继承前面的编号）；　　　　
c. 上报时机（埋点事件根据什么条件来触发，通常来讲分为显示时触发（曝光量）和操作时触发（转化量）两种，当有全数据后可以用来构建曝光-转化的漏斗模型）；　　　　
d. 上线时间（说明该埋点是什么时候上线的，埋点的生效时间）；　　　　
e. 优先级 (开发人员根据优先级来评估工作量)。

四、自定义事件属性：

如果仅仅只是按照这样撰写埋点文档，只能统计到事件发生的次数。而代码埋点的核心是自定义事件的属性。（通过数据字典记录用户ID，点击事件，点击的文章ID）。

4.1数据字典

数据字典是用来定义自定义事件属性的文档，通常和埋点文档放在一起通常有以下几个字段。
　　　　　　　　　　　　a. 字段解释
key：表示的是属性的名称；　　　　　　　
注释·：对于key字段的解释，用来说明key值代表的是什么，便于后续的查询；　　　　　　　
数据类型：数据类型分为名义数据、等级数据和连续数据三种，标注数据的类型有助于后续的数据分析工作；　　　　　　　
Value：Value是Key对应的值，有一些Key对应的是不确定的值，例如User_ID，有多少个用户就有多少个值，所以Value可以为空。但有一些Key的Value是限制在一定范围内的，所以需要事先对Value的可选择值作出定义；　　　　　　
全局字段Global：数据统计的过程中，有一些key值是需要所有的事件都要进行统计的，典型的例如用户的ID，为了节省时间，可以将这些key值定义为全局字段，这样就可以不用在每个事件当中重复填写了。
　　　　
b. key命名方法：驼峰命名法、下划线命名法。　　　　　　
小驼峰命名法：第二个单词首字母大写，其余小写；　　　　　　
双驼峰命名法：第一第二个单词首字母均大写，其余小写；　　　　　　
下划线命名法：多个单词之间使用下划线来进行分割。
　　　　
c. 将自定义事件的属性添加至事件中：在原有的埋点文档上添加一列Key/Value字段，然后把要添加的属性加入到事件对应的行就可以了。

五、埋点文档注意事项

5.1 埋点文档只可增加，不可修改和删除

因为产品无法保证每个使用者都在使用同一版本，所以埋点文档不可以修改，也不可以删除，因为即使从埋点文档中删除了，已经上线了的统计代码是不会删除的。删除某个埋点文档可能会导致这个事件依然在上报，但后续的产品经理却不知道这是个什么事件了。（如果要对埋点文档进行删减，只能在备注中标明，该埋点已于xx时间废弃）

5.2 事件必须独立

确保埋点的准确性，需要让不同的事件之间相互独立（例如APP页面中的返回事件，要统计该页面的蹦失率（Bounce Rate）就需要统计有多少人点了返回按钮，但是每个页面可能都有返回按钮，如果只把Lable写成“返回”则很有可能会与其他页面的返回相互混淆，造成数据结果不正确，这个问题我们已经通过给每个EventID和Label加上唯一编码解决了，目前工作中有遇到此类问题；通用的页面事件需保持唯一的编号，而不是用多个编号去统计同一个事件，造成数据的分散。如果有一个通用的页面可以通过不同的入口进入，那么可以在这个页面的事件中加入一个From_page的属性，来记录是从哪个入口进入到这个通用页面中来的。）

5.3 数据字典不重复

团队协作，确保每个事件属性的含义保持一致（如果自己需要的key已经由其他人定义好了，则可以直接拿过来使用。如果要定义之前没有出现过的key，则只需要在数据字典中添加，然后同步给其他产品经理即可。）

5.4 注意平台限制

不同的埋点平台可能对于事件和属性有上限的限制（例如友盟平台一个APP只能记录500个事件，每个事件只能定义10个属性，而talkingdata的事件是可以无上限记录的，每个事件可以记录50个属性）

5.5 埋点测试

确保埋点的数据上报正确，该统计的属性也都添加成功了（和测试同事一起进行）