如何推动埋点管理项目的落地

埋点数据作为三大数据来源之一，具有应用场景多、数据量级大等特点，上能影响数据分析、推荐、AB实验的准确性，下能影响数仓结构设计和维护成本，其重要性不言而喻。

一般公司在业务发展初期，业务线及参与协作的角色数量相对较少，通常采用在线文档的形式来管理埋点，但随着业务的快速发展，业务线的增加以及人员流动等因素，在线文档的的弊端也日益显现，急需一款一站式埋点管理工具，用来实现埋点全生命周期管理，规范埋点定义，沉淀组织过程资产，提升数据使用效率。我作为负责埋点管理项目的数据产品经理，经过对公司涉及埋点相关的角色，如产品经理、开发人员、测试人员、设计师、分析师等进行深度调研，企图了解其在工作中遇到的痛点和诉求。

对埋点数据使用者，如设计师、业务人员来说，他们遇到最大的困难是：在需要看某个数据时，通常不知道这个数据有没有埋点？具体的埋点信息是什么？应该去哪里看埋点数据？为什么这个埋点不能按照自定义参数筛选？

产品经理遇到的问题主要有两个：

开发人员说：现在的在线埋点文档真是太乱了，阅读体验极差，没有埋点变更信息记录，有数据质量问题时，数据溯源工作非常艰难。

测试人员：每次埋点测试都需要到数据库去查，由于SDK上报时机的原因，往往不能即时看到数据，需要等一定时间，比较耗费时间，如果不会写sql，那简直是难上加难，有时候遇到大版本迭代，一次性上线的埋点比较多，测试工作量巨大。

数据产品经理：业务经常找我问这个数据有没有埋点，埋点ID是什么？有哪些可以分析的维度？作为数据产品经理，这个时候通常比较懵逼，因为埋点信息都是分散在各个业务产品经理手上，大数据部门没有埋点元数据。有时，业务人员突然发过来一个埋点ID问，这个埋点怎么没数据，这个时候，产品经理往往需要先对问题做个筛选，比如，当前埋点是什么时候上线的，是不是因为刚发版，新老版本过渡期，数据还没报上来或者新版本流量较小，这时才发现，没有相关记录可以查。有时，上游业务系统发生变更，也不会通知下游，业务发现数据异常时，通常第一时间找数据产品经理，如果数据产品经理不知道上游埋点的变更，这时往往是一脸懵。

产品经理的素养告诉我，遇到问题，一定要透过现象，洞察其背后的本质。经过深入的思考，我认为造成以上痛点的原因有三方面的因素，分别为规范的因素、人的因素、工具的因素。

规范因素，未建立明确的流程规范。

制度层面缺少统一的流程及操作要求：埋点从需求到上线的流程是怎样的，埋点需求应该在哪里创建，维护，埋点元数据应该在哪里查询等，在制度上没有相关规定，有的业务产品经理认为：埋点文档不应该给业务的人看，业务用数据时，找大数据部门就好了，不应该找业务产品经理要埋点信息。可当前的现实是埋点元数据散落在各业务产品经理手上，数据产品经理也不知道埋点元数据。这样，用数据的人常常需要找多方沟通，才能拿到埋点信息，对业务来说，找数据极其困难。

埋点定义缺少统一标准和规范：比如对于自定义参数，有的开发以数组的形式存在一个字段里面，有的开发是将自定义参数存在分别上报到不同的字段里面，这种标准的不一致，不但会增加下游数据处理成本，也会对数据使用者造成一定的困惑，比如导致埋点数据不能通过自定以参数筛选。

特殊场景缺少规范指导：比如新版本增加了和已有埋点相同意义的埋点，是新增一个埋点ID还是用已有的埋点ID，增加参数区分所属埋点事件的位置等等。

人的因素，未规范录入信息。

只埋，不维护信息：当前大数据也提供了埋点录入工具，但是业务产品往往只在在线文档上维护埋点信息，只有用数据的时候才会来录入，导致埋点信息不全；

信息录入不完善：当前埋点管理平台仅有部分埋点ID和名称及所属应用，缺少埋点属性、位置归属等信息，不能提供完整的埋点元数据供数据使用者，导致数据理解困难；

信息无人持续维护：埋点变更、下线等情况无人维护，也没有通知下游进行影响评估，比如，某天业务突然找数据产品经理反馈，当前的数据值和埋点元数据不一致，数据产品经理需要去排查原因，有时候查了半天原因才发现是业务产品改版，所以变更了埋点导致了数据异常，但这种情况只有变更上线后才能发现，没法在事情发现，进行影响评估，也没法在事后通知相关方。

工具的因素，埋点管理工具还存在不足。

比如埋点位置结构无统一维护，针对同样的页面，不同的产品经理理解不一致，导致埋点归属混乱，就像图书馆的数没有目录和检索系统一样，找起来非常困难。

上面分析了在埋点管理方面遇到的痛点及其背后的原因，那如何系统化解决这些痛点呢？

第1步，建立规范埋点管理流程，定义清楚各方职责。

将埋点从需求到上线，分为四个大阶段，分别为需求阶段、埋点开发阶段、埋点测试阶段、埋点上线。埋点需求一般由业务方或者业务的产品经理提出，业务产品经理在埋点管理平台定义好埋点需求后，进行需求评审，评审通过后，进入埋点开发阶段，开发同学以埋点平台的埋点文档为基准，进行埋点代码的开发；开发完成后，进入测试阶段，测试同学以埋点管理平台的埋点文档为基准，进行埋点测试验收；测试通过后，需要对埋点标记上线，这样，埋点文档就从需求变成可供业务方使用的埋点元数据。大数据中心在接受数据时，会对数据进行质量校验，对于质量问题会通过邮件等方式推送给相关负责人去处理。各方的职责定义如下：

数据产品经理：制定标准和规范，维护应用信息和各SDK信息及采集规范；

业务产品经理：录入并维护埋点信息和各应用的页面层级信息；

开发人员：基于埋点文档，开发埋点代码；

测试人员：基于埋点文档，开发埋点代码。

第2步，统一并贯彻埋点标准

1、埋点归属的标准化：由数据产品经理统一维护公司所有应用信息，每个应用指定一个业务产品经理作为应用负责人，应用负责人负责维护应用的页面层级结构，保证所有产品经理共用一套标准；

2、自定义属性上报方式标准化。

有的开发是将自定义参数全部以数组的形式上报到params字段里，有的是分别上报的param1~param5里面，超过5个时，全部上报到params里面。经过和数据开发同学讨论，决定新增param6~param15，自定义参数依次上报至param1~param15，自定义参数超过15个时，联系数据产品经理处理。数据格式的一致，有利于下游数据的处理加工。

3、埋点ID命名标准化和产品化

之前各业务线埋点ID的命名是最初的产品经理制定的，各业务线规则也不一样，后来的产品经理一直沿用之前的标准，但随着埋点数量的增加，埋点ID不够用了，产品经理在写埋点文档时，经常要纠结如何命名才能和以前的埋点不重复，也没有系统辅助校验是否重复，在密密麻麻的在线文档中查询一遍，保证不重复，对产品经理来说是一件繁琐且枯燥无味的工作。经过对各业务线现有规则的调研，本着简单、易懂、不重复的原则，制定出各业务线通用的命名规则：

应用标识_一级页面_三位版本号_3位自增数字，如A1210001，A代表应用标识，1代表页面标识，210代表V2.1版本。

当产品经理在埋点管理平台录入埋点基本信息，如位置归属信息、埋点名称和类型后，系统会自动会按照规则自动生成埋点ID。

第3步，引入埋点管理工具

有了流程和标准规范，还需要有好用的工具去辅助落实标准和规范，因此我们决定引入埋点管理平台，实现埋点全生命周期的管理。

需求阶段，在埋点管理平台创建埋点文档，保证埋点定义的规范性、准确性；

埋点开发阶段，提供自动生成埋点代码的功能，提升埋点代码开发效率；

埋点测试阶段，提供辅助测试功能，提升测试工作效率；

数据校验，校验数据的准确性、一致性、完整性，保证埋点数据的质量；

数据使用阶段：提供友好的数据数据检索方式和灵活丰富的分析工具，提升找数据、理解数据、用数据的效率，让埋点数据真正被应用起来，数据只有被应用起来，才能发挥价值；

埋点下线：根据埋点的访问情况等因素，推送出建议建议下线的埋点，经影响评估后，针对可下线的埋点，作下线处理，避免数据只埋不用的问题。

埋点管理平台是埋点全生命周期管理和团队协作工具，提供埋点需求创建，辅助测试及开发、数据校验、埋点元数据查询、埋点数据分析、埋点下线等能力，解决埋点管理混乱，找数据难、理解数据难等问题。

产品的目标用户有产品经理、开发、测试、相关数据使用者。产品经理负责维护埋点元数据，开发人员基于产品经理创建的埋点文档开发埋点代码，测试人员测试验收埋点并上线，数据使用者主要查找埋点元数据，做埋点数据分析。

主要功能模块如下

应用管理：

 本模块维护应用及页面层级划分标准及基本信息。

属性管理：

 维护属性（参数）信息，分为预置属性和常用自定义属性，预置属性是提前预置到埋点SDK的属性，如用户ID、版本号等，自定义属性是根据具体埋点需求产品经理自己定义的属性。

需求管理

 本模块负责埋点需求的管理，支持单个新增和按照模板批量导入，每个埋点均归属于唯一的埋点集、应用、页面。埋点集是同一批次上线的埋点的集合，相当于文件夹的作用，方便开发和测试阅读埋点文档。

事件管理

本模块主要提供已上线埋点的检索功能，提供树形菜单的形式，方便用户在不清楚埋单ID的场景下可按应用逐级下钻查找。埋点变更信息也会维护在这里

质量监控

本模块支持配置监控规则和邮件提醒，校验接收到的数据和点元数据作对比，找出已接收到数据但没埋点信息的事件或有埋点信息但未接受到数据的事件，推送给相关负责人处理。也会从数据量、数据波动等方面检测的质量，及时发现异常数据。

埋点校验

本模块主要作用是辅助测试人员进行埋点测试，提升其效率。

数据分析

本模块主要是埋点相关的数据分的工具，比如概览看板、用户路径分析、转化漏斗分析、埋点数据查询等，帮助数据使用者快速使用数据。

整个埋点管理平台的建设是分三个阶段进行，第一阶段主要实现埋点历史数据和流程的线上化，提升找数据、理解数据的效率，这是后续工作的基础；第二阶段主要从数据使用角度出发，提升数据使用效率和体验，让数据更好的发挥价值；第三阶段，着力提升开发人员和测试人员的效率。

对公司来说，建设埋点管理平台，实现埋点系统化管理是需要投入不少资源的，那这件事值不值得做呢？做好埋点管理有什么价值呢？

在我看来，建设埋点管理平台的价值有三个方面，分别为：

1、沉淀数据资产和组织过程资产，降低找数据、理解数据，用数据的门槛

建设埋点管理平台之前，埋点元数据散落在各个业务产品经理手里，对数据使用者来说，每当用数据的时候经常陷入找数据难、理解数据难的困境，那埋点管理平台建成之后，所有业务线的埋点元数据均被维护在同一的平台上，平台提供多维检索功能，让数据使用者快速找到数据、理解数据，埋点变更等中间信息也会维护在埋点详情里面，埋点的前世今生一路了然。

2、提升数据质量，让数据更好的发挥价值

通过数据可以让我们能了解过去，知悉当下，预测未来，如同水电煤，深深影响着业务的决策，比如产品经理、设计师主要依赖埋点数据指导产品设计方案，开发人员依赖埋点数据进行bug定位，业务的一些核心指标更是通过埋点数据计算而来。试想一下，如果我们提供给业务的数据是错误的，那极有可能基于数据得出错误的信息，从而导致错误的决策，数据也就失去了其价值。所以，保证埋点数据的高质量是极其重要的事情。

3、提升研发、测试工作效率及团队协作效率

对于大的版本迭代，有时候一次性上线多大上百个埋点，其对开发和测试人员来说，是极其大的体力活，这时候如果平台可自动生成埋点代码，开发人员只需要复制代码插入到对应位置就可，会极大节约人工。

标准规范是方向，工具是将标准规范产品化，关键需要人去执行才能取得效果，所以，人是项目成败的关键因素，但往往人也是最大的变量。埋点管理涉及到多个部门的协同，另外，现存历史埋点也需要梳理后进行初始化，这些工作需要相关人员的密切配合，所以在项目立项时，数据产品经理需要努力获得上面的支持，能够自上而下去推进，最好推动成立跨部门的项目小组，具体工作、责任落实到人，避免相关人员的不配合，导致项目流于形式。那如果争取不到自上而下推动的机会该怎么办呢？这个时候就需要Plan B了，可以先找到愿意配合的业务线和他们合作，解决他们的痛点，有一定成效后，再慢慢推广到其他业务线。

1、千万别忘记用户。产品的诞生是为了满足某种需求或者解决某类问题的，千万不可闭门造车，闷头设计产品，等上线时再面对最终用户，一定要走出去，多和产品的目标用户聊，深入挖掘他们的痛点，让他们有参与感，获得用户的认可，尤其像埋点管理平台这种内部的工具性产品，产品诞生的时候，现有的用户习惯已经形成，比如产品经理们已经习惯使用在线文档去维护埋点信息，如果没有制度上的约束，如何让他们换到新平台上来呢，那就是过程中想办法让他们有强烈参与感，能把他们的一些想法融入到产品设计中，最终的产品方案获得他们的认可后再推进落地，当然了，这个过程对数据产品经理来说，是比较耗费精力的，但对产品经理来说，自己的产品能获得用户的认可，被广泛的使用，是一件有意义的事情；

2、在设计上，尽量考虑已有的用户习惯，避免大范围的改变用户习惯，触发用户的抵触情绪；

3、如果已有历史产品的情况下，要考虑兼容性。