云音乐曙光埋点：还原数据理想国

图片来源：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

曙光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

EasyInsight是曙光建设的埋点管理平台，在数据埋点的事前中后均起着非常重要的作用，平台的整体包含的功能简介如下图所示，其中已经完成的为需求管理和参数管理，以及测试稽查中的需求测试部分。有关回归稽查、动态取参、以及后续更多扩展开发写此文时尚在进行中。

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

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

事后平台提供了需求维度的自动化测试工具，以及版本能力的集成灰度和线上数据稽查功能，开发可快速自行验证后上线。需求测试中，开发通过二维码扫描与平台socket连接，保障埋点数据的实时性，并与平台上维护的对象关系和参数配置生成的埋点规范进行对比验证。而回归稽查功能要更复杂，尤其对于客户端大量需求集成集中发版的情况，我们做了不少工作结合内部的研发管理工具与EasyInsight打通，关联版本相关任务的代码合并状态，在平台找到合适的版本与其产生的埋点ODS分流后进行撞库校验。测试和稽查的结果均有完整的报告和IM通知输出。

EasyInsight除了埋点开发过程管理外，埋点上线后其上沉淀的元数据和对象信息，亦是后续数仓开发、BI分析、算法使用的主要内容；同时相关的可视化敏捷数据分析能力亦在建设中，基于整体数据埋点的高度标准化，常见的多维、漏斗、留存、路径等分析诉求，可以简单快速拖拖拽拽进行配置查看。

数据治理

曙光埋点建设时，云音乐已经存在了诸多版本的埋点数据，多种口径和规范并存，整体的数据使用较混乱，在方案落地时深感不进行全面的改造和梳理对齐，新的埋点体系建设得再好如果仅是覆盖新需求不管老埋点，各种业务报表以及业务和算法任务混用时，亦是无法保障准确性的。因此，新方案建设，新埋点开发落地，老埋点梳理对比验证三条腿缺一不可，均纳入了曙光项目的范畴内。过程中牵动数据开发、策划、BI、算法以及各个业务服务端开发进行了详细的旧使用梳理，并也以此为契机将云音乐的数仓能力丰富标化建厚。

整体的新老数据兼容方案如下图，由于埋点的改造不是集中投入一次改完，是随着业务迭代持续进行，故需要对老埋点进行口径的二次梳理(将老的非标化的埋点依据各种参数条件通过UDF映射成一个伪spm)，依据新老spm映射通过中间表兼容新老数据，将原本下游直接从ods直接分流使用(图中红线)的任务切换到统一的中间表或兼容流量表上。

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

后记

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

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

本文发布自网易云音乐技术团队，文章未经授权禁止任何形式的转载。我们常年招收各类技术岗位，如果你准备换工作，又恰好喜欢云音乐，那就加入我们 grp.music-fe(at)corp.netease.com！