陆小曼数据产品经理：埋点的设计、管理与应用( 二 ) 本文由作者董小矿于社区发布

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

文章图片
2埋点的管理
比较完几种类型埋点的特点，在具体的功能场景时，就要根据情况选择对应方案，进行埋点方案的设计了。全埋点不需要设计，这里的埋点管理主要是围绕自定义埋点展开。
2.1新增埋点设计2.1.1埋点指标定义-事件表
一款互联网产品每天产生的数据是庞大杂乱的，全部都存下来会占据硬盘空间，而且，不加定义和标记的数据也很难使用。因此，在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事，你想要的数据有哪些，定义这些数据的字段包括但不限于以下字段：

文章图片
图1：埋点指标定义
上图是我目前管理我司平台埋点的字段，分别解释下：
埋点位置：我司平台覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；
功能模块：对应埋点所属的大功能板块，如【电子书】功能模块，会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因：对于我司业务，区分度比较高，功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异；
埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：

文章图片
图2：运营同事关注的字段
而开发同事关注的是下面这些字段：

文章图片
图3：开发同事关注的字段
因此针对同一个埋点，至少要考虑的是以上这些字段。（更大平台的埋点字段会更多，欢迎交流）
其中，比较难处理的是【触发时机】的准确定义和描述，举个例子，某页面的pv数据，触发时机定义成加载和加载成功，会是完全不同的数据；又比如，首页模块（也有叫楼层）浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；
事件变量定义：用来定义事件的参数，也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理，我司实践是把二表合二为一）。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。
当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标约精简越好，便于理解和管理，但可能对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。
举一例，电商产品，商品详情页的事件变量怎么设计，见下图：

文章图片
图4：商品详情页事件变量
这里你可能会有疑问，如果是传一个【商品id】，其实也就可以通过【商品信息表】，把【商品名称】、【品牌】、【一二级类目】给查出来了，为什么还需要传？
这里就涉及到指标管理与数据使用便捷性的权衡：如果不传，在使用的时候免不了要跨表联查，是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式，来保证数据能比较高效使用，最大化数据的价值。

陆小曼 数据产品经理：埋点的设计、管理与应用( 二 )

陆小曼数据产品经理：埋点的设计、管理与应用( 二 )