导读

本文核心内容聚焦为什么要埋点治理、埋点治理的方法论和实践、奇点一站式埋点管理平台的建设和创新功能。读者可以从全局角度深入了解埋点、埋点治理的整体思路和实践方法，落地的埋点工具和创新功能都有较高的实用参考价值。遵循埋点治理的方法论，本文作者团队已在实践中取得优异成效，在同行业内有突出的创新功能，未来也将继续建设数智化经营能力，持续打造更好的服务。

一、埋点治理背景

1.1 埋点数据的价值

随着线上流量红利高峰逐渐达到瓶颈，在精细化运营、数智化运营的大背景下，越来越多的公司开始认识到数据的重要性，并将其打造成为公司的核心资产，以数据为中心驱动业务发展。而埋点数据作为企业内部最重要的两大来源（埋点数据、业务数据）之一，其重要性不言而喻。

埋点是一种常用的数据采集方法。基于业务需求或产品需求，在应用页面中植入数据采集代码，监听用户各种行为事件（页面浏览、关闭，元素曝光、点击等），然后将采集的数据上报至服务端，服务端分别下发到大数据平台和搜索、推荐等各业务系统。通过分析数据，追踪用户行为和应用使用情况，推动产品优化或指导运营；通过实时的获取用户点击、浏览、停留等行为作为关键特征提供给搜索、推荐、广告等系统，来提升智能分发的转化和用户体验。

埋点数据上能影响业务运营数据分析、智能推荐、AB 实验的准确性，下能影响数据仓库结构设计和数据采集团队的维护成本。

1.2 业内主流埋点方式的对比

从技术层面上，埋点分为代码埋点、可视化埋点、无埋点/全埋点。目前国内主要的第三方数据分析服务商和大型公司内部普遍支持。代码埋点又衍生出了声明式埋点、无痕埋点、服务端埋点等丰富的埋点方式。

通过多种埋点方式组合，可以在不同场景业务中灵活使用。比如在页面中元素或页面事件使用前端代码埋点；在 Debug 链路长的搜推代码中使用服务端埋点；产品运营等非研发使用可视化埋点。

1.3 为什么要治理埋点数据

然而随着业务的迭代变更，部分埋点数据失去效用。为了确保数据的质量、效率、安全、标准及易用性，需要对埋点数据进行治理。不仅是存量数据的治理，新增数据更是要保证从源头开始就是正确的。在埋点数据的生命周期内，每个环节制定原则性的管理方法和具体的落地措施。一个稳定的治理链路是埋点治理的基石。

从平台视角来看，埋点治理要解决的问题如下：

质量问题：最重要，大部分公司的数据部门启动数据治理的起因就是数据质量存在问题。例如数仓的及时性、准确性、规范性，以及数据应用指标的逻辑一致性等。

成本问题：互联网行业数据膨胀速度非常快，大型互联网公司在大数据基础设施上的成本投入占比非常高，而且随着数据量的增加，成本也将继续攀升。

效率问题：在数据开发和数据管理过程中都会遇到一些影响效率的问题，多是靠 “盲目” 地推人力在做。

安全问题：业务部门特别关注用户数据，一旦泄露，对业务的影响非常之大，甚至能左右整个业务的生死。

标准问题：当公司业务部门比较多的时候，各业务部门、开发团队的数据标准不一致，数据打通和整合过程中存在很多问题。

从业务视角来看，埋点治理要解决的问题如下：

埋点数据 “全”： 因整体协助链条非常长，许多时候在需要做数据分析时，才发现页面有部分功能漏报埋点，产品需求未涉及等。

埋点数据 “准”：需求开发测试阶段，往往重点关注业务逻辑，对于埋点上报这些辅助异步流程，设计评估不准确。会存在因验证不充分而导致数据不准确的情况。

埋点数据 “快”： 推荐算法主要依赖数据驱动，埋点数据需要及时上报并反馈，推荐等智能应用系统才能根据用户当前行为给出精准的策略决策。

埋点数据 “统一”：智能场景往往要通过多个业务线交叉数据作为输入特征或算法画像，每个业务线如没有统一标准规范，数据处理计算逻辑复杂且迭代维护成本很高。

埋点数据 “链路长”：埋点数据从生产到使用，涉及运营、产品、研发、测试、数据分析师或算法工程师多个环节（如下图），问题沟通排查链路长。

埋点数据 “历史长”：页面埋点随需求迭代更新较快，历史埋点设计文档缺少统一管理，不利于长期维护。

二、埋点治理实践

为解决上述问题，几经探索总结经验后，本文作者团队为埋点治理制定了全面的标准制度。遵循相应的制度，使得埋点治理工作有序有效开展。

2.1 制定全链路标准

作者团队制定了一套覆盖数据生产到使用，全链路的数据标准方法，从埋点数据定义、采集、验证、指标定义到数据生命周期管理都建立了相应环节的标准化的研发规范，发布了《埋点流程规范标准》。

2.2 制定埋点流程规范

作者团队制定了完整的埋点上报规范规程，并邮件通知各部门产研按流程，照规范上报数据。上报流程为埋点方案设计、埋点方案配置、埋点开发/测试、数据存储/服务、数据应用五个环节，每个环节都要通过必要的步骤才可继续向下执行。

2.3 建设一站式埋点管理平台

奇点埋点管理平台是科技内部统一的埋点平台，覆盖埋点数据定义、采集、生产、验证、基础指标应用、数据质量监控治理等埋点全生命周期。做到了埋点元数据统一管理，埋点信息查询简易化、埋点上报验证一键化、埋点数据质量追踪可视化。

2.4 成立组织保执行

通过和数据技术产品部门合作，在两个部门领导的支持下，作者团队成立了埋点治理盘古项目及埋点数据管理委员会。平台研发部团队是采集埋点数据工具的产研方，数据仓库体系是由数据技术部负责建设，所以以这两个团队作为核心，并由这两个团队负责联合各个业务线团队，一起完成数据治理各个环节工作和流程的保障。

奇点团队作为埋点数据采集和管理的主力，负责数据采集 SDK，数据上报、清洗、存储、查询，埋点管理平台等。

2.5 宣导埋点和数据文化

过去由于数据文化的缺失，很多业务方意识不到规范埋点的重要性。未正确录入页面埋点信息、使用低版本采集 SDK，造成了大量不符合标准的数据。组织培训会和埋点规范宣讲，推动数据合理规范上报，也是埋点治理的重点工作之一。

三、埋点治理阶段性成果

作者团队提供的数据采集服务范围除了京东科技下金融科技、京东云、数字城市等全部业务线外，还扩展到了京东物流等兄弟部门。

奇点针对金融业务深耕多年，对数据的安全性、稳定性、实时性有多种保障方案，已是业务运营过程中不可或缺的重要环节。奇点管理平台现已实现埋点管理、数据分析一体化。在埋点数据上报查询、数据监控、数据计算可视化展示等各个环节都有相应的管理工具。

3.1 埋点验证工具

过去验证上报数据是否准确，需要测试人员申请数据库表权限，然后手写 SQL 查询数据。为此作者团队做了埋点验证工具，既可以扫码查看本机实时数据、查看所有上报实时数据，也可以一键检测上报数据是否符合规范。该工具为测试人员节省了大量时间，也为埋点治理，推动用户规范录入起了辅助作用。奇点服务端使用 Lua 脚本并发处理，而不是传统的 Web 服务，处理请求速度更快，减少了服务器资源使用。实时数据存放在 ES 中，相比 MYSQL 数据库能容纳更多的数据量，查询速度更快。

3.2 埋点验证工具

作者团队在客户端数据上报、服务端数据转换、数据发送、落仓等每步都加入了监控，保证整条链路数据质量。监控定时检查计算数据上报的成功率、缓存率、丢失率，数据加工清洗后的留存率、落仓率等，一旦数据浮动超过设定的阈值，会自动发告警邮件给奇点研发人员。有了数据监控，能及时发现、高效处理数据量问题，降低数据损失，节省人力，极大提升了数据质量。

3.3 实时数据一站式看板

过去作者团队只关注埋点范围的研发业务，平台升级后，用户录入埋点信息后可通过看板即时查看 PV、UV、点击率等指标实时数据。对于用户来说，省去了从各种库表取数分析的步骤；对于埋点治理来说，不但降本增效，推动用户规范录入页面信息，而且指标计算结果比各个业务方自己分析更加准确。

四、奇点埋点对比行业创新功能

4.1 埋点可视化展示

查看某个页面的埋点信息，通常采用分页列表的方式，详细数据要跳转到看板浏览。这种方式虽然罗列出了页面所有埋点，但是每个埋点的录入人不同，埋点多了之后具体每个埋点表示什么含义其他人并不清楚。

为此作者团队研发了埋点可视化工具，完美解决了上述问题。只要输入页面 URL，选择合适的设备大小，页面哪些元素有埋点就呈现出来。每个坑位的埋点 ID，点击曝光的数据只要点击一下浮框即可见。埋点可视化工具还支持查看实时上报的日志和汇总的实时数据。

埋点可视化展示通过数据采集脚本 - 奇点 JS SDK 自动加载可视化插件实现，使用 postMessage 和 addEventListener('message')，实现埋点可视化工具和所查看页面的数据双向发送与接收，从而实时展示埋点数据和埋点日志。为减少加载 SDK 的页面开销，作者团队做了优化处理，只有在可视化工具中打开页面才会加载该插件。

4.2 H5 与原生 App 全链路数据打通

类似京东金融这样使用 Native 和 WEB 技术开发的混合应用，之前 H5 页面和原生页面的数据，使用了不同的 SDK 采集，用户在两端页面间跳转，数据是断裂的，只能分开统计，不能从整体上统计分析用户行为。采用归因统计的方法能关联部分两端的数据，但会导致数据统计不准确，不但增加数据分析人力、物力成本，不可靠的数据还会使运营无法精准投放广告，从而影响最终收益；

如今奇点团队实现了 H5 页面和原生页面数据打通，包括以下打通点：

访次打通: 访次是指用户在当前设备中累计访问次数，在京东金融 App 中，用户每次重新打开或者切后台超过 2 分钟后，访问的次数就会加 1。可以根据访次来统计用户活跃度。

访序打通: 访序是指用户在当前访次内，页面的访问顺序，H5 和原生页面打通后，页面的访序是连续的，可以更精准的查看用户访问页面路径。

来源埋点: 来源埋点是指上一个页面用户点击点最后一个埋点 ID。根据来源埋点，可以精准定位上一个页面触发点。数据打通后，可以确定当前页面的热点来源。

首访埋点: 首访埋点是指用户打开 App 时首次点击的坑位埋点，根据首访埋点可以定位到进入某一 H5 或原生页面起始点。

上一个页面 URL 或原生页面 CTP: 为了精准分析用户行为轨迹，奇点会采集上一个页面 URL 或原生页面 CTP，数据打通后，会形成闭环，即使是后退操作也会记录后退的前一个页面，从而可以更好的进行路径分析、页面可达分析、用户丢失率分析。

其他采集字段打通: 为了统一口径，统一指标，打通的字段还包含以下字段：设备 ID、手机品牌、手机型号、App 名称、App 版本。

两端打通前：

两端打通后：

数据打通的收益是巨大的，下面是一个实际使用案例 - 小金库页面流量来源归因分析：

4.3 页面 ID 自动匹配上报

过去统计 PV 时，根据访问页面的 URL 作为唯一标识，这个 URL 需要在奇点管理平台录入后方可进行计算。然而这种方式存在很大的缺陷。当遇到以下场景，根据哪个 URL 来计算，边界并不清晰。

• URL 中带参数，例如/path1/path2?param=value。不同参数可能代表同一个页面，也可能是不同的页面；
• 动态路由，例如/path1/path2/:path3/，某个 path 是动态的，如果这个 path 是数字 ID，是无法在奇点管理平台全部录入的；
• Hash 路由，例如/path1/path2/#/route1 / route2。如今前端单页面盛行，不同业务方做出的网站大相径庭，hash 值不同，有的希望统计成一个页面，也有想统计成不同的页面；
• 以上场景混合的情况。

针对此问题，作者团队提出了使用 pageId 代替 URL 的方案。即业务方在奇点管理平台录入时指定 URL 的哪部分是动态的还是固定的，并生成唯一页面的 ID。在访问页面时，当前页面的链接与录入的动态规则做计算，找到最匹配的 pageId 后上报数据，最终使用 pageId 做数据统计，极大的提高了指标计算正确率。

为保证此方案的稳健性，作者团队也做了很多细节把控。比如为防止拉取 CDN pageId JSON 文件失败，增加了重试机制，在未获取到文件时先将上报数据缓存在本地。比如没有匹配成功的 URL 另做打标处理。还有监控站点更新页面，同步生成最新的配置关系等等。

五、未来规划

在埋点数据治理方向，奇点团队联合数据团队通过一系列方案实现自动化治理埋点数据。例如对不规范数据打标，使数据不进入数据分析模型层；各端统一使用页面唯一 ID 的上报方式；不规范录入信息的页面自动认领到页面站点下；向未录入页面的用户定向推送邮件等方式持续提升数据质量。

在平台能力建设方向，首先从精细化运营角度还要持续建设可视化埋点及与页面活动搭建平台打通提供组件化埋点能力，提升埋点开发效率。其次从埋点生命周期管理角度，奇点平台提供的埋点设计管理、代码扫描、埋点验证、埋点指标看板一系列工具要更好流程化整合，提升产、运、研等各方的协同效率。最后从智能化建设角度，对于流量数据看板增加智能分析、智能预测能力，提升数据应用效率。通过埋点数据作为基石，赋能业务场景，更好地服务支撑公司整体的数智化经营能力建设。

作者：京东科技 奇点研发组 转载请注明来源