数据仓库实战之埋点设计与应用

问题导读：

1、埋点分为哪些类型？
2、怎样设计与管理埋点？
3、埋点有哪些应用？



1.埋点的类型
埋点：在期望的点位，埋设一个记录的标记。这个点位，一般多是指用户与产品进行一次次交互的接触点。

通过收集这些标记点的数据，可以帮助产品运营及开发同学了解功能的整体使用、运行情况，并通过数据基础上做出下一步调整或优化的方向。遇事不拍脑袋，而是用数据说话，这是数据埋点最大的价值。

在AB测试的场景下，数据埋点为实验组的效果提供数据支持，其本质也是数据决策的基础。

根据目前常见的数据埋点形式，可以将数据埋点分为全埋点，和代码埋点（也就自定义埋点）。

1.1 全埋点

全埋点的逻辑，是指数据采集sdk无区别的，将所有页面的加载成功事件，和控件的浏览和点击事件全部获取后先存下来，到使用的时候，再根据具体的页面路径和控件名称，去捞取相应的数据。

基于此，可视化埋点是指，在全埋点部署成功、已经可以获得全量数据的基础上，以可视化的方式，在对应页面上定义想要的页面数据，或者控件数据。


图0：可视化埋点（也叫圈选）

这种方案的弊端之一是耗流量和存储空间，全埋点采集的数据一般会根据情况设定一个销毁时限，比如7天。即：全采集过来的数据，如果7天之内没有被使用，则会删除。而一旦对圈选数据做了圈选定义之后，则被定义的页面数据、控件数据，则会一直采集，且不会删除。

全埋点，其优势和特点是功能上线时，不需要开发做额外的埋点定义工作，用的时候再根据需求去获取对应的数据，因此也叫无埋点。

全埋点的缺点也很明显：

1）耗用户流量、占存储空间；

2）一旦版本迭代，对页面的路径做修改，或者控件位置、文案有修改，原来的圈选数据可能就会出错，需要重新圈选，之前利用圈选指标设定的分析模型都要替换；

3）圈选指标无法区分细部参数，比如：商品详情页，无法通过圈选数据来区分是哪一个商品或哪一个类目；

4）对web的页面数据处理一直不好，尤其是涉及到APP的内嵌H5页时，非常痛苦。

因此，全埋点适用于业务多变、经常调整，且分析诉求比较轻量的场景。对于通用的功能，形态相对比较固定，且对数据分析颗粒度、下钻深度、聚合程度要求比较高，那就需要用到代码埋点

1.2 代码埋点

代码埋点也叫自定义埋点，从字面上即可理解：是针对想要的点位单独定义，并可以通过变量丰富埋点的信息，以支持上下游分析。

代码埋点分为前端埋点和后端埋点。

前端埋点，包括但不限于APP客户端、H5、微信小程序、PC网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细颗粒度数据的拆分、聚合和下钻。

后端埋点，指触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付费成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端事件一般采集的是已登录状态下的用户行为，如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况。

综合以上，几种埋点类型的比较



2.埋点的管理

比较完几种类型埋点的特点，在具体的功能场景时，就要根据情况选择对应方案，进行埋点方案的设计了。全埋点不需要设计，这里的埋点管理主要是围绕自定义埋点展开。

2.1 新增埋点设计

2.1.1 埋点指标定义-事件表

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


图1：埋点指标定义

上图是我目前管理我司平台埋点的字段，分别解释下：

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

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

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


图2：运营同事关注的字段

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


图3：开发同事关注的字段

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

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

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

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

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


图4：商品详情页事件变量

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

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

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

如果这篇文章你只记住一句话，我希望是：好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。

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


图5：举例-商品详情页事件指标设计

2.1.2 埋点指标定义-用户表

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


图6：事件表和用户表的关联

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

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

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

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

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


图7：用户表维度举例

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

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




图8：默认采集字段（部分）

2.2 通用埋点设计

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

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


图9：分享埋点事件

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

2.3 数据指标地图

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

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


图10：数据指标地图

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

2.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轮之前的公司，大多都是没有精力去做这样一套数据指标管理平台的。

3.埋点应用

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

3.1 低垂的果实：可视化

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

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

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

低垂果实1：数据大屏

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

我司采用的是阿里云的DataV工具，可按月付费（350一个月）。这个工具一方面可支持多种数据库，如MySQL、SQL Server，另一方面前端有多种展示组件，并支持自定义。部署和维护起来都比较轻便。


图15：数据大屏

低垂果实2：开源数据展示工具

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

工具推荐：Superset、Grafana


图16：superset截图

3.2 数据应用平台

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

这类数据应用工具，目前已经有成熟厂商提供了标准化产品，如果公司规模没有达到自研数据平台时，建议采购。推荐平台：GrowingIO、神策 （两个平台各有特点，可参看之前文章）

3.3 数据仓库

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

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

1）约定进入ODS层的原始数据的维度、周期；
2）定义EDW层主题宽表的字段、周期；
3）设计DM层应用表的字段、周期（需要结合具体业务，设计尽可能通用的主题表、应用表）；
4）设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。


以上，是数据产品经理关于数据基础能力建设（数据埋点、数据工具、数据仓库）过程中的部分工作内容，基于此，做用户标签、精准推荐、AB测试工具，有的公司定义为增长产品经理的工作范畴，在我看来，属于应用侧的数据产品经理工作范畴了。这里也不纠结啦，产品经理是块砖，哪里需要往哪搬嘛~

最新经典文章，欢迎关注公众号

---------------------

作者：数据仓库与Python大数据
来源：weixin
原文：数仓埋点体系 | 埋点设计、管理与应用