写点什么

浅谈埋点及其质量保障 | 京东云技术团队

  • 2023-11-22
    北京
  • 本文字数:3433 字

    阅读完需:约 11 分钟

浅谈埋点及其质量保障 | 京东云技术团队

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)对比字段,进行测试结果打标,打标之后生成测试报告。


作者:京东零售 张宇洵

来源:京东云开发者社区 转载请注明来源

发布于: 刚刚阅读数: 5
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
浅谈埋点及其质量保障 | 京东云技术团队_大数据_京东科技开发者_InfoQ写作社区