数据埋点:埋点治理面对的项目管理问题

埋点项目管理

数据埋点项目流程

  • 梳理埋点需求(分析指标体系)
  • 制定埋点规则
    • 命名的规范化
    • 埋点流程统一化
  • 制定埋点数据的清洗规则
    • 数据清洗规范化
  • 维护埋点的测试、上线、下线
  • 维护埋点元数据(埋点管理系统)

埋点项目示例

项目管理问题

内部信息障碍

  • 开发人员疑虑
    • 埋点文档太乱,阅读体验极差;
    • 没有埋点变更信息记录,有数据质量问题时,数据溯源工作非常艰难。
  • 测试人员疑虑
    • 每次埋点测试都需要到数据库去查;
    • 由于 SDK 上报时机的原因,往往不能即时看到数据,需要等一定时间,比较耗费时间;
    • 如果不会写 sql,测试查询会非常困难;
    • 有时候遇到大版本迭代,一次性上线的埋点比较多,测试工作量巨大。
  • 数据产品疑虑
    • 业务经常会问这个数据有没有埋点,埋点ID是什么?有哪些可以分析的维度?但是埋点信息都是分散在各个业务产品经理手上,大数据部门没有埋点元数据。
    • 当前埋点是什么时候上线的,是不是因为刚发版,新老版本过渡期,数据还没报上来或者新版本流量较小,这时才发现,没有相关记录可以查。
    • 有时,上游业务系统发生变更,也不会通知下游,业务发现数据异常时,通常第一时间找数据产品经理,如果数据产品经理不知道上游埋点的变更,这时往往是一脸懵。

埋点需求混乱且缺少管控

  • 当新功能或活动上线时会提很多埋点需求,数据产品在这个环节如果对埋点需求没有明确的提需规范和把控,就会导致埋点需求爆炸,对于开发和维护成本都是压力;
  • 并且后续做数据分析的时候经常会发现数据不可用或数据不准确,那其实后续排查问题的成本非常大,

未明确埋点要统计哪些指标

  • 数据产品在评审埋点需求的时候很重要的一点就是:明确埋点要统计哪些指标;
  • 埋点统计是服务于指标的,如果对埋点需求没有管控放任提需,经过几个版本的迭代就会发现埋点维护很难;

埋点需求不规范

  • 埋点需求规范的价值是帮助业务方和数据产品拉齐对即将开发的埋点认知一致;
  • 在设计埋点提需规范时,不仅仅要让业务方标明要统计哪些指标、事件如何规划、触发时机,最好能写出每个自定义参数的触发时机、参数打在哪个层级、是否需要透传等;
  • 埋点提需规范越详细越好,可以帮忙拉齐各方对埋点的认知。

业务接口人素质参差不齐

  • 需求接口人这个角色很重要,没有接口人的话仅靠数据产品跟业务对接,在大体量和复杂业务场景的公司里是不现实的;
  • 所以接口人的定位是埋点需求 master,甚至是数据需求 master,需要将业务方、开发、测试、数据产品等连接起来;
  • 建议接口人可以考虑经常对接埋点需求的业务,或是有开发背景的业务方,这样沟通起来会方便一些。

未规范录入信息

  • 虽然提供了埋点录入工具,但是业务产品往往只在在线文档上维护埋点信息,只有用数据的时候才会来录入,导致埋点信息不全;

信息录入不完善

  • 例如:
    • 埋点管理平台仅有部分埋点 ID 和名称及所属应用,缺少埋点属性、位置归属等信息,不能提供完整的埋点元数据供数据使用者,导致数据理解困难;

只埋点、不维护

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

缺乏埋点生命周期管理

  • 缺少生命周期的管理一味放任熵增,后续治理的成本实在很高,所以埋点生命周期的管理必不可缺;
  • 简单来说要做好后续埋点梳理、埋点瘦身、埋点升级的工作,定期统计一段时间内低频上报的埋点和这些埋点相关指标、报表的访问量,以此为依据开展埋点生命周期管理工作;
  • 对于埋点需求的提出、评审、开发、测试、验收、上架、修改、下架,必须要做持续的全流程、全生命周期的管控;

规范制度层面问题

制度层面缺少统一的流程及操作要求

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

埋点定义缺少统一标准和规范

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

特殊场景缺少规范指导

  • 比如新版本增加了和已有埋点相同意义的埋点,是新增一个埋点ID还是用已有的埋点ID,增加参数区分所属埋点事件的位置等等。

埋点元数据管理混乱

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