江苏龙网

  1. 首页 > 人文 > >

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


综合以上 ， 几种埋点类型的比较
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
2埋点的管理
比较完几种类型埋点的特点 ， 在具体的功能场景时 ， 就要根据情况选择对应方案 ， 进行埋点方案的设计了 。 全埋点不需要设计 ， 这里的埋点管理主要是围绕自定义埋点展开 。
2.1新增埋点设计2.1.1埋点指标定义-事件表
一款互联网产品每天产生的数据是庞大杂乱的 ， 全部都存下来会占据硬盘空间 ， 而且 ， 不加定义和标记的数据也很难使用 。 因此 ， 在初期的数据建设阶段 ， 先要做的是定义想要的数据 ， 告诉前端开发和后台的同事 ， 你想要的数据有哪些 ， 定义这些数据的字段包括但不限于以下字段：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图1：埋点指标定义
上图是我目前管理我司平台埋点的字段 ， 分别解释下：
埋点位置：我司平台覆盖了APP、Web和小程序平台 ， 其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页） ， 分开管理会造成指标冗余 ， 因此对于多平台存在的核心指标 ， 采用的是统一事件名定义 ， 不同平台触发时 ， 数据上报到同一个事件名上 ， 通过平台类型（platform_type）进行拆分；
功能模块：对应埋点所属的大功能板块 ， 如【电子书】功能模块 ， 会尽可能把属于电子书的埋点事件放到该模块进行管理 。 这里解释下没有向下拆解子功能模块的原因：对于我司业务 ， 区分度比较高 ， 功能模块+具体事件名就能够快速定位到想要的指标了 。 这点因公司而异；
埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高） ， 对于运营同事来说 ， 他们要关注的字段是下面这些：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图2：运营同事关注的字段
而开发同事关注的是下面这些字段：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图3：开发同事关注的字段
因此针对同一个埋点 ， 至少要考虑的是以上这些字段 。 （更大平台的埋点字段会更多 ， 欢迎交流）
其中 ， 比较难处理的是【触发时机】的准确定义和描述 ， 举个例子 ， 某页面的pv数据 ， 触发时机定义成加载和加载成功 ， 会是完全不同的数据；又比如 ， 首页模块（也有叫楼层）浏览 ， 模块长短不一 ， 到何种深度会触发对应模块的浏览 ， 需要定义时想清楚 ， 与开发沟通实现细节 ， 避免后期踩坑；
事件变量定义：用来定义事件的参数 ， 也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理 ， 我司实践是把二表合二为一） 。 该字段决定了事件的颗粒度 ， 直接影响到事件下钻的颗粒度 ， 对于数据PM来说 ， 平台不同位置的事件抽象后 ， 尽可能提取出公用事件 ， 然后通过事件变量进行区分 ， 能减少：指标冗余、指标管理工作、培训成本 ， 以及使用者的学习成本 。
当然这里也并不完全执着于抽象公用性 ， 对于数据PM和开发来说 ， 指标约精简越好 ， 便于理解和管理 ， 但可能对于运营同事来说 ， 学习和使用成本高企 ， 数据产生了但无法最大化应用侧价值 ， 那就得不偿失 ， 所以需要平衡 。
举一例 ， 电商产品 ， 商品详情页的事件变量怎么设计 ， 见下图：
陆小曼|数据产品经理：埋点的设计、管理与应用
文章图片
图4：商品详情页事件变量
这里你可能会有疑问 ， 如果是传一个【商品id】 ， 其实也就可以通过【商品信息表】 ， 把【商品名称】、【品牌】、【一二级类目】给查出来了 ， 为什么还需要传？


推荐阅读


上一篇：烟草味道|麒麟1020成为“绝版”？任正非早有后手，华为旗舰采用联发科芯片

下一篇：草莓味的棉花糖|一年前我们就可以了，中兴7nm芯片量产？中兴老总