货拉拉用户埋点体系建设实践

导读埋点数据作为货拉拉公司的核心数据资产，应用涉及用户增长、产品优化、智能运营及科学决策，是各业务侧提出优化解决方案的重要基础数据。各大互联网公司都十分重视埋点数据的收集、治理和数据洞察应用。本次分享介绍了货拉拉用户埋点体系建设的相关经验和实践，包括用户埋点体系建设的背景和挑战。其中涉及到三方面的痛点，分别是业务侧需求管控缺失、技术侧埋点上报缺失以及 QA 侧回归成本高。通过引入后端埋点的 SDK，建立与埋点管理平台的打通，可以实现对埋点数据的校验、标记、分发。通过增量埋点和存量埋点的监控能力，可以了解埋点的情况和趋势，以及 PV/UV 等指标。未来将会从服务融合、血缘建设和治理优化三个方面继续开展工作。

本次介绍会围绕下面的内容展开：

1. 背景与挑战

2. 体系能力建设

3. 埋点监控与保障

分享嘉宾｜于敬晖 货拉拉 资深大数据工程师

编辑整理｜天天

内容校对｜李瑶

出品社区｜DataFun

01背景与挑战

首先介绍埋点体系建设的整体背景与挑战。2021 年货拉拉业务方对于埋点需求相对简单，货拉拉外购神策埋点服务可以支撑当时的埋点需求，但随着业务的快速扩张，对于埋点元事件管理的要求也随之提升。主要面临以下两个个问题：

1. 能力缺失

在神策体系中，有以下三个方面无法满足业务方的需求：

首先是元信息追溯能力，即业务方无法回溯埋点元数据的变更，只能查询当前最新的埋点元数据信息。其次是需求管控的能力，即当业务部门进行版本迭代时，可以设计和管控当前版本需要的埋点元信息，由此可以了解到不同版本下新增、修改、删除了哪些埋点。这样对于增量埋点，就可以做元数据层面的管控。最后是埋点的验收与保障，由于初期以功能开发为主，埋点比较混乱，很多情况都是端上开发自行埋点，并且由于历史原因埋点已没有归属，存在僵尸埋点，而增量埋点质量也没有良好的测试。

2. 模块单一

外购的神策服务支撑了用户埋点，货拉拉很多后端服务需要有 SDK 支撑埋点上报，因此我们单独开发了后端埋点采集服务及其 SDK。神策服务并没有和埋点测试平台打通，因为之前也没有埋点测试平台，导致现在的埋点数量很多并且字段定义不清，存在各种冗余和无效埋点。针对上述问题，归纳出三方面的问题，如下图所示：

• 业务侧痛点

首先需求没有管控，其次录入的埋点事件很难追溯，无法得知其历史记录的具体情况。

• 技术侧痛点

从技术侧来看，有服务端上报的需求，但是目前服务端上报是缺失的。在做埋点时，由于没有整体管控流程，导致埋点没有清晰的定义，只能在业务产品的 PRD 上做一些类似的需求。

• QA 侧痛点

QA 侧又会认为整体需求管控缺失，导致埋点元信息散乱，QA 的回归成本高。

针对这些痛点，开始着手解决体系不完善的问题。

02体系能力建设

为了解决业务侧的两个痛点，我们建设了自己的埋点管理平台，平台设计了四个模块：需求管理，版本管理，事件管理和属性管理。需求管理规范了整个埋点准入的流程，即从开始提需求、埋点设计到埋点上线等一系列操作。版本管理回溯埋点事件所有的变更，提供追溯事件变化过程的能力。事件管理和属性管理，可以展示出埋点事件详情及其属性和属性版本信息。

接下来详细介绍需求管理方面的建设。

当端上业务方开始一个新版本的迭代，就会新建一个埋点需求单，在需求单中会添加本次迭代相关埋点事件，并进行埋点事件的设计，包括埋点名称、属性值类型以及属性校验规则。例如订单相关埋点有价格属性，该属性会有一个取值范围，如果超出了价格区间，上报埋点就会判定为错误埋点。埋点设计完毕后交由数据部门审核。

早期没有这样的管控，业务方会输入各种各样的属性值、属性类型、属性名，而这些属性可能都是代表同一含义。审核使得增量的埋点事件逐渐规范化。审核通过后，就可以转交开发和测试进行埋点开发和埋点测试，开发和测试确认无误后，再交由业务需求来做埋点验收，并且上线后会把整个事件的元信息推送到缓存中。同时在有埋点上报时，也会做相关校验。埋点上线后，埋点管理平台还会把历史版本所有的属性取并集作为最新的埋点元信息，可以作为未来对该埋点元信息修改的参考。

每一次发版，都会有相应的版本元信息存储在埋点管理平台，通过回溯版本元信息，我们可以把历史埋点的历史变更全部展示出来。

同一个事件会有不同版本，不同版本下，属性不完全相同。在我们当前的平台上，用户可以从任意版本的属性出发，定位到相关的需求单、需求单所在的版本和在该版本下所属的事件。当这些版本、事件、属性、需求等所有信息打通后，对于用户来说就会非常便捷检索到事件、属性、版本。对于同一事件，其他用户对该埋点做了变更后，那么该事件的关注人也会收到相应的通知，大家能够感知到该事件的变化，对事件的认识会更加统一，在很大程度上杜绝了属性值定义不规范的问题。

通过以上元信息管理方案可以解决需求业务侧的问题，而技术侧痛点通过后端埋点的架构设计来缓解。通过引入后端埋点 SDK，并打通埋点管理平台，可以实现对后端埋点数据的校验、标记、分发。为了解决数据一致性问题，引入了 ack 和重试机制。

后端埋点上报链路实现了校验、标记、分发等功能逻辑，接下来介绍整体的设计思路。

后端埋点 SDK，通过内网 HTTP 的方式上报到后端埋点采集服务，前文提到的管理平台会把埋点的元信息写到 Redis，后端采集服务就会从 Redis 里获取这些埋点的元事件，以此校验、标记并分发埋点，分发到下游再由 Flink 任务去根据这些埋点的标记，分发到不同的业务线下。这些业务线的埋点数据可以提供给业务、后端或者数仓去做一些消费。同时，也会写到 Doris 和 Hive 中。事件分析平台基于 Doris/Hive 提供分析能力。以上就是整体的架构设计。

接下来详细介绍相关的模块设计。

在介绍模块前，首先介绍数据上报流程，当一个 HTTP 请求落到后端埋点时，这个 HTTP 请求会先落到日志里，我们的服务会通过解析该日志拿到这些埋点信息。我们还设计了埋点的 ACK 机制保障埋点一致性。ACK 具体实现如下：当读到一个埋点后，会在 Transaction Log 中记录一条数据，发送 Kafka 成功以后，Transaction Log 在数据打上标记，此时就认为这一条埋点是发送成功的。如果这个服务遇到一些问题或者重启，就可以直接读取 Transaction Log 去发送那些没有被打标记的埋点，这样就可以保证数据不会丢失。另外 SDK 层面也会有重试机制，当采集服务端遇到 500 的 HTTP Code 或者其他异常，SDK 都会重试。其次，元事件验证模块，与前文提到的埋点管理平台打通，可以通过埋点管理平台上的元事件进行后端埋点校验。以上是为了解决技术侧方面的问题所做的体系建设。

接下来介绍埋点测试平台，测试平台也与埋点管理平台进行了打通。当用户在管理平台上录入埋点事件后，这些事件信息就可以推送到埋点测试平台，测试同学可以对这些埋点去做验证。同时也会有版本管理和上报记录的功能，使测试过程中有记录可以追溯。

• 本文地址：货拉拉用户埋点体系建设实践
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

大致的产品形态如下图所示，会记录测试的目标事件，属性校验的属性名、类型以及是否校验成功。

通过上述三方面建设，从需求端到技术侧再到 QA 侧，解决了一个最重要的问题即增量问题。当埋点增量控制好之后，就可以做更多的事情，规范了增量的埋点以及埋点准入规则后，之前那些无序的埋点录入，就被统一管理起来了。

接下来介绍对埋点的监控和保障。

03埋点监控与保障

通过增量埋点和存量埋点的监控能力，可以了解埋点的情况和趋势，以及 PV/UV 等指标。通过质量监控系统和实时监控，可以对埋点的数据质量进行可视化呈现。同时，对埋点进行分级治理，梳理出治理措施和层面。根据埋点类型进行过滤和抽样，缓解资源问题。这些措施和实践在过去两年里得到了应用，取得了一定的缓解效果。

由于存量埋点仍然存在很大问题，所以需要对埋点做可视化管理，需要了解存量埋点和增量埋点的具体情况。首先是埋点的监控能力，会有相关卡片即每天会监控一些核心埋点事件，这些核心埋点事件的趋势以及 PV/UV 指标会被展现出来，具体如下图所示：

接下来会对所有核心埋点做质量保证。我们的质量监控系统叫做大禹系统，这个系统会扫一些关键的核心埋点，将其数据质量以可视化的形式呈现出来。

通过这两种方式就可以知道埋点的大致情况，此外还有一些实时的埋点质量监控，对于某条业务线的所有埋点做一个简单汇总，例如有哪些事件版本，以及相关的校验数量和错误数量。当这些监控完善之后，就会对之前处于混沌状态的埋点，有更加清晰的认识。

当增量埋点的规范化可控并且对整体埋点有了大概的了解之后，就可以开始着手做一些埋点的治理工作。治理工作冗长并且繁琐，由于一些历史原因，之前疏于管控，种种问题导致无效埋点非常多。因此首先对埋点进行分级，具体分了 A-无效、B-一般、C-重要、D-核心四个等级，列出每个等级的治理措施。

接下来介绍在整条链路上如何去处理这四个等级的埋点。

由于现在的用户埋点还是依赖于神策服务，因此神策服务会体现在上图中。对于梳理出来的一些无效埋点，可以直接在最前端拒绝掉，或是反馈给业务，让业务做处理。而对于 B 类事件，例如只有一些业务产品感到有用，而数仓或者后端下游则认为并不重要。当梳理好这些事件以后，就可以在神策上面去做查看和分析，不需要沉淀到数仓，或者做一些抽样沉淀至数仓。因此对于 B 类事件可以直接从 Flink 任务上去做过滤，把这些任务直接过滤掉，不需要再接收 A 类和 B 类事件了。C 类和 D 类事件被认为是非常重要的事件，会直接写到数仓 ODS 中。

由于无效埋点数量众多，所以在整个链路中开始拒绝一些埋点或是反馈给业务方下线埋点后，就会节省出一些资源。在过去一年里，货拉拉从去年 6 月到今年 6 月，埋点的量级翻了三倍，所以对于资源的利用是非常紧张的。在埋点分级后，得到了一定的缓解。但根本解决埋点质量问题，还需要一个持续且长期的过程。

以上从分析当前体系的缺失，到开始总结需求侧、业务侧、技术侧、QA 侧的痛点，再到开始治理存量埋点，同时整个埋点的概览也被描述清楚，这就是过去两年货拉拉在做的一些事情。

最后分享一些对未来的展望。

04展望

未来我们将着力于服务融合、血缘建设和治理优化三方面的工作。在服务融合方面，逐渐将自研系统与外购神策系统融合。在血缘建设方面，将通过分析埋点事件的下游链路，实现埋点的可追溯性。在治理优化方面，将通过数据部门的被动治理和主动治理，推动业务部门的标准化和规范化。

1. 服务融合

目前自研的系统越来越多，而之前外购的神策系统跟自研系统的融合存在一些困难。因此希望能够将后端的采集、管理平台、测试平台、质量校验平台，以及画像等服务融为一体，逐渐融入到货拉拉的技术栈中。

2. 血缘建设

数仓这边存在一大痛点是有时根本不知道埋点在哪些表中，是如何抽取出来的。因此会加强血缘方面的能力建设，通过埋入新的埋点事件后，分析出这些埋点的下游链路，使得埋点在整个数据链路上有可追溯的能力。

3. 治理优化

前文中提到，对于存量埋点的治理已经开始，但是这是一个长期的过程。由于埋点数量涨幅太快，所以不得不开始做治理。后续希望能够将数据部门的被动治理，转变为主动治理，通过从数据部门做治理，反向推动业务部门进行更加标准化、规范化的埋点录入和测试。

后续还会继续埋点的整体梳理，对于整个链路有更加清晰和准确的认识。

05

问答环节

Q1：如何评估埋点准确性目标的合理性，例如新增埋点的准确率大于百分之多少？执行层面是否有合理的统计办法，上线前完全识别出埋点的时机和参数上报的异常？

A1：目前我们有一个埋点测试平台，有测试环境以及上线前的 PRE 环境。我们在 PRE 环境会做一轮埋点的回归，测试同时会在 PRE 环境做埋点的一些参数的校验。在测试平台上会对参数进行校验，如果有问题会反馈到开发这边重新修改，直到测试通过以后，才允许上线。此外后端还有一个质量检测功能，因此对于整个质量是有保障的。如果在 PRE 环境通过校验，准确率是非常高的。只有一些存量埋点目前无法控制。

Q2：事件 Schema 校验不通过数据，数据是不是要另外保存？

A2：是的，我们会有一个叫做 Invalid 的数据流。我们会定义出很多种不同的异常，比如 Schema 不存在、参数不通过、参数缺失、类型不对、属性值不对等等，一些分层次的异常。当校验出这些异常时，我们会对这个埋点打个点，告诉他这个埋点是错误的。然后会由此路由到另外一个 Kafka 的 topic 里，同时我们还有一个查询这些异常队列的功能，就会把刚才定义的那些异常完整地展示给用户，让用户可以看到这些异常是怎么回事。

Q3：当用户没有登录的时候，产生的行为上报怎么和用户登录后的行为上报数据关联起来，如何做到归一？

A3：用户埋点目前我们还是在用神策的一个服务，因此登录的这一套流程其实都是由神策来处理的。用户登录前会生成一个 Anonymous ID，即匿名 ID。登录时调用登录方法，会生成一个真正的用户唯一 ID，替换掉之前的 Anonymous ID，通过这个唯一 ID 来做到归一。

Q4：贵司的埋点管理的粒度是怎样定制的，主要考量的是什么？

A4：目前我们的埋点粒度是事件层级、属性层级或是属性更下一级的层级，刚才前文提到一个版本的概念。我们的版本定义到了属性的粒度，即同一个事件下会有不同版本的属性。比如同一个事件叫做 app_click，在 1.0.0 版本有三个属性，在 1.2.0 可能还有一个 platform，但是这个 platform 属性完全改变了。我们最后的一个版本的粒度其实就是定在属性上，1.0.0 的 platform 属性和 1.2.0 的 platform 属性可能是完全不同的。为什么要定义在 platform 这个层面呢？这也是根据我们的需求来确定的，我们这边的埋点偏好是定义一个事件，这个事件可能在不同的页面都会有上报，然后会根据类型来区分这个事件是什么样的。比如同样叫作app_click 的事件，放到司机上可能就是接单事件，放到用户上可能又是下单事件。由于这种埋点设计偏好我们就只能把粒度放到属性上面，通过属性来区别这个埋点的作用。

Q5：如何辅助业务分析人员快速将埋点与各版本产品的位置对应上？

A5：目前我们的事件管理和属性管理是比较初级的方案，即提供了一个截图的功能，不同版本的属性下可以有截图，比如我们在 APP 上埋在了哪里，可以通过截图来上传。通过我们前文提到的系统可以快速定位到具体的属性，这个属性就会有相关的备注和截图，来辅助业务人员看到这个事件是如何埋的，埋在哪里。

以上就是本次分享的内容，谢谢大家。