埋点的逻辑：
界面-事件-事件参数
每一个界面的每个事件都有唯一的标示ID
此外，每个界面中都会有公共参数统计，比如：userId、timestamp、taskId等
埋点怎样测试：
（1）通用的一种方式是直接第三方统计平台去定时查看自己的appid对应的数据。优点是，第三方平台的数据往往是经过分析汇总的，展示非常直观。但缺点，是这些平台数据往往不是时时更新的。
再加上第三方统计平台自己的稳定性也有待考量。所以没办法及时确认数据的准确性。
主流APP统计工具：友盟+的U-App，Talking Data，openinstall，Google Analytics
（2）另一种方式是从客户端下手，查看开发的埋点日志。
Android平台用androidsdk
环境和资料准备：
1、搭建ddms环境，可以使用androidstudio，或者直接使用android sdk里带的monitor
2、想尽一切办法拿到埋点字段表，这是开发埋点的依据，以及产品分析的标准
3、取已埋点的安装包并且输出app埋点的日志
测试方法：
1、调起monitor之后，连接移动设备
2、设置logcat的filter，填写包名即可
3、查看埋点字段表，执行对应有埋点的操作，进入手机上的app，点击 下一步
4、查看ddms的logcat，即可看到操作的日志
5、检查埋点是否正确，出现错误的情况一般是：
a)漏埋点
b)埋点和操作类型不对应，比如点击的是“下一步”，却上报了“返回”
c)埋点和操作频率不对应，比如只操作了一次，却上报了两次
iOS平台用xcode
环境和资料准备
1、安装xcode，从appstore直接下载即可
2、找产品/开发拿到埋点字段表
3、找开发要已经埋点的安装包
测试方法
1、调起xcode之后，连接移动设备
2、选择Debug－Devices
3、查看埋点字段表，执行对应有埋点的操作
4、检查埋点准确性
小程序平台
小程序埋点是通过脚本植入代码，js脚本中通过内置app，app有他的生命周期，当打开小程序的时候会触发请求，我们可以把我们想要做的事情随着该请求一起发出，把相应的需要采集的组件，事件添加到监听列表里面去，根据json的需要采集的组件，绑定相应的class和处理的监听回调函数。当页面被浏览的时候会满足我们需要采集的条件。
埋点数据的注意事项
编码格式：埋点数据的值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
大小写：埋点数据的值在命名时要和服务端数据组同步命名规则，尤其是大小写；
全角半角：埋点数据的值为英文时，常常容易忽略全角半角的输入方式，有时候会因此产生无法接收的错误；
数据格式：埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，发出的数据量大且同一条埋点发出好多，需要整合；
发送时机：埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，增加测试成本；
埋点数据的命名规则：埋点数据的规范化命名规则有利于数据的阅读和查看，比如页面点击的就用Page开头，区域的用Label开头作为前缀；
展现类的埋点：最关键的在于避免重复统计。比如在某宝搜索“华为手机”时，当用户输入了“华为MATE10手机”和“华为MATE10”出来的效果几乎是一样的，失去了统计的意义。
点击类的埋点：关键在于避免服务器超时的情况下连续点击导致的重复统计。
状态类埋点：关键在于避免统计默认状态。并且状态类埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。
计数类埋点：关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。
网页缓存：对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。
网络环境：当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。
覆盖安装：产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。
服务端压力：数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。