一、什么是埋点

先举一个实际的例子，比如用户在某一时刻点击了某个APP里面某个页面上的推荐按钮，这一信息将被记录下来，会以一条日志的方式去做上报，存储到服务器当中，这样的日志信息可以定义为一个埋点。

埋点的结构可以抽象为who(什么人)、when(什么时间)、where（在什么地方）、what（做了什么事）、how（上下文的环境是咋样的）这五个关键词，记录用户在APP、网页或小程序里面一系列的行为。实际上不管是用户在客户端的行为，还是在接口日志的变更记录，都是埋点的一种类型，这就是常见的客户端埋点以及服务端埋点

二、埋点数据的价值

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

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

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

三、业内常见的埋点方式

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

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

四、治理埋点的原因

用一句话描述，是因为当时公司内部缺少埋点全生命周期的管理流程，导致埋点新增、埋点变更、埋点使用（解析和计算）方面存在各种问题。

细节问题及举例如下。

1、业务侧

埋点溯源难：线下创建埋点，随着时间推移-人员变动-工作交接，难以溯源

埋点查询难：若想了解某个埋点的具体含义，需要逐级问好多人，都不一定能得到答案

埋点事件不可读：埋点事件上线后，由于缺少规范约束，不知道事件中关键词的具体含义

2、数据分析侧

沟通成本高：若需要通过埋点加工数据指标，由于数据结构和字段含义不可见，需要反复与业务侧多次沟通埋点数据结构

感知变更难：只能通过数据指标的大幅度变化感知埋点变更，滞后且不可靠

数据不可靠：埋点不经过测试就上线，上线后发现埋点漏埋、错埋、多埋、漏发、错发、多发，导致数据指标不可靠，更新又要等一个版本

3、平台侧

计算压力大：通过埋点算指标的场景，基本使用正则表达式，带了计算复杂度的提升

存储压力大：无下线机制，不用的埋点不下线，每天都消耗计算资源

流程未闭环：平台只支持埋点录入、事件分析，缺少校验、规范环节

五、埋点治理标准化实践总结

       带着上述问题，我们对业界的埋点方案进行了调研总结。主要分为两部分：埋点日志字段规范和埋点需求流程。

1、字段规范

       埋点字段规范应遵循以下几点：

1.    一致性：所有事件字段的命名要统一，便于后续分析和比较。使用相同的命名格式（如驼峰命名法、下划线命名法等）。

2.   详细性：字段设计要尽可能详细，确保能够捕捉到用户行为的所有关键细节。避免过于简单或模糊的字段，例如“操作”应该具体到“点击按钮”而不是“行为”。

3.  简洁性：保持字段名称简短且具有描述性，避免过长的命名。确保字段信息易于理解，不会让分析者感到困惑。

4.  灵活性：设计应能适应未来的业务变化，方便后期添加新字段。考虑到不同的业务场景，字段设计应具有扩展性。

5. 不重复：避免设计冗余字段，确保每个字段都有独特的目的，数据不会重复。

6.  完整性：确保每个关键的用户行为和系统事件都有对应的埋点。不遗漏任何重要的业务逻辑或用户交互。

7.  可追溯性：每个埋点应该能够追溯到特定的业务需求或用户需求，确保数据能够反映实际场景。

8.  用户隐私：遵循相关法律法规，避免收集敏感信息，做好用户隐私保护。

9.  性能考虑：注意埋点对系统性能的影响，合理设置埋点的触发频率，避免过度埋点带来的负担。

遵循这些原则可以帮助团队创建一个高效、可维护并且易于分析的埋点系统

这里附上作者团队在做【网舟埋点管理平台】时埋点字段规范

2、埋点需求流程规范

在埋点标准化设计中的三个重要部分：埋点命名规范、埋点属性管理和流程规范。

埋点命名规范

作者团队在标准化实践中引入了spmid（super-model）模型。在埋点的track_sign中包含业务的实际信息，将各业务含义抽象在埋点ID当中，然后将这个ID进行维表化的管理。整体分成五个部分，包括业务ID、页面ID、位置和埋点类型。通过规范的命名可以提升整个业务的可读性，在做埋点数据治理时，可以合理的定位问题，降低埋点的成本。相同的命名，不同的埋点类型可以做到复用。

上图中展示了一个实际的例子，在埋点的我的页，我的保单按钮应该如何命名？这个埋点可以命名为aminePage.b34.d35_49.click，这样一个命名中包含了很多业务使用的含义。拆解来看，这个埋点实际上包含四个业务粒度及埋点类型的元信息。业务的粒度从粗到细，覆盖了business_id、page_id、position_id。

对于使用者来说，拿到这个track_sign以后能快速地定位到这个埋点所处的页面模块、位置模块，以及在哪一个页面minePage，所属的业务线是哪一条，能够精确地定位它所处的业务线对应的信息。

这个业务埋点ID，对于做一个定位或者类型的划分，能够做到业务的可读性非常高，分摊业务埋点的成本，并且复用性非常高。点击的埋点命名为click，那同样一个模块，曝光的埋点，命名为show就可以了。

在做埋点的时候，上报的时候会划分为客户端SDK上报以及服务端上报。客户端通过埋点的类型划分，包括启动、浏览、曝光、点击、播放、系统以及其它事件。服务端包括这个API的请求记录，以及业务端业务表的日志变更信息。

上述就是作者团队关于埋点的命名的一些经验。

埋点属性管理

在埋点上报的时候，有一个很重要的部分是记录埋点的属性参数。埋点属性在业务含义当中是对用户有一些定制采集的信息。

会做三个层级的划分：首先是全局公共字段，包括埋点事件ID、APP信息、触发的时间戳、触发时间的网络、运营商、操作系统的版本等等。

第二个是针对不同的埋点类型，包括页面浏览PV、播放，或者业务特色的业务内容埋点，抽象出这个类型通用字段去做一个具体的预填充。

这两个部分都是预设在SDK当中，业务开发无需二次处理。

第三个部分就是业务定制化的私有参数，比如做海报轮播的时候，需要这个海报轮播的bannerID，或者这个海报对应跳转up主的mid等参数，就是业务它自定义去使用的参数信息。

在业内有另外两种主流的方案，一种是采集参数，平铺预留10-20个param的私有参数，另外一种就是只区分公共属性跟私有字段的属性。这两类方案的问题是扩展性会有一些欠缺，虽然在早期的时候可以快速地去辅助业务的数据采集，但是后期的治理成本比较高。经过长期的实践发现，采用公共字段+类型通用字段+私有字段这种方式，是一个比较通用，而且扩展性比较强的埋点属性规范方式，保证了灵活性和扩展性。

关于埋点属性规范，在数仓中，比如一张Hive表，会有表字段级别的数据标准。在埋点数据当中，把埋点抽象为业务表，埋点的属性实际上映射为表当中的字段，所以引申出来，它也有属性标准。

一个管理的规范会划分为三大类，一类是基础的描述信息，第二类是属性的质量，第三类辅助去做属性管理所使用的信息。

第一类基础属性，常见的有命名规范是否符合下划线连接、点号连接，中划线连接。数据的类型，到底是字符串还是数值，还是枚举类型。

第二个部分是它的数据质量，包括埋点是否为空值、枚举值，默认值应该填充为Null，还是一个中划线，这些是后面做埋点测试的时候使用，测试规则都是基于这部分埋点的属性标准。

第三类是元数据集管理，包括埋点的版本，属性的优先级、安全等级等等。

流程规范

       作者团队把整个埋点流程及规范，划分为了五个环节以及四个重要的参与方

四个重要的参与方分别如下，业务同学提出了需求以后，给到数据产品同学，数据产品把业务需求抽象为埋点需求文档，称为DRD，然后跟开发进行可行性方案的评审，根据优先级、成本去进行评估，最后落地为开发排期进行需求上线，需求开发完成通过测试，再给到数据同学进行分析。

六个环节除了包含上述四个参与方的环节，还包含数据采集和验证。开发根据这个需求文档进行埋点开发，对服务端或者客户端的行为去做接口日志的采集存储，最后交由数据产品或者测试同学进行埋点测试。测试会借助到埋点管理工具当中的一个测试模块。最后测试完成，进行上线使用。