一：埋点数据的意义
1.产品的晴雨表。
通过对用户数据的对比，对数据趋势的分析，能发现哪些环节存在问题，哪些环节有提高空间。
2.优化排期以及资源调配
同时，通过数据分析，可以更直观的查看功能的受欢迎程度以及面向用户对产品进行改良。
二：埋点数据的类型：
埋点数据一般分为：展现，点击，状态，计数等类型。
1.展现。
某个功能逻辑实现之后展现在用户面前的数据量。例如，资讯信息流的广告，当滑动资讯信息流展现广告时，此时发送广告的展现埋点数据，一般命名“XXXShow”；
2.点击。
人为操作之后发出的数据量。这种埋点数据较为单一，正常控件元素点击，一般命名“XXXClick”；
3.状态。
某个功能逻辑实现之后的状态。一般指的是开或关，登录与非登录等，一般命名“XXXStatus”；
4.计数。
通常指的是一个功能点击了多少次，切换了多少次等，一般命名“XXXCount”；
5.性能统计
默认性能统计上报会在发生 load 事件或 unload 事件时上报，具体取决于哪个事件先发生，并且只会上报一次。
6.滚动可视
滚动可视上报是指页面元素在通过滚动行为触发，经过不可见到可见过程之后的上报，可视上报模块的目标是收集页面中重点关注元素的展示情况，对于需要收集可视上报的内容区域，在页面发生滚动行为并且该区域出现在视口内时，模块将自动收集值作为上报参数的一部分。
7.时间消耗
时间消耗上报模块主要用于代码块、异步操作或接口请求的时间消耗，可以以自己的方式统计好时间然后调用计数方法来上报，也可以在指定代码块执行前统计时间，在代码执行后统计时间，通过时间差自动统计并上报。
三：测试点
1.页面全部覆盖
同一个功能在前端有多个位置，注意所有的位置点均具有上报功能。
2.发送时机
埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，不然会增加测试成本。此外，在发送自测case时（注释：自测case是指开发提测之前，衡量是否能提测的主路径测试用例）要标记清楚。例如：“数据发送有独立的接口，请直接调用即可”这样的提示，以免新来的同学不了解逻辑而单独处理。
3.编码格式
埋点数据的value值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
4.大小写
埋点数据的key值在命名时要和服务端数据组同步命名规则，尤其是大小写，一般情况下数据组在过滤收集数据时是不考虑大小写的，但是也有例外。例如，之前在测试SDK时，客户端改变了命名规则，而服务端限制了大写，导致线上数据出现异常。
5.埋点的准确性和合理性
例如，浏览器的分享web页功能，开发一开始将埋点放在点击分享按钮之后；即下图中蓝色按钮之后，但是这种情况忽略了一个问题，如果单纯的统计分享按钮的点击次数，这种逻辑是正常的，但是如果要统计web页信息分享之后的数据，应该将埋点设在下图红色框内的按钮点击分享成功之后。否则如果用户点击了分享按钮但是没有触发具体的分享操作，那么此时数据就会出现误差。
6.展现埋点
最关键的在于避免重复统计。例如，浏览器有搜索VR功能，需要统计不同的搜索展现的VR的数据。例如下图中“快乐大本营”是搜索出来的VR，但是由“快乐”变化到“快乐大”的过程中虽然从逻辑上重新做了处理，但是对于用户来说，连续输入看到的始终是搜索VR---“快乐大本营”，因此多次统计就没有产品意义。
6.点击埋点
关键在于避免服务器超时的情况下连续点击导致的重复统计。例如，资讯信息流的刷新统计埋点，当服务器超时的情况下，连续多次的点击，此时如果客户端发出的请求，统计刷新数据是没有问题的，但是请求如果没有发出，那么此时统计多条就是不正常的。
7.状态埋点
关键在于避免统计默认状态。并且状态埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。此外，例如，浏览器的网页护眼色。浏览器网页护眼色默认状态是无护眼色，因此，我们在关注护眼色的状态时就要验证在调起工具栏的同时，护眼色的默认状态是否发送了数据，如果发送了就是错误的，或者发送的为空，都是没有意义的
8.计数埋点
关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。
8.网页缓存
对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。
10.网络环境
当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。
11.覆盖安装
产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。
12.服务端压力
数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。
13.数据格式
埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，此时发出的数据很多，往往同一条埋点发出好多，此时我们要整合一下数据格式。
14.预置数据
埋点数据往往需要云端的配置文件支持，此时我们就要留意在配置文件下发之前可能产生的逻辑，这部分逻辑的数据埋点要在云端和本地同时存放，即本地要有预置数据。
15.埋点命名规则
测试中要和产品形成一种隐含的规则，双方都要遵守。此外，埋点命名首字母要大写，这些细节不是强制性的，但是有利于数据阅读和查看。
16.数据处理
上报之后的数据，会通过数据整理，去重等操作。上报的数据要具备唯一辨识性。
