埋点规范和质量管理

在数据埋点设计专题的前两篇文章中，我们讨论了如何去思考、分析数据埋点，以及如何写出一篇合格的数据埋点文档。接下来，我们将探讨数据埋点的规范和管理等问题。

之所以会写这篇文章，因为当我们接手公司的数据埋点工作时，大概率并非从零开始进行设计数据埋点，更常见的情况是公司已经有了一套能够运转的数据体系，或多或少能够指导实践，但你感觉它好像还没有发挥出应有的能力。即便是大厂，也不能确保对于数据有充分的使用效率。

So，让我们开始吧，数据埋点设计专题的最后一篇，开始啦~

埋点业务流程

流程角色

在一个完整的埋点业务流程中，涉及到三个主要团队：业务团队、埋点研发团队和数据团队。他们各自具有不同的职责：

• 业务营运团队：要由运营人员、产品经理和数据分析师组成，他们负责提出埋点需求。这些需求基于具体的业务场景，旨在通过数据分析来优化业务流程。他们的主要任务是提出初始需求，并在埋点实施后分析所收集的数据。

• 埋点研发团队：每个团队专注于埋点的开发、测试和部署。他们确保埋点的正确实施，以便准确收集所需数据。

• 数据团队：责定义埋点模型，处理从埋点收集到的数据。他们的工作包括接收数据、存储、处理和最终展示数据，以便业务团队进行分析和决策。

不难看出，我们在开展埋点业务时会涉及到大量的协同配合。为此企业需要一个与埋点业务相对应的组织架构来确保埋点采集的质量和效率。一般来说有三个关键的角色，他们在埋点工作中发挥着至关重要的作用：

1. 项目经理：于项目经理来说，它负责整体埋点工作的统一规划与组织协同。主要职责包括制定埋点流程、规范，并推广规范的实施与执行。这个角色需要确保各业务线数据接入的规范性和数据质量。一般会由数据产品经理担任。

2. 业务负责人：对公司特定业务线的埋点需求，需要有一个熟悉业务的人来负责。业务负责人的主要职责包括业务线的埋点需求梳理、设计、数据上线应用推广、日常使用支持以及培训。通常由数据分析师、有数据敏感度的产品经理或具备业务洞察力的研发人员担任。

3. 技术负责人：常每个业务线都涉及多种客户端产品，埋点开发可能包括 Android、iOS、微信小程序和服务端等多个平台。因此，需要一个技术接口人来统筹和协调埋点的开发工作，这个角色一般由前端开发负责人担任。

业务流程

埋点流程长什么样？

上面这张流程图完整地展示了埋点的整个过程。对于埋点业务来说，这个流程是非常严谨的。它涉及了多个角色和步骤，确保了高质量和高效率的数据采集。不过，很少有组织会采用完整的埋点业务流程进行实践，每个企业的情况不同，适用的业务流程也不同。

那有没有一些流程在大体上是通用的呢？是有的。埋点的核心流程主要涵盖了五个环节，分别为：

1、埋点需求提交：业务线的需求方发起，通常包括营运、产品、推广或数分部门。他们根据业务需要提出埋点需求，通过正式的需求邮件通知埋点研发测试团队和数据团队。

2、需求评审：该环节由数据团队主导，埋点研发测试团队参与，业务方进行确认。数据团队基于业务需求设计埋点方案，输出文档（DRD），并组织需求评审会议。在评审会上，研发测试团队确认需求的可行性，业务方确认事件设计方案是否符合业务需求。如有必要，进行多次需求复审直至三方达成一致。

3、埋点开发：业务方在埋点开发前需在线注册埋点信息，内容需与评审通过的 DRD 保持一致。埋点研发团队依据线上注册的信息进行开发。

4、埋点测试、验收与部署上线：测试人员完成埋点数据的测试。测试完成后，数据团队和业务方进行验收。经验收合格后，由研发人员负责部署上线。

5、埋点应用（数据分析）：埋点上线后，业务方可利用数据提取、用户行为分析平台、用户画像标签系统等工具消费埋点数据，以进行进一步的数据分析。

当然，这是最为理想的情况，这五个步骤能够平衡好数据埋点的 KOI。但是！！事实是我们并不可能严格按照这套流程来执行，有可能因为各部门的工作排不开，导致无法进行多轮的埋点需求评审。或者在文档层面出现了难以发现的小错误，导致最后上线的数据与实际不符等等。

如何改进埋点流程？

那么，我们还能够怎么做，让整个埋点体系达到成本低、效率高、质量好的目的呢？我们主要从产品经理的核心能力和业务流程去进行改进。

1、沟通能力

关于沟通真的有太多想要讲的了，在当今的产品开发流程中，学会如何沟通要比产品和技术更加重要。沟通是个时间黑洞，产品经理每天不是在开会，就是在开会的路上顺便写需求。对于 PM 来说，明确对接对象、清楚描述好需求，能够一定程度上提高沟通效率。

2、抽象能力

抽象能力是产品思维的核心能力之一，具备抽象能力有助于减少重复设计的成本，提高产品复用性。关于抽象能力，可参见 什么是产品思维？我们要尽可能地设计一套灵活、全面且具有高度复用性的埋点模型。优秀的模型能广泛覆盖用户行为，提高对埋点进行增删改查的效率。从宏观（企业）的视角来看，埋点体系建设需要统一进行设计。

3、独立评审

关于需不需要将数据埋点当作一条独立的研发流程来对待，这需要取决于公司对于数据的重视程度。我认为，除非是涉及大版本更新或者架构调整，否则数据埋点业务大多会在产品评审或需求附件上体现，小版本或运营活动的数据埋点一般不会特别复杂。将数据埋点作为单独的研发流程，有助于提升研发各方的重视程度，实现高效协同。

4、埋点管理

和产品经理写埋点文档类似，对于研发来说，埋点开发同样是一项琐碎的工作。随着埋点越来越多，埋点管理的工作也会更加复杂，这是很多研发不愿意进行埋点的原因。考虑到埋点研发工作的繁琐性和代码管理难度，需要开发专用工具来提高开发和测试的效率。常规的解决方式是通过做一个埋点管理系统去解决这个问题。

如何设计出一个实用高效的埋点管理系统？

5、埋点应用

如何做好埋点和业务的关联应用？这个问题的答案就是我们前两篇文章中提到的对于埋点的思考和分析过程。想清楚数据最后怎么用，知道埋点和业务的关系，有助于 BI 团队根据业务需求生成相关指标，发挥数据看板的最大效用。

总结，建设一个还不错的企业级埋点体系，需要注意以下三个要点：

1. 设计灵活、全面、复用性高的埋点模型，以提升设计效率和降低应用及管理成本。
2. 制定清晰可执行的端到端埋点采集规范，明确每个环节的输入输出，保证各参与方的高质量产出。
3. 开发线上工具以支持埋点管理、研发、测试验收等工作，从而提高整体效率。

埋点需求提出

回到一开始我们提到的埋点业务流程，我们来过一遍一个完整的埋点业务流程。

提出之前

埋点需求通常是业务方的运营人员、产品经理或者数据分析师来提出的。除了数据分析师，可能运营和产品对于如何提埋点需求，甚至对数据埋点的定义并不熟悉。换句话来说，提埋点需求并非一件简单的事情，同样也需要学习。

在我之前的团队中，埋点需求的提交流程仅要求业务部门明确说明所需分析的指标及其应用维度。随后，数据团队会细化这些指标和维度，完成埋点设计。

这个流程对于提出需求的业务人员是很方便的，他们不需要解释选择这个指标的原因以及选择这个指标的价值。通常，业务方对整个业务路径并不完全了解，他们关注的是路径中的特定环节，比如要看某些运营位的转化数据、某个功能的使用情况等等。他们并不需要了解功能与功能之间的关联和作用。也因此，他们提出的需求往往是局部性的、临时的、一次性的。

虽然这种方法很便捷，但是问题同样也是存在的。因为提出的需求是局部性、临时性、一次性的，针对需求进行的埋点设计同样也具有这类特征。如果后续业务路径有任何微小调整，甚至是最细微的变化，都可能导致现有的埋点无法使用，需要重新设计。

示例：用户发帖

这个例子可能比较抽象，让我们来看一个具体的例子：用户在社区发帖。

假设在当前社区，用户可以通过两个入口进入帖子的编辑页面。如下图所示，分别有 A 入口和 B 入口。在帖子编辑完成后，点击发布按钮就可以发布帖子。

经典环节来了，此时业务方想要知道用户发帖子的漏斗数据，但并不知晓有 B 入口的存在。于是他们提出的数据指标漏斗就是：

• 点击入口 A 的用户数

  • 进入编辑帖子页面的用户数

    • 点击发布按钮并成功发布帖子的用户数

数分通常不会质疑业务方，可能数分知道存在多个页面入口，但如果业务方想要了解从 A 入口进入帖子编辑、发布的数据，那么不置可否，照做就行了。于是，基于业务方的要求，数分设计了两个事件，分别为进入编辑帖子页和发布帖子两个事件。由于入口默认为 A，所以不需要区分其他入口的点击数据。

事件	事件属性	事件属性说明
进入编辑帖子页	时间	记录进入编辑帖子页的时间
	用户ID	记录进入编辑帖子页的用户ID
发布帖子	时间	记录发布帖子的时间
	帖子ID	发布帖子的ID
	帖子标题	发布帖子的标题
	是否成功	标记帖子是否发布成功
	用户ID	记录发布帖子的用户ID

没过多久，业务方突然找上门来，来找数分核对数据，质问数据有问题（OS：这种情况真的太太太常见了！）：

业务小哥：我觉得数据有问题。

数据分析师：有啥问题（我看你才是最大的问题）？

业务小哥：入口 A 的浏览数据（PV）只有 1000 人，进入帖子编辑页的人数（UV）有 1000 人，闹鬼啦？

数据分析师：其实进入帖子编辑页还有其他的入口。

业务小哥：...你怎么不早说？！

数据分析师：你也没问呀，我以为你知道，只是为了统计单一入口。

（陷入沉默...）

业务方：Emm...那好吧，那现在能不能区分不同入口发布帖子的用户数呢？

数分：当前的埋点做不到，要等下个版本才能新增埋点，并且只有在新版本中才能区分。

业务方：好吧，也只能这样了（内心一千只神兽奔腾）。

数据分析师：好的，那我改下需求，待会发你看看，你核对一下。

事件	事件属性	事件属性说明
进入编辑帖子页	时间	记录进入编辑帖子页的时间
	用户ID	记录进入编辑帖子页的用户ID
	发布入口	记录进入编辑帖子页的入口
发布帖子	时间	记录发布帖子的时间
	帖子ID	发布帖子的ID
	帖子标题	发布帖子的标题
	是否成功	标记帖子是否发布成功
	用户ID	记录发布帖子的用户ID
	发布入口	记录进入发布帖子页的入口

这种情况是数据团队与业务团队之间常见的问题，堪称典中典。根本原因在于掌握丰富业务知识的业务部门未能向数据分析团队提供全面的信息。同时，数据分析团队也未进一步探询细节，而是直接根据业务部门的指示进行操作，这导致设计出的埋点无法覆盖完整流程，进而影响埋点的有效性。

为预防此类问题，建议在埋点需求提交阶段，要求业务部门对整个业务流程进行详细说明。这包括业务功能的目标、完成路径，以及用户体验流程等。这有助于业务部门在提需求前自行梳理业务路径，并提供尽可能多的业务背景信息。通过这种方式，可以确保数据团队获得足够的信息，以设计出更全面、有效的埋点。

总而言之，我们同时需要团队多方尽可能地掌握多的信息，消除潜在的信息差。

提交需求

业务部分确定埋点后，需要向团队发送正式的需求邮件以确认工作的正式开展。

格式		示例
邮件标题	[埋点接入]应用名称业务名称邮件日期	[埋点接入]主包APP_券商业务_20240101
邮件正文	按照表格提供以下信息： · 应用名称： · 端类型： · 业务名称： · 希望埋点上线日期：	· 应用名称:主包APP · 端类型:Andorid、iOS、H5、小程序 · 业务名称:券商业务 · 希望埋点上线日期:20240201 · 希望在用户行为分析平台看到数据日期:20240201
附件	附上以下两个附件： 1. 《埋点需求模板》 2. 《埋点业务路径描述》
邮件接收人	对接数据分析邮箱
邮件抄送人	数据团队、埋点研发测试团队、业务相关人员

另外，还需要附上埋点需求梳理模板和埋点业务路径描述说明。

模板中的信息要和业务方做的业务梳理高度相关，业务方需要方严格按照线下邮件流程提交详细信息，包括产品类型、所属业务、业务路径、统计指标、维度和期望上线日期等。数据团队应在两个工作日内回应，以便详细讨论需求。

埋点需求评审

需求评审是数据团队主导的关键环节，通常由负责特定业务线的数据分析师负责。该环节分为三步：埋点设计、组织埋点需求评审会议、埋点注册。

1、埋点设计

数据分析师在接收到埋点需求邮件后，需详细阅读并与业务方沟通细节，根据业务路径设计埋点以全面覆盖业务流程。埋点设计结果是输出一个埋点设计文档（DRD）。

2、埋点需求评审

数据分析师需组织埋点研发测试团队和业务方进行埋点需求评审。评审内容包括：

• 需求可行性：由埋点研发测试团队确认
• 埋点设计方案：由业务方确认

如果评审未达成一致意见，需要多次组织评审直至团队意见一致。评审完成后，埋点开发将严格按照文档进行。如需调整需求，必须经数据分析团队变更并通知相关方。这个过程就是比较常规的需求研发流程，没有特殊的地方。

3、注册埋点

埋点注册包括将埋点设计文档（DRD）中的信息录入线上系统。这样做的目的是方便埋点的整个生命周期管理，包括新增、回溯、迭代、下线等，确保埋点的有序管理，避免混乱。

Tips：关于埋点管理的文章，上面给到了一个链接，感兴趣的可以回去看一下哦~

埋点开发

完成埋点注册之后，研发小哥们就可以开始敲代码了。研发团队可以自研埋点 SDK，采用全埋点、代码埋点或者可视化埋点，或者采用开源的神策埋点 SDK，可以节省很大的工作量。相较于其他产品，开源的神策埋点几乎是唯一选择。

测试、验收、上线

埋点数据的测试是一个关键步骤，主要由测试人员负责，前向会有负责埋点需求的产品经理进行验收和轻量测试。这个过程需要确保埋点数据在实际操作中的准确性和有效性。测试通过后，研发团队会进行部署上线。上线后，业务方负责对埋点数据进行最终的验收。埋点验证过程包括以下任务：

1. 校验在触发时机下，前端或服务端的埋点数据是否正常上报。
2. 确认数据库是否成功接收到上报的埋点数据。
3. 对上报的事件和属性的完整性及数据类型进行校验。

为了确保广泛的兼容性和准确性，埋点的测试需要覆盖主流机型。测试完成后，测试人员需要编写并提交测试报告。根据这份报告，研发人员将进行最终的埋点部署上线。整体来看，就是采用研发流程去管理埋点业务，使得埋点业务流程更加规范、高效。

更多

至此，数据埋点专题五篇文章到这里就结束了。其实应该还有一篇是关于如何进行数据分析的内容，但是由于专题的限制，数分的部分将会在后续展开。