关于埋点:云音乐曙光埋点还原数据理想国

6次阅读

共计 6618 个字符，预计需要花费 17 分钟才能阅读完成。

图片起源：https://unsplash.com

本文作者：渔夫

进入挪动互联网的下半场，以用户行为数据分析驱动的算法个性化举荐和人工精细化经营已成为各个产品必不可缺的配置，数据成为各产品的外围竞争力之一，各厂均开始致力于建设本人的数据仓库和数据中台。其中埋点作为互联网产品的次要数据起源起着至关重要的作用，从下图可见是整个数据链路的起源，决定了整个数据体系的品质和能力。然而埋点因其生产生产链路太长，体现不对用户间接可见，过程中信息传递和积淀艰难等起因，使得埋点往往存在问题多发现晚保障老本低等特点；且随着业务倒退到不同阶段，对于数据埋点的能力诉求亦会变动，但往往后续治理也是十分艰难。

云音乐作为一个典型简单内容产品，蕴含了多种内容介质（歌曲 / 播客 / 视频 / 动静 / 评论 / 直播 / 歌房等），多种组织模式（歌单 / 播单 / 专辑 / 话题 / 云圈等），多种用户身份（音乐人 / 达人 / 普通用户 / 主播等），以及十分多内容散发场景（举荐流 / 搜寻 / 榜单 / 专区等），具备了一个典型内容产品对散发效率敏感的特点，因而在整体流量 / 内容 / 用户等多个域内都具备非常复杂的用户生产数据和行为剖析诉求。这对端上标准化和全面埋点提出了极高的挑战，产品决策 /BI 剖析 / 数仓开发 / 算法举荐等诸多方面均须要有一套整体高效稳固标准化的埋点设计来撑持。然而过往历史中，因计划建设不佳历史包袱重，埋点始终是业务突出痛点，存在如下图几个方面问题。

基于此背景，笔者联结网易杭州研究院及云音乐内诸多部门成立曙光埋点我的项目，设计方案推动共建优化落地，目前已根本实现外围建设并在搜寻、播客、首页举荐等外围业务上实现落地和数据革新，剩平台的数据回归稽查能力、搭建买通以及若干易用性优化，以及更多的业务落地治理在 22 年收尾。

要实现埋点提效提质，须要在埋点定位规范、埋点机会口径、参数设置收集等方面进行良好设计晋升信息精确表白升高出错可能，并且须要在各个环节开发各种工具和平台去赋能，综合察看了业界各家的解决，整体在如下方面各有偏重。

在坑位定位方面，鉴于大前端的 DOM 树布局渲染模型，很容易联想到用坑位节点本身在树上的地位去进行形容。基于此，Mixpanel、GrowingIO、神策、以及网易的 HubbleData 等抉择了 x -path 形容法，因 x -path 全自动埋点量大及无更多业务参数，均联合端主动截屏，IDE 和平台联合，进行更多的坑位圈选参数设置；以及采纳一些形容优化伎俩升高层级、类型和地位变动对 ID 的敏感水平。但始终无奈从根本上解决定位形容的稳固标准化和不同端的一致性形容问题，计划难以利用到外围的业务报表，以及线上算法应用上。

腾讯、美团、字节、快手等建设联合坑位示意图、参数治理进行面向坑位的埋点准确治理，定位形容由平台随机生成或策动按默认标准输出，埋点参数均由开发面向坑位手动设置无层级上下文汇总收集，并联合 IDE 插件买通开发和测试赋能进行提效（可参考：字节跳动大规模埋点数据治理最佳实际）。其中美团在外部的动静布局上与 x -path 找到了不错的结合点，买通实现坑位圈选定位 (x-path) 和模型对应的参数配置，建设 MTFlexbox 上的可视化主动埋点，实现了埋点的齐全策动 /BI 自助化。

阿里通过四段式 SPM(站点. 页面. 页面区块. 区块内点位)和 SCM(投放零碎 ID. 投放算法 ID. 投放算法版本 ID. 投放人群 ID) 进行地位和内容的标准化形容，开发亦是面向坑位进行坑位进行标识和参数设置，无层级上下文汇总收集，在埋点上各端均做了 AOP 实现自动化，并通过截图图像编码买通平台进行更多业务参数的可视化配置。网易严选亦采纳了与阿里类似的计划。

能够看到各个大厂在支流大产品中均未采纳类 x -path 的定位形容自生成以及上下文参数根据汇总收集方面的建设。而云音乐新近亦采纳类似的治理计划，坑位的定位形容采纳过平台随机生成以及四段式 SPM。然而因为云音乐自身简单内容社区型产品存在的大量资源散发组织模式，以及外部工程化建设背景，如下图所示，一个歌单和动静均会在诸多场景和模块分区中呈现，而采纳业界现有的各种治理方法，即便端上歌单卡片组件是对立复用的，然而其埋点亦需随着场景组合状况的减少和出现极大水平的扩张，使得埋点开发在工作量和品质以及标准化方面均始终很痛。

基于内容型产品自身业务和架构特点(后续会输入文章进行专门解说和剖析，敬请关注)，要彻底解决问题满足业务需要，仍然须要思考类 x -path 型的页面层级上下文自定位自汇总的计划，只是咱们须要通过肯定伎俩去解决业界始终未能无效解决的精确稳固一致性难题。

其中在上下文参数的自汇总收集方面：西瓜视频基于责任链模式，在业务层进行了相干父子层级参数的汇总收集，不过会对业务存在较强的侵入性，且不彻底。腾讯 PCG 数据中台的大同埋点平台亦联合 DOM 树的 UI 层级进行各级参数的主动收集和汇总格式化，然而大同治理平台自身做得较差，且采集 SDK 的计划不够彻底泛化，能力无限保护艰难，未彻底走向虚构对象树建设这条路。

在曙光埋点中，思考到 x -path 的地位形容其实存在较多无数据意义的层级且这些层级又往往随着端上同学的款式重构批改而变动(往往会有容器层级的新增或类型批改)，而在理论埋点中往往仅须要关注的是蕴含若干层级的资源卡片、模块频道容器、互动组件等，如果能够仅将这些层级标注进去并进行自汇总，那么定位的形容如果产品设计层面未产生需要变动的状况下，就是稳固易懂且可多端统一的(毕竟不同端上产品设计是统一的)。基于此，引入了如下所示的埋点对象概念，在整个 DOM 树中，通过 oid 去标识所须要的对象层级(图示意用，理论层级比画出的更多，仅红色 - 页面和蓝色 - 元素的层级进行 oid 标记)，借助 DOM 树的构造，天然造成了一个稠密的埋点对象树。

整个曙光埋点的根本思维就是要在端上 (客户端 & 跨端 & 前端) 构建页面的埋点对象树并放弃同步更新，实现页面和元素曝光的主动埋点，以及通过用户行为 API 的 Hook 实现点击的主动埋点。

如上图示意，曙光建设了业务无感的主动埋点 SDK，主动生成和更新页面的对象树，实现曝光和点击事件的自动化埋点，在坑位埋点生成时从对应节点往上查找到根对象节点，收集树支上所有节点业务设置的参数，即可主动生成坑位的标准化地位 SPM 和内容 SCM 形容；在此基础上 SDK 内有序记录了相干埋点事件，辨认出途中用户操作行为，间接在埋点生成时按约定格局生成和记录 refer 参数，以进行高效精确的行为归因。同时亦能够看出，该计划对于组件化的内容型架构特地敌对，对于卡片在不同场景再复用再组织的状况，卡片自身是无需再反复埋点的。计划中波及的相干参数规范和埋点构造约定如下，列出了次要要害参数及含意。

在此基础上，建设相应埋点平台来进行埋点需要治理、参数等元数据管理、以及埋点测试和稽查校验等，整体造成了如下流程：

回到上文的痛点剖析，配合 SDK 和平台，以及基于曙光埋点的后续 UI 自动化等的能力建设，咱们针对于各个痛点的解决思路能够总结如下：

曙光 SDK 是整个计划实现的外围，其整体蕴含内容如下，以后已实现 Android，IOS，WEB，RN 四端的反对：

为了更好标准化，咱们将规范的事件限定成曝光和点击两个大事件，再通过对象的 spm 和 scm 去辨别具体的事件业务含意。比方，老的埋点计划中(个别业界也多采纳这类定义)，端上的关注事件会定义 EventCode 为 ”focus”，在曙光中会间接定义成能够产生关注行为的元素点击操作(个别会采纳雷同 oid==btn_focus 来对立定义)，故整体上点击事件的表现力是比拟充沛的。而曝光上，咱们辨别了页面和元素，页面的曝光和反曝光会触发对应节点往下的元素曝光检测，且页面节点根据其所处层级不同有根页面和子页面辨别，但业务开发无需关怀，只需 API 设置 elementOID 和 pageOID。基于此，SDK 的根本外围性能就是在各端通过 SDK 去实现页面 / 元素曝光和点击事件的主动埋点，并自动记录和关联用户行为。目前在 Android、IOS、WEB 三端的 SDK 解决流程如下图所示。

图中要害流程：通过零碎 AOP 触发树更新，在主线程根据页面理论 DOM 树的遍历过滤出 OID 节点生成虚构树，将树更新事件推送给曙光工作线程去进行视图的可见遮挡穿插判断以进行曝光埋点的主动生成，进而在工作线程根据树结构进行埋点节点的树枝回溯收集相干节点的参数进行架构化；同时在工作线程中保护了用户行为链路的 refer 参数（由页面曝光、元素点击、用户自定义和插入 refer 组成），这些 refer 参数会在埋点中被间接带上，供数据侧生产归因。

图中绿色圆圈为凋谢给业务开发应用的 API，其蕴含了节点的参数设置、被动触发刷新（局部极非凡状况页面更新未被 AOP 的业务可自行触发）、自定义埋点事件、未 AOP 的 Refer 插入等四局部，整体操作很轻量，最次要的节点参数设置 API 与各端给 View 设置显示数据的理论可保持一致，且各层只需关注本人的参数，所处的父级模块、页面等信息由 SDK 在埋点回溯时主动收集。

当然这是现实状态下的主流程，在整体计划中在前端和客户端均会存在非凡状况须要去抹平，如图中粉色背景的方块中，在生成 vTree 的过程中，为了尽可能达到多端统一，以及满足业务数据需要的状况，咱们反对了逻辑挂载来将一个节点脱离自身 View 父子关系建设新的父子关系（如上图左，点击歌曲更多关上的浮层可能是一个独立 Window，与歌单页和外部的元素无父子关系；然而在数据分析上，会心愿看到浮层内的各个点击能够看到歌单页以及对应歌曲卡片的信息，这时候能够抉择将浮层对象逻辑挂载到歌单卡片或者歌单页对象下），以及虚构层级以反对对本来不存在的 View 父子层级减少一个可剖析的数据层级（如上图右，对于模块内的各个歌单和歌曲卡片以及头部的更多、播放按钮的埋点事件，会须要晓得所属的模块信息，但端上可能并不存在整个模块的层级 – 图中红色虚线，只是头部和下方横向滚动列表在整体列表上的拼接假象，对于端开发同学为了缩小 UI 层级这种状况是比拟常见的，此时能够通过减少一层与虚线红框对应的虚构模块节点来疾速达到目标）。

SDK 内对于 View 的曝光可见性也做了较为齐备的扩大反对和判断，业务能够通过 API 去批改 View 的理论 Frame(显示 Rect，以便反对半透理论背地可见等状况)。同时，在曝光检测中，也以节点的可见区域和树结构，做了严格的遮挡比照判断，整体准则和流程如上图所示。

如上为 Android、IOS、WEB 三端的整体状况，其中 WEB 端的计划基于 DOM 而非 VDOM 操作，能够适配各种不同前端技术栈。对于 RN 类 Native 渲染的跨端平台，其在 JS 端放弃与 WEB 端雷同的 Component 配置 API，而后客户端通过 ViewManager 扩大属性，将相干节点配置对应到 Native 侧的理论 View 节点即可，其余流程与原生是统一。另外，对于 Flutter，Android 端的 Compose 这类渲染框架，亦可在其理论布局节点树上找到切入点，构建出对应的埋点对象树结构，更多端后续会持续反对，同时 SDK 打算往年开源，更多细节届时再披露。

Android 端 BaseViewManager 中扩大：@ReactProp(name = "eventTracing")
public void setEventTracing(@Nonnull T view, @Nullable ReadableMap eventTracing) {// 调用客户端侧曙光埋点 SDK 的节点设置 API}

IOS 端 RCTViewManager 中扩大：RCT_CUSTOM_VIEW_PROPERTY(eventTracing, NSDictionary *, RCTView) {// 调用客户端侧曙光埋点 SDK 的节点设置 API}

除了 SDK 的外围性能之外，曙光我的项目还开发了一个工具，以反对各端间接进行对象和层级查看，辅助开发测试，并且随着计划的落地和规范数仓的开发，后续亦可在端上间接做数据可视化，整体成果如下，具体细节不再赘述。

EasyInsight 是曙光建设的埋点治理平台，在数据埋点的事先中后均起着十分重要的作用，平台的整体蕴含的性能简介如下图所示，其中曾经实现的为需要治理和参数治理，以及测试稽查中的需要测试局部。无关回归稽查、动静取参、以及后续更多扩大开发写此文时尚在进行中。

事先其承载埋点元数据管理，埋点需要提出、埋点设计、评审和任务分配。

事中开发同学根据对象详情页里的参数需要，根据层级 (血统) 关系判断适合的层级和组件进行埋点参数设置，平台在对象层面保护了无关对象和 SPM 所需的各种公参私参，对相干参数的取值状况进行配置，并通过父对象的保护构建起一个个复用下页面的对象树，同时还提供了血统树的残缺视角，更显直观。

预先平台提供了需要维度的自动化测试工具，以及版本能力的集成灰度和线上数据稽查性能，开发可疾速自行验证后上线。需要测试中，开发通过二维码扫描与平台 socket 连贯，保障埋点数据的实时性，并与平台上保护的对象关系和参数配置生成的埋点标准进行比照验证。而回归稽查性能要更简单，尤其对于客户端大量需要集成集中发版的状况，咱们做了不少工作联合外部的研发管理工具与 EasyInsight 买通，关联版本相干工作的代码合并状态，在平台找到适合的版本与其产生的埋点 ODS 分流后进行撞库校验。测试和稽查的后果均有残缺的报告和 IM 告诉输入。

EasyInsight 除了埋点开发过程治理外，埋点上线后其上积淀的元数据和对象信息，亦是后续数仓开发、BI 剖析、算法应用的次要内容；同时相干的可视化麻利数据分析能力亦在建设中，基于整体数据埋点的高度标准化，常见的多维、漏斗、留存、门路等剖析诉求，能够简略疾速拖拖拽拽进行配置查看。

曙光埋点建设时，云音乐曾经存在了诸多版本的埋点数据，多种口径和标准并存，整体的数据应用较凌乱，在计划落地时深感不进行全面的革新和梳理对齐，新的埋点体系建设得再好如果仅是笼罩新需要不论老埋点，各种业务报表以及业务和算法工作混用时，亦是无奈保障准确性的。因而，新计划建设，新埋点开发落地，老埋点梳理比照验证三条腿缺一不可，均纳入了曙光我的项目的领域内。过程中牵动数据开发、策动、BI、算法以及各个业务服务端开发进行了具体的旧应用梳理，并也以此为契机将云音乐的数仓能力丰盛标化建厚。

整体的新老数据兼容计划如下图，因为埋点的革新不是集中投入一次改完，是随着业务迭代继续进行，故须要对老埋点进行口径的二次梳理 (将老的非标化的埋点根据各种参数条件通过 UDF 映射成一个伪 spm)，根据新老 spm 映射通过两头表兼容新老数据，将本来上游间接从 ods 间接分流应用(图中红线) 的工作切换到对立的两头表或兼容流量表上。

兼容表的流量切换，EasyInsight 也提供了工具化反对，如下图所示：

曙光在实现埋点落地和数据治理的同时，云音乐也曾经基于曙光多端统一明确的 oid 和 spm，解决了业界基于 x -path 和 Accessibility 的各种 UI 自动化计划未曾基本解决的对象精确疾速查找和用例稳定性差及运行效率低问题，建设了全新的自动化计划获得了很不错的成果（后续会再写一篇文章总结下大前端的各种自动化计划的建设思路和痛点以及基于曙光的自动化计划，敬请关注）。同时，以曙光为根底的更为齐备的平安风控策略，新 AB 零碎，以及可视化剖析能力，也在启动进行中。曙光埋点起于埋点但意在更多，这也是如开头脑图所示最后立项所预期的。

数据埋点治理是一个极辛苦且艰难的事件，如同在给一辆高速行驶的火车换轮子，在任何一个公司做起来都不会轻松，有幸在云音乐失去了老板的反对，跨团队圈了几位很不错的小伙伴，在绝对投入很小的状况下用不长的工夫就做到了很不错的完成度。期间困难重重，我的项目团队同学们几度没了信念，不过最终都挺过去了。随着外围业务的落地和业务的切换反馈，各方对其也投入了越多越多的器重和期待。回望去路感恩满满，可能将心里长期构想的数据埋点理想国还原进去，是一件人生幸事。