一、埋点用途
为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果的记录
二、埋点分类
埋点数据一般分为：展现，点击，状态，计数四种类型。不同的类型代表着产品不同方面的需要。
- 展现：某个功能逻辑实现之后展现在用户面前的数据量。例如，资讯信息流的广告，当滑动资讯信息流展现广告时，此时发送广告的展现埋点数据，一般命名“XXXShow”；
- 点击：人为操作之后发出的数据量。这种埋点数据较为单一，正常控件元素点击，一般命名“XXXClick”；
- 状态：某个功能逻辑实现之后的状态。一般指的是开或关，登录与非登录等，一般命名“XXXStatus”；
- 计数：通常指的是一个功能点击了多少次，切换了多少次等，一般命名“XXXCount”；
此外，点击类埋点在一定的条件下可以转化为计数类埋点，当遇到需求时，从埋点的作用角度思考合理性。若是单纯统计某个元素或者控件的点击量，此时应该定义为conut类型；若是为了统计某种状态下元素或者控件的点击效果，此时应该定义为click类型。
三、埋点数据的注意事项
- 编码格式：埋点数据的value值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
- 大小写：埋点数据的key值在命名时要和服务端数据组同步命名规则，尤其是大小写，一般情况下数据组在过滤收集数据时是不考虑大小写的，但是也有例外。例如，之前在测试SDK时，客户端改变了命名规则，而服务端限制了大写，导致线上数据出现异常；
- 全角半角：埋点数据的值为英文时，常常容易忽略全角半角的输入方式，有时候会因此产生无法接收的错误；
- 数据格式：埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，此时发出的数据很多，往往同一条埋点发出好多，此时我们要整合一下数据格式。
- 发送时机：埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，不然会增加测试成本。
- 预置数据：埋点数据往往需要云端的配置文件支持，此时我们就要留意在配置文件下发之前可能产生的逻辑，这部分逻辑的数据埋点要在云端和本地同时存放，即本地要有预置数据。
- 埋点命名规则：在测试中要和产品形成一种隐含的规则，双方都要遵守。此外，埋点命名首字母要大写，这些细节不是强制性的，但是有利于数据阅读和查看。
四、埋点数据的正确性
展现类的埋点：最关键的在于避免重复统计。比如在某宝搜索“华为手机”时，当用户输入了“华为MATE10手机”和“华为MATE10”出来的效果几乎是一样的，失去了统计的意义。
点击类的埋点：关键在于避免服务器超时的情况下连续点击导致的重复统计。（比如刷新统计埋点，当服务器超时的情况下，连续多次的点击，此时如果客户端发出请求，那么统计的数据是正确的，否则没发出数据，统计的数据就是错误的）
状态类埋点：关键在于避免统计默认状态。并且状态类埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。
计数类埋点：关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。
五、埋点数据的注意事项
- 网页缓存：对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。
- 网络环境：当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。
- 覆盖安装产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。
- 服务端压力：数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。