一、引言
随着大数据技术的不断发展，从IT时代到DT时代，再到AI时代，埋点技术也在不断升级和改进。从Hadoop技术体系到如今的AI技术体系，埋点的应用场景和价值不断扩大和提升。在AI时代，埋点的重要性更加突显，因为AI技术的发展离不开大量的数据支持，而埋点正是收集和存储数据的关键。埋点的价值在于能够收集数据、存储数据和分析数据，为数据分析和决策提供有力支持。
在技术升级的同时，埋点的应用也越来越广泛。从营销分析、产品优化、运营管理到用户画像等多个领域，埋点都有着重要的应用。而在这些应用中，埋点的作用也逐渐从简单的数据收集转变为更加智能化和个性化的服务。通过埋点收集的数据，企业可以更好地了解用户需求、行为和偏好，进而提供更加优质的产品和服务。
总之，埋点是大数据时代不可或缺的核心数据来源，其价值和作用在不断扩大和提升。在未来的数据时代，埋点将继续扮演着重要的角色，为数据分析和决策提供有力支持。
二、埋点工具概览
在埋点研发过程中，埋点工具起到了非常重要的作用。一些常见的埋点工具包括SDK和web请求抓包等辅助工具，可以帮助业务进行埋点以及验证，有利的工具可以提高埋点的效率，并确保埋点数据的准确性和有效性。
埋点工具集主要包括埋点需求管理工具、埋点验证工具、埋点数据采集工具和埋点数据查询四部分。
- 埋点需求管理工具是一个重要的工具，它可以帮助数据产品人员更好地管理埋点需求，对埋点数据进行分析和浏览，为后续埋点工作提供支持。
- 埋点验证工具则是对埋点数据质量进行验证的工具，主要包括数据抓包和验证，确保全链路数据埋点的数据质量。
- 埋点数据采集工具主要负责将埋点数据进行采集，确保线上数据的正常有效采集。
- 埋点数据查询则是将采集到的数据进行查询和分析，帮助企业更好地了解用户行为和需求，为业务决策提供数据支持。
三、埋点需求管理
知乎埋点需求管理平台的演进，以简化埋点设计流程为主线，同时也注重降低设计成本，提高效率和易用性，使其能更好地满足软件开发人员和项目管理人员的需求，增强其生产力。
从1.0版本升级到2.0版本，知乎埋点需求管理平台主要改进在两方面。一方面，降本增效成为该平台升级的核心思路。这不仅能帮助开发人员和项目管理人员专注于软件开发和项目管理本身，减少因繁琐的埋点设计流程占用时间和精力的困扰，同时，增效功能可以更快地完成埋点设计，提高团队整体工作效率。另一方面，简化整个埋点设计流程也是该平台升级的重要改进之一。1.0版本中，埋点设计流程较为复杂，需要进行多个步骤的配置，给用户带来了较高的操作难度和学习成本。2.0版本中，知乎埋点需求管理平台将多个步骤整合成一个流程，大大简化了用户的操作流程，提升了使用体验。
为了更快捷、高效地完成需求复制，并对不同场景下的埋点差异进行比较，我们提出了一项智能化的功能。该功能可以根据需求，快速生成埋点代码，并通过流程化的方式，将各个流程中涉及到的埋点需求、内容及时传递给相关负责人，以确保整个流程的清晰明了。
四、埋点验证
经过前期埋点需求设计与开发的紧密合作，现已顺利完成该项目的关键节点——埋点验证功能的设计与开发。相较于之前单点抓包自行验证的方式，此次的升级采用了平台化的验证方案，这一改进显著提升了测试效率，为数据质量的保障奠定了坚实的基础。
作为知乎埋点功能的1.0版本，本次升级至2.0版本，主要体现在单点抓包自行验证的方式已经成为过去式，取而代之的是平台化的验证方案。这一变革不仅为埋点功能的应用提供了更高效的验证方式，同时也提升了整个埋点验证过程的质量，为后续埋点功能的运用奠定了良好的基础。
数据验证功能1.0升级到2.0版本主要有以下几点的改善:
- 技术上从单点架构升级到云原生高可用的保障方案,引入消息队列中间件，支持无状态多节点部署，避免单点故障，保障业务系统的高可用。
- 埋点测试可以快速绑定埋点需求，进行埋点测试，并生成相关测试报告。
五、埋点数据采集
1.0版本的采集服务系统整个流程为，由客户端上报后，埋点数据会先经过服务本地缓冲队列，再进行线程转发给消息队列Kafka。1.0版本经历了5年的时间，采用python代码开发，代码臃肿，数据处理机制延迟较高，随着时间的推移后续迭代变更风险呈指数级增长，1.0版本的缺点由于本身的架构限制而日益凸显。
2.0版本采用平台级别的数据采集方案，仍然以消息中间件作为与数仓沟通的桥梁，但臃肿的数据处理机制全部重构，内部数据兜底策略使用多路消息中间件作为backup，可让数据输出直面消息MQ提示整体的处理能力，整个数据链路计算耗时缩短为之前的1/15（延时基本保证在30ms以内）。除此之外为了保证迭代的安全性，根据不同的埋点数据处理流程提供单独的处理器实例，可实现快速的横向扩展，这样引入新的数据处理机制时可减少变更风险。
六、埋点数据查询
埋点数据查询工具，主要面向人群为运营、分析师、产品角色的同学，供其进行数据查询分析使用。整体架构是建立在数据服务上的，以Web-API的方式查询数据服务，数据查询功能和底层数据模型和存储进行架构分离，使用上通过配置可以快速生成API，使得效率大幅提升。
为了提升业务的高频访问速度和用户体验，我们针对不同的需求定制了精简化的维度设置，例如在product、国家、地区等方面，我们选用了具有强大处理能力的Doris底层架构，以便更加高效地处理海量数据。另外，为了满足埋点数据产品平台的高性能查询需求，我们选择了基于Hive的Presto引擎作为底层数据查询引擎，能够轻松支持大规模的数据离线以及实时查询任务，提供更快捷、精准的查询结果。
七、埋点服务
埋点数据查询基于基础数据服务，其主要包括三点核心设计：数据集成、逻辑模型以及云原生。
数据服务主要解决如下问题：
- 数据集成，降低异构数据接入成本；针对不同的数据结构和使用特点，会通过数据产出任务导入不同的中间存储，对外无感知。
- 通过逻辑模型解决接口和物理模型无法复用的问题；可有效避免烟囱式的开发模式；逻辑模型是虚拟的能够解决掉面对同一物理模型而需要关注不同的列的需求，避免数据重复加工，而且其本身并不产生落盘数据，而是在查询时动态获取数据，这样也使数据通过api对外共享成为了可能。
- 全链路关系的打通；有了数据服务后，对外界暴露的数据就可以通过api来实现了，应用发布api以后，我们可以通过物理模型本身的数据血缘所对应的逻辑模型中去打标签，标签是根据上层的数据应用涉及的具体页面接入是生成的，这样就可以和原本物理模型的数据血缘可以组成全链路的数据血缘关系；当上层数据应用接入或者下线时，我们就可以条件或者清除掉对应的标记；这样不但能解决掉数据加工任务异常时无法根据应用的重要性排列恢复优先级的问题，而且还能解决掉数据下线时不知道哪些业务引用了的难题。
- 防止基础表字段变更对上层应用造成影响；底层物理模型变更其实是比较频繁的事情；因为汇总层的模型也一直在随着业务需求去做完善和优化，所以基础的字段增删以及修改会经常发生，如果没有数据服务通过接口的方式提供查询，就会出现字段变更之后需要强推业务修改代码重新上线，这是非常不合理的，数据服务逻辑模型可以避免掉这个问题，可以通过物理字段和逻辑字段的映射关系达到对用户访问透明的效果，这样就消除了数据访问字段强依赖的问题。
八、提问环节
Q1: 埋点需求流程中参数设计及上线由哪个角色负责比较合理？
A1: 知乎埋点流程是由整体的数据产品把控的，业务产品进行需求规划和建立，数据产品根据业务需求进行埋点设计，后续埋点开发、验证到上线验收也是由数据产品进行整体闭环掌握。
Q2: 用户端的行为session，客户端上报还是服务端上报比较合理？
A2: 在用户体验和数据分析方面，用户Session的设计和实现是至关重要的。通过对Session的不同类型进行深入了解，可以更好地把握用户在不同页面和应用场景下的行为特征。同时，SDK方案的优化也可以帮助提高代码质量，更好地保障行为质量。这些都需要通过精细的端上控制来实现。在具体实现方面，端上对Session的管理是非常关键的。在不同的场景下，用户的行为会呈现出不同的特点，例如在网页中，用户的行为通常是点击、滑动、搜索等操作；而在移动应用中，用户的行为可能会涉及到应用的启动、加载、操作等多个环节。因此，我们需要通过深入分析用户的行为特征，从而对不同类型的Session进行细致的划分和设计。另外，SDK方案的优化也是提高行为质量的关键之一。SDK方案可以通过优化代码逻辑、提高性能、降低延迟等方式，来帮助我们更好地捕捉用户行为数据。在这个过程中，我们需要对用户行为进行分析和预测，以便更好地优化SDK方案，从而提高用户的满意度和体验。总之，对于用户Session的设计和实现，我们需要充分了解不同场景下用户的行为特征，通过精细的端上控制和优化SDK方案，来保障用户行为的质量和数据的准确性。这需要我们不断探索和创新，以更好地满足用户的需求和期望。
Q3: 什么样的埋点体系才是很好的埋点体系？
A3: 根据公司业务业务需求特性落地，核心包括(1)流程规范性保障，从埋点需求到埋点设计、再到埋点开发和测试和验收整个流程上保障一致性。(2)全链路数据质量保障，通过埋点工具保障埋点设计和埋点生产数据保障一致。
Q4: 业务产品版本，埋点版本和前端功能版本之间的关系是怎么样的？
A4: 针对埋点版本是有对应的落库记录，可以通过不同版本的差异，快速寻找对应的埋点差异。
Q5: 埋点成本如何优化 ？
A5: 埋点版本生命周期管理,针对不同版本，无效埋点进行下线，降低数据产出级别成本;数仓表生命周期管理:按照数仓分层，不同分层对数据使用的周期，进行数据生命周期管理。
