【埋点体系】(二)-埋点设计、管理与应用_埋点文档

一、埋点的管理

1.1 新增埋点设计

1.1.1 埋点指标定义-事件表

一款互联网产品每天产生的数据是庞大杂乱的，全部都存下来会占据硬盘空间，而且，不加定义和标记的数据也很难使用。因此，在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事，你想要的数据有哪些，定义这些数据的字段包括但不限于以下字段：

埋点位置：平台覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；

功能模块：对应埋点所属的大功能板块，如【电子书】功能模块，会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因：对于我司业务，区分度比较高，功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异；

埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：

 而开发同事关注的是下面这些字段：

 因此针对同一个埋点，至少要考虑的是以上这些字段，更大平台的埋点字段会更多。

其中，比较难处理的是【触发时机】的准确定义和描述，举个例子，某页面的pv数据，触发时机定义成加载和加载成功，会是完全不同的数据；又比如，首页模块（也有叫楼层）浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；

事件变量定义：用来定义事件的参数，也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理，我司实践是把二表合二为一）。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。

当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标约精简越好，便于理解和管理，但可能对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。

举一例，电商产品，商品详情页的事件变量怎么设计，见下图：

这里你可能会有疑问，如果是传一个【商品id】，其实也就可以通过【商品信息表】，把【商品名称】、【品牌】、【一二级类目】给查出来了，为什么还需要传？

这里就涉及到指标管理与数据使用便捷性的权衡：如果不传，在使用的时候免不了要跨表联查，是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式，来保证数据能比较高效使用，最大化数据的价值。

其他说明：变量值类型，比较常见的有：int、float、boole、string、timestamp；埋点形式，对于自己研发的数据采集系统，一般前端埋点和服务端埋点可以了，如果外采第三方数据采集服务，可能还会有全埋点（详细见上篇文章）；埋点版本和日志，则是帮助你和开发快速回忆这个点的前世今生。

牢记：好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。

以上，综合下来，以电商商详页举例，一个埋点事件最后的字段如下：

 1.1.2 埋点指标定义-用户表

用户表，记录用户信息、用户属性的表，通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联。事件与用户实现关联，事件表里一条条的数据记录，就不会再是孤立的统计数字，而是能够与具体的用户产生关联进行分析，或者用行为来圈定用户，给用户设定分群和标签。

用户表的自定义维度设计与业务关联度最高，除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外，其他偏业务属性字段需要一个比较全局的视角，不仅要与数据运营方沟通，而是要与公司每一个有分析诉求的部门进行沟通，采集他们的数据分析诉求，来提炼抽象出比较通用的用户表。

如上面提到的，如果只是从事件表里把上报的数据聚合成统计数字或者图标，是没有很大意义的，还要能够下钻进行分析。事件表中变量字段的设计是为了从事件反映的用户行为侧进行下钻，而用户表的属性字段则是基于从产生行为的用户本身进行下钻。

举简单一例：当日商品详情页的总浏览数据是上升的，但是总GMV确没有明显提高，从事件侧分析，发现某类异业合作主推的单品商详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。

从此得出的初步判断是：1）单本对渠道A的用户拉新效果明显；2）但是该类用户被吸引来了，却没有下单，很奇怪，需要确认投放落地页与站内商品信息是否一致，尤其是价格；3）该类用户对平台其他商品的兴趣不高。

说回用户表的属性字段设计，回到那句核心：采集共性诉求，提炼出通用、容易理解的用户表。这个工作其实并不难，考验的是数据PM沟通、提炼真实诉求，并整合成具体的需求的能力。以我司做内容服务的平台举例，用户属性表如下，基本覆盖了通用的用户群的分析：

1.1.3 埋点指标定义-默认属性

除了前面提到的自定义事件和用户属性外，一般客户端或者第三方数据采集SDK还会采集一些默认的属性信息，这些可能不需要你单独去定义，但数据PM需要去了解平台获取的默认字段有哪些。

 

 

 1.2 通用埋点设计

在自定义埋点设计中，有一些通用的事件往往是比较复杂的，而且随着业务发展，会变得越来越复杂。比如，APP平台的分享事件，如果按功能模块，每个功能模块都设计了自己的分享事件，则这个事件会越来越分散，且想聚合做复合指标时，如通过分享/日活来衡量内容质量，分享事件要先聚合平台各功能模块的分享事件，太分散会产生应用上的问题。

所以，我的建议仍然是将通用类型的埋点统一进行管理，通过变量字段进行拓展，来满足多功能模块的埋点需求。还是以分享事件举例，可以通过多个变量来进行区分。

对于通用埋点，有更新时（上新功能，或者下旧功能），就将对应type字段的埋点和值进行更新即可。（另：写上指标变更记录）

1.3 数据指标地图

数据能力推广的第一个难点，是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标，我曾经采用的是excel的方式进行管理，问题是指标一多起来，找起来不太方便，对于定义者（我）来说自然很容易找到，但是对于使用者来说则不太友好。即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。

因此在数据指标表的第一个sheet，设计了一个数据指标地图，将不同功能模块的数据指标进行了拆解和说明，运营同事找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。

 另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和大数据组一起来明确具体内容了，这个工作并不复杂，就是需要开个小会进行确认，并且约定好，新增表格时，及时更新对表格的解释。

1.4 版本迭代功能埋点管理

随着版本迭代有新功能的埋点，或者针对之前功能的优化，所以需要对之前埋点进行调整。从埋点管理的角度，新增/修改的埋点，需要整合到之前的埋点系统里，这样能够方便使用者查阅整体的埋点明细。

下面是我基于使用Excel来管理APP版本迭代中埋点更新时的解决方案，我并不认为是最优解，所以仅做参考。

背景：APP迭代周期为两周一个版本，有3位功能产品经理，他们负责具体功能的设计和产品跟进，在设计产品功能时，也会提交与功能相关的埋点需求，在经过功能评审后，会和我就功能埋点进行一次沟通，然后将确定的埋点需求梳理出来。

处理流程：功能在经过需求评审（=技术评审）后，基本确定了这一次要做的功能点，因此也可以梳理出要做的埋点有哪些。所以从这个节点的处理流程是：

1）功能产品经理（后称功能PM）梳理相应的埋点清单（按照符合总表设计逻辑的字段进行梳理）；

2）功能PM与数据产品经理（后称数据PM）做内部评审，评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单；

3）功能PM与开发进行埋点需求评审，数据PM可旁听。

举一例：功能产品对签到功能进行优化，涉及到新增一些页面的分享功能，其最初提交的埋点需求如下图，标红的是分享相关的埋点需求：

（数据PM需要要求功能PM按照统一的字段进行埋点的设计，初期的事件定义或者变量定义或许不规范，没关系，这个能力可以随着做几个版本逐步提高，但是字段规范一定要先定义好）

图11：功能产品提交的相关埋点清单

在评审这期埋点前，数据PM查看在总表里，有分享相关的埋点：

图12：查阅总表，分享事件之前已经有签到功能的埋点 

根据我们前面提到的原则，类似【分享】这类通用的功能组件，不要重复造轮子，而是要统一到一个事件上，通过类型来处理，因此，针对例子中的功能点，也将其提出的分享埋点，合并到总表中，如下图：

图13：通过新增类型解决埋点需求 

然后，功能PM将仅该版本所涉及到的埋点拎出来，单独整理一份埋点文档，这份文档是单独给开发来看的，这样做的好处是：让开发同事只关注这个功能点相关的埋点就可以（我习惯通过颜色标记来进行区分）：

 图14：给开发看的埋点文档

如果是第一次这样做，需要跟开发说清楚：这份文档里标颜色的，是这个功能迭代中需要新增/修改的点，没有在文档里看到的type类型的埋点，不是删掉，而是不要动（曾经有位憨厚的小哥，因为没沟通清楚，认为不在表格文档里的，都是要删了的，删了一半了，才找我沟通......）。

关于版本迭代中的埋点管理，相比于excel一定要更好的工具化的管理办法，之前跟一个同行聊过，他们采用的方案是，做一个web端平台，可以看到所有的埋点。同时，功能PM可以在该平台上按照字段要求提交自己的埋点需求，然后走审批流程，能够进入开发的埋点，会打上版本标记，待上线后，对应的埋点会出现在平台总表里，供使用者查看。这个方案就很不错，本来计划推这套平台，后来我因个人原因离开了这家公司，就没有再继续。

上面这个方案适用于有一定体量的公司，个人认为在C轮之前的公司，大多都是没有精力去做这样一套数据指标管理平台的。

1.5 埋点实践中可能会遇到的问题和解决方案

1.埋点设计过程中不注意事件和属性的命名规范，导致埋点无法使用或难以理解

这个问题在很多企业中都有出现，一开始的时候随便起一个事件名或属性名，也没有标准的规则去限制。这种做法在埋点比较少的时候还勉强适用，但是一旦业务线增加，埋点数量成倍上升的时候，就会出现混乱：比如有同事离职，下一个同事交接项目时，根本无法理解前一位同事是如何设计埋点的；还有就是如果埋点设计工作是由不同业务线的同事完成的，没有命名规范的话就会出现混乱，开发同事和分析数据的业务同事都会相当痛苦。这些问题会导致之前辛辛苦苦开发出来的埋点无法被使用，进而需要额外花很大的力气去做数据治理。

与其在后面亡羊补牢，不如在前期就定好规则让所有同事去遵守，减少后续不必要的治理成本。埋点事件的命名规则没有标准答案，只需要结合企业目前的发展现状，比如拥有产品线（app、小程序等）的个数、业务线个数等进行制定即可。一般来说，可以依照“产品线_业务线_页面名称（按钮名称）_动作”这个规则，比如说“app_ShengXian_BuyNowIcon_Click”（app中生鲜业务线内“立即购买”按钮点击），企业也可以根据部门和业务线划分去自定义规则。

2.埋点可解释性差，需要花费时间进行理解

如果第一个问题说的是埋点命名不规范，那么第二个问题就是使用埋点的人不知道某个埋点是埋在了哪里，以及该埋点的确切含义，想要使用某个埋点也是胆战心惊，需要不断询问埋点开发的同事或者靠自己的理解瞎猜，这极有可能会导致数据结果偏差，进而得出错误的业务决策，而且需要额外花费时间进行理解，降低工作效率。

解决这个问题可以通过“埋点地图”的方式实现，方法也很简单，就是每次在设计埋点的时候，顺手把该埋点涉及的页面或者按钮截图并圈选，放在埋点需求文档的第一列或者最后一列，如果有必要的话可以在备注列进行补充说明。这样可以方便开发同事理解需求，避免埋错点，也可以让使用埋点的业务同事快速了解点位埋在了哪里，减少无效的沟通成本。如果有余力的企业还可以开发一套属于自己的埋点管理平台，业务同事将要埋的点位截图上传并做简单说明，开发同事依照平台上的需求进行埋点，验收上线后即可便捷使用，这样就可以减少维护文档带来的不便，尤其适用于业务线多，场景复杂的企业。

3.埋点冗余，浪费开发资源

即使解决了问题（1）和（2），还是不可避免会出现埋点事件或属性的冗余，因为每位同事的埋点设计习惯不同。比如同样都是页面浏览这个行为，有的同事会用page_name（页面名称）这个属性，有的同事会用page_title（页面标题），但是这两个属性都代表用户浏览的是哪个页面，很明显可以统一这两个属性。从这个例子可以看出，如果不加以限制，就会出现事件或属性冗余的情况，浪费开发资源和服务器资源。

为了能让各个事件和属性名称重复利用最大化，在前面埋点规则和埋点地图的基础上，我们可以设计一个“埋点资源库”，内含所有之前已经被使用过的埋点事件名和属性名，如果在后续设计过程中发现有的名称可以被重复使用，则可以直接利用而不是重新设计。但是，如果某个企业是通过文档去迭代埋点的话，该方法会比较麻烦，因为检索之前用过的名称需要时间和精力，如果有能力且有资金和资源的话，最好是设计在第（2）个问题中所述的埋点管理平台，直接通过系统管理埋点资源池，方便又高效。

二、埋点应用

埋点有了，能采集到之前获取不到的数据了，下一步该如何使用，下面是从我的经验总结的，数据从浅层应用，向深层应用传递的应用场景。

2.1 可视化

结合业务日志，以及埋点采集上来数据，如何让数据立刻产生价值？我建议先去做可视化。建议原因：前期的数据采集、录入、清洗耗时耗力，对于领导来说，铺人力做一件看不到产出的事情，时间久了自然有点质疑。

而对于数据本身来说，完成清洗后的数据能最快应用的方面就是做可视化，对于每天要看excel数据的领导来说，可视化的东西也是能让ta感到明确不同的产品，取得上层认可，对于后期推进数据项目绝对有利。

在做可视化这个阶段，建议使用已经成熟的产品框架，不要花精力去自研。说白了，这个阶段的主要目的是让数据采集的产出最快体现出价值来，得到相关部门认可，给自己项目团队成员以信心的，所以拿来主义，一切从简。

2.1.1 数据大屏

数据大屏的视觉冲击力强，对于关注整体指标的领导层来说，大屏解决了他们快速掌握全局数据的需求，另外，如果贵司常要接待其他单位或者到外面汇报、参展，动态数据大屏绝对是曝光度最高的产品。

 2.1.2 开源数据展示工具

数据大屏满足了展示类需求，但是定制化一点的、操作类需求，数据大屏满足不了。这时可以考虑使用别的工具，其核心就是通过该工具平台，连接数据库，读取数据后进行展现，并且可以按照一定的维度，如日期、周期、item名称等维度聚合数据，形成一个个看板。看板里的单图支持源数据下载、和简单的SQL取数。能够解决略进一层的数据展示和分析诉求。

工具推荐：Superset、Grafana

2.2 数据应用平台

数据终究要产生业务价值的，上面提到的数据展示工具，无法以可视化形态做业务分析。数据需要结合具体的业务场景，然后选择成熟的分析场景，如：事件分析、漏斗分析、留存分析、归因分析等，以及更深度的用户画像、精准营销，才能真正赋能业务。

这类数据应用工具，目前已经有成熟厂商提供了标准化产品，如果公司规模没有达到自研数据平台时，建议采购。推荐平台：GrowingIO、神策、TalkingData

2.3 数据仓库

数据采集、录入，最终会落入到数据仓库中，成为数据仓库中的“弹药”。从19年大火的“数据中台”，去掉面子，里子就是一个数据仓库。数据仓库汇聚各业务端的原始数据，和主题数据，其建设过程是一个随着业务发展不断更新的过程。只是做数据的ETL本身并不是数据仓库的价值，其核心是能够收录好业务侧需要使用的数据，或者在业务侧提出新的数据需求时，能够快速响应。

按照数据仓库设计的经典三层结构：ODS层、EDW层、DM层，数据产品经理在数据仓库建设中的工作职责，是：

1）约定进入ODS层的原始数据的维度、周期；

2）定义EDW层主题宽表的字段、周期；

3）设计DM层应用表的字段、周期（需要结合具体业务，设计尽可能通用的主题表、应用表）；

4）设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。

参考资料：

1.微信公众号（大数据学习与分享）-《数仓埋点体系 | 埋点设计、管理与应用》