埋点测试笔记

目录

埋点种类

埋点注意事项

基本测试点

触发时机

数据内容

常见埋点错误情况

---

埋点种类

• 前端埋点

在实际过程中，有些埋点是不用特意区分前后端的，用户的一个埋点事件在前端埋点或后端埋点都可以实现，但是需要注意的是，在实际埋点上报、数据收集等过程中会有数据丢失的情况，从这个角度来看的话，其实后端埋点要比前端埋点更有优势，前端埋点会因为一些网络问题、适配问题等等容易出现上报异常造成数据丢失且丢失后排查困难，因为前端相关的是没有记录相关操作的，只负责上报，上报成功与否没有记录。

• 后端埋点

而如果是后端埋点，无论是自己的数据系统还是第三方数据系统都是可以通过自己系统本身相关的数据库查询或记录日志等操作进行埋点数据的校验排查，所以针对一些比较重要的埋点，还是建议以后端埋点为主，必要时通过记录日志或记入数据库等方式对相关数据进行二次记录以便进行数据核实。
 

埋点注意事项

• 编码格式：埋点数据的值为中文时，尤其要注意编码格式。为了避免服务端解析数据出错，一般情况下，客户端需要对发出的数据进行编码格式转化；
• 大小写：埋点数据的值在命名时要和服务端数据组同步命名规则，尤其是大小写；
• 全角半角：埋点数据的值为英文时，常常容易忽略全角半角的输入方式，有时候会因此产生无法接收的错误；
• 数据格式：埋点数据的数据格式在定义时要简单明了，尤其是非实时数据的发送机制，发出的数据量大且同一条埋点发出好多，需要整合；
• 发送时机：埋点数据发送往往是一个公共功能，且发送时机一般情况下分为两种：实时和非实时。因此将数据发送功能作为一个单独的模块存在，其他功能调用即可，避免所有模块在发送时各自处理，增加测试成本；
• 埋点数据的命名规则：埋点数据的规范化命名规则有利于数据的阅读和查看，比如页面点击的就用Page开头，区域的用Label开头作为前缀；
• 展现类的埋点：最关键的在于避免重复统计。比如在某宝搜索“华为手机”时，当用户输入了“华为MATE10手机”和“华为MATE10”出来的效果几乎是一样的，失去了统计的意义。
• 点击类的埋点：关键在于避免服务器超时的情况下连续点击导致的重复统计。
• 状态类埋点：关键在于避免统计默认状态。并且状态类埋点统计的一定是最终的状态。例如，由开切换到关，那么最后发出的状态数据一定是关闭的状态。
• 计数类埋点：关键在于避免遗漏。一般情况下，非实时发送的计数埋点容易出现遗漏情况，因为涉及到数据库的读写。因此在测试时要格外留意。
• 网页缓存：对于web页面的埋点统计，要考虑到web页缓存的问题。例如，资讯详情页有停留时长的统计，当进入资讯详情页时开始计时统计，不在该页面时结束统计，那么此时我们就要考虑到在前后台相互切换时是否存在多发的情况，之前浏览器遇到的问题就是将缓存页的时长页做了统计一并发送到了服务器。
• 网络环境：当网络特别差的时候，客户端发送埋点失败，这种情况下应该将发送失败的数据保存在本地，等下次条件满足的时候一并发出。避免出现丢掉数据的情况。
• 覆盖安装：产品升级之后，升级之前的埋点不能被删除掉，应该保存在本地，待升级之后满足条件一并发出。
• 服务端压力：数据发送有实时和非实时两种，当实时数据量特别大时容易给服务器造成压力，因此在测试时要特别留意。

基本测试点

触发时机

点击事件：

• 若前端做了防抖动、节流，在重复点击产生有效点击后，只上报一次，反之点几次上报几次
• 各端对同一个tab的点击效果不一致，考虑双击逻辑，需明确各端的上报策略

曝光事件：

• 屏幕停止滑动且视图元素在可视范围内露出超过50%，则上报
• eg：0% -> 50%（上报第一次）-> 30%（不上报）-> 60%（上报第二次）-> 100%(不上报)
• 页面切换、app退出、app进入后台后，再回到页面，重新计算曝光
• 元素被弹窗遮挡，下拉上滑系统菜单，都不重新计算曝光
• 露出的判断：先判断视图元素是否可见，再计算视图元素的面积
• 包括水平露出、垂直露出

浏览事件：

• 页面首次加载/渲染成功上报
• 刷新不上报
• 页面打开后立刻退出app不上报
• 首次进入页面，返回上一级后再进入、进入子页面后返回、切换tab，若能拿到请求数据，则上报
• 再次进入页面，从任何页面进入该页面，无论是否请求了数据，无论请求数据是否成功，都上报

数据内容

检查上报的内容是否正确

常见埋点错误情况

        a)漏埋点

        b)埋点和操作类型不对应，比如点击的是“下一步”，却上报了“返回”

        c)埋点和操作频率不对应，比如只操作了一次，却上报了两次