1、埋点是什么
埋点又称为事件追踪（Event Tracking），指的是针对用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。用大白话说：就是通过技术手段“监听”用户在APP、网站内的行为。
2、埋点的作用
如果我们想要收集用户行为数据，就可以通过埋点来实现。
- 比如想要了解一个用户在APP里面点击了哪些按钮，看了哪些页面，做了哪些事情等。
- 再比如想要了解有多少人用过某些功能，使用的频率次数等。
3、埋点的使用--数据流整体介绍
3.1、实时数据
![]()
- 实时数据源头从点击流开始，客户端SDK上报埋点数据，采集服务会将上报的埋点写入JDQ写集群，然后通过fregeta任务将数据汇总到JDQ读集群。
- 下游flink任务会从读集群消费原始topic，然后将加工后的topic吐出，供下游业务消费。
- 下游业务如：黄金眼、商智、搜推广等。
3.2、离线数据
![]()
- 离线数据源头从点击流开始，客户端SDK上报埋点数据，采集服务会将上报的埋点写入cfs网盘，然后通过离线抽数服务将数据落入数仓。
- 数仓会经过多层加工，将数据处理成为业务需要的口径，提供给数据应用使用。
- 下游业务如：黄金眼、商智、搜推广等。
4、埋点相关团队
各团队职责：
![]()
5、埋点流程
![]()
5.1、业务产品提需
- 业务产品首先将需求提给埋点产品
- 需要注意的点：埋点相关的需求新增或变更，都需要提给埋点产品走子午线平台。
- 线上问题：20230527京东APP小程序加购解析失败，就是因为需求比较紧急，没有走子午线，产品自己维护了文档，导致字段修改后，下游无法解析。
5.2、设定埋点方案
•埋点产品接收到需求之后，启动评审会，评审需求是否合理、是否遗漏、参数是否完善、是否需要通知第三方业务、确定排期等。
- 埋点产品会根据评审结果，在子午线制定埋点方案
- 埋点产品产出埋点方案后，会拉业务、开发、测试、数据侧共同参与方案评审，确认方案是否完整、参数是否合理
![]()
5.3、埋点开发
- 前端研发拿到埋点方案之后，按照埋点方案进行开发
- 需要注意的点：开发需要在约定埋点上线的版本分支开发，注意不要提前跟版上线
- 线上问题：2023年10月12日搜索结果页小时达相关订单指标下降，就是因为埋点没有经过测试，提前发版，导致下游无法解析
5.4、埋点测试
- 开发完毕后提测，测试需要进行上报规则验证，详见：6.2.2、上报规则用例
- 测试在track平台对埋点进行字段验证，详见：6.2.1、字段验证用例
- 验证完毕后，输出测试报告。详见：6.3.3、track平台使用
5.5、埋点验收
- 埋点产品对测试产出的测试报告中的测试记录进行验证
- 同时进行数据的落表验证
5.6、埋点上线
- 验收完毕后，子午线对应的版本状态修改为上线
- 前端跟版上线
- 需要注意的点：开发每次需要使用最新线上master分支拉新的开发分支，上线前合并代码时，确保拉分支到现在过程中没有其他上线，如果有的话需要重点关注，避免覆盖上次上线的内容。
- 线上问题：2023年10月18日京霄LBS相关业务看板数据异常，就是因为上线合并的分支覆盖了上一次上线的正常版本，导致上报出错。
6、埋点的主要质量保障--埋点测试
6.1、埋点常见问题
常见问题大概有几种：
- 埋点需求没有走子午线，上报内容错误
- 业务在修改逻辑时，忘记修改埋点上报
- 埋点上线时没有做好上下游同步
- 新增字段数据结构下游无法兼容
6.2、埋点测试用例--上报内容的质量保障
6.2.1、字段验证用例
- 验证埋点上报与方案中设置的字段名称、字段类型是否一致
- 如果埋点方案有标注参数长度，或者参数为枚举时，需要验证
- 如果为嵌套json，需要注意不破坏原有json结构
6.2.2、上报规则用例
1）pv场景
场景1：正常进入页面
- 行为：正常进入pv页面并停留
- 预期结果：正常只上报1条pv埋点，且page_id、page_param和文档保持一致
- 特殊场景：
▪tab嵌套页面场景：进入时只上报1条主tab pv埋点，切换tab时上报另外一个tab的pv埋点，如出现进入时出现2条pv埋点(1条外层大框架pv埋点，1条主tab pv埋点)，则上报错误；重复切换tab不会再次上报相同页面pv
▪正常进入页面时无pv埋点上报，切换相关tab时才会上报埋点
▪进入页面时无pv埋点上报，离开页面时才上报pv埋点
场景2：回退到该页面场景
- 行为：正常进入A页面并停留，再在该场景下点击某一元素进入到下级B页面，再回退到该A页面
- 预期结果：原生会上报3条pv埋点，分别为A、B、A，且A页面的page_id、page_param和文档保持一致，h5回退不会上报pv埋点
- 易出现问题：回退页面不上报A页面pv埋点
场景3：快速离开页面场景（主要解决pageParam参数中存在服务端下发参数，如果接口未响应，pv埋点也需要正常上报）
- 行为：正常进入页面并快速离开该页面
- 预期结果：正常上报1条pv埋点，且page_id、page_param和文档保持一致
- 易出现问题：
场景4：下拉刷新场景
- 行为：正常进入页面，然后下拉刷新
- 预期结果：下拉刷新不会再上报pv埋点
- 易出现问题：
场景5：APP切至后台或锁屏场景
- 行为：正常进入页面，然后APP切至后台或锁屏，再次打开或解锁
- 预期结果：不会再上报pv埋点，依据规范
- 易出现问题：
2）点击场景
场景1：进入页面不点击
- 行为：不点击对应元素
- 预期结果：依据埋点文档，如未要求默认上报，则此处不会上报点击埋点（部分埋点有默认点击埋点的逻辑，该种场景符合预期）
- 易出现问题：
场景2：正常点击
- 行为：正常点击对应元素
- 预期结果：正常上报1条点击埋点，且event_id、page_id、page_param、event_param、json_param、et_model和文档保持一致
- 易出现问题：
场景3：点击无跳转（无功能触发，无交互变化）
- 行为：正常点击无交互的对应元素
- 预期结果：不上报点击埋点事件
- 易出现问题：
场景4：滑动埋点
- 行为：滑动浏览后停止
- 预期结果：上报点击埋点事件
- 易出现问题：
3）曝光场景
场景1：正常进入页面，此时未漏出该元素（测试曝光元素的是否未漏出就上报）
- 行为：正常进入页面，此时未漏出该元素，然后离开该页面
- 预期结果：不会上报对应的曝光埋点
- 易出现问题：未漏出就进行曝光埋点的上报
场景2：正常进入页面，此时该元素已漏出展示(需要分别测试该元素刚刚漏出、漏出50%、漏出100%的场景，确保和埋点文档中元素曝光的空间限定、时间保持一致，测试曝光元素的上报时机及空间限定）
- 行为：正常进入页面，此时该元素已漏出指定比例，然后离开该页面
- 预期结果：该元素上报时机 = 埋点文档内的要求的上报时机(漏出上报 or 离开页面时上报)，上报参数保持一致
- 易出现问题：
▪埋点文档要求离开页面上报曝光，实际为漏出就上报，反之亦然。
▪埋点文档要求漏出100%才算曝光，实际漏出一px像素就上报埋点
▪曝光逻辑两端不一致，安卓和ios的曝光数据量相差极大
场景3：测试曝光元素的上报时机
- 行为：正常进入页面，此时该元素已漏出100%，分别触发不同的离开页面场景：进入下级页、返回前页、刷新页面、切换到其他tab页面、进入后台5种场景
- 预期结果：该元素对应曝光上报次数 = 埋点文档内的要求的次数
- 易出现问题：埋点文档要求离开页面上报曝光，实际为漏出就上报、或者离开页面场景漏掉某种场景，导致曝光数据未及时上报
场景4：正常进入页面（测试曝光元素的页面内去重逻辑）
- 行为：正常进入页面，上下滑动页面使得该元素重复出现2次，之后再离开页面，
- 预期结果：该元素对应曝光上报次数 = 埋点文档内的要求的次数（是否页面内去重，只上报一次曝光）
- 易出现问题：
场景5：正常进入页面（测试曝光元素的返回上报逻辑）
- 行为：正常进入页面，上下滑动页面使得该元素出现，之后再进入下级页面或其他tab页，再从下级页面返回，再离开该页面
- 预期结果：从下级页面或其他tab页返回后上报对应元素的曝光
- 易出现问题：
▪要求返回重新上报曝光，实际返回后未重新上报
场景6：曝光数据的下拉刷新场景（测试曝光元素的下拉刷新上报逻辑）
- 行为：正常进入页面，该元素100%出现，然后下拉触发页面刷新
- 预期结果：下拉刷新后再次上报
- 易出现问题：
▪要求刷新后重新上报曝光，实际未上报
6.3、埋点测试工具--track平台
6.3.1、平台简介
Track是APP、M、小程序全域一站式埋点质量平台。支持代理、扫码的方式无痕收集埋点，并通过统一规则中心对埋点数据进行自动校验，方便测试、开发、产品、业务快速高效的查看测试埋点。同时能够在埋点自测、冒烟、回归等环节，通过遍历技术对埋点进行自动化测试，节约人耗，提高了埋点质量的效能。
6.3.2、平台使用
1）生成埋点方案
![]()
此处需要，在子午线维护好的埋点方案链接。
![]()
2）生成后选择此埋点方案
![]()
3）选择好后，上报方式，选择扫码上报
填好对应的站点，生成二维码，使用相机扫码，打开app就可以上报了
4）触发需要测试的埋点事件，会在下方实时上报里出现，选择对应的事件，右边会出现上报的字段信息
![]()
5）对比字段，进行测试结果打标，打标之后生成测试报告。
作者：京东零售 张宇洵
来源：京东云开发者社区 转载请注明来源
