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


陆小曼|数据产品经理:埋点的设计、管理与应用
文章图片
本文由作者董小矿于社区发布
前言:
本篇是从数据产品经理如何设计、管理和应用埋点的角度重新整理的文章 , 其中:1.埋点类型、2.1新增埋点设计、2.3产品指标地图部分的内容 , 与本人之前的文章有重叠 , 还请知晓 。
本文较长 , 目录如下:
1.埋点的类型1.1全埋点
1.2代码埋点
2.埋点的管理2.1新增埋点设计
2.2通用埋点设计
2.3产品指标地图
2.4版本迭代功能埋点管理
3.埋点应用3.1低垂的果实:可视化
3.2数据应用平台
3.3数据仓库
1埋点的类型
埋点:在期望的点位 , 埋设一个记录的标记 。 这个点位 , 一般多是指用户与产品进行一次次交互的接触点 。
通过收集这些标记点的数据 , 可以帮助产品运营及开发同学了解功能的整体使用、运行情况 , 并通过数据基础上做出下一步调整或优化的方向 。 遇事不拍脑袋 , 而是用数据说话 , 这是数据埋点最大的价值 。
在AB测试的场景下 , 数据埋点为实验组的效果提供数据支持 , 其本质也是数据决策的基础 。
根据目前常见的数据埋点形式 , 可以将数据埋点分为全埋点 , 和代码埋点(也就自定义埋点) 。
1.1全埋点全埋点的逻辑 , 是指数据采集sdk无区别的 , 将所有页面的加载成功事件 , 和控件的浏览和点击事件全部获取后先存下来 , 到使用的时候 , 再根据具体的页面路径和控件名称 , 去捞取相应的数据 。
基于此 , 可视化埋点是指 , 在全埋点部署成功、已经可以获得全量数据的基础上 , 以可视化的方式 , 在对应页面上定义想要的页面数据 , 或者控件数据 。
陆小曼|数据产品经理:埋点的设计、管理与应用
文章图片
图0:可视化埋点(也叫圈选)
这种方案的弊端之一是耗流量和存储空间 , 全埋点采集的数据一般会根据情况设定一个销毁时限 , 比如7天 。 即:全采集过来的数据 , 如果7天之内没有被使用 , 则会删除 。 而一旦对圈选数据做了圈选定义之后 , 则被定义的页面数据、控件数据 , 则会一直采集 , 且不会删除 。
全埋点 , 其优势和特点是功能上线时 , 不需要开发做额外的埋点定义工作 , 用的时候再根据需求去获取对应的数据 , 因此也叫无埋点 。
全埋点的缺点也很明显:
1)耗用户流量、占存储空间;
2)一旦版本迭代 , 对页面的路径做修改 , 或者控件位置、文案有修改 , 原来的圈选数据可能就会出错 , 需要重新圈选 , 之前利用圈选指标设定的分析模型都要替换;
3)圈选指标无法区分细部参数 , 比如:商品详情页 , 无法通过圈选数据来区分是哪一个商品或哪一个类目;
4)对web的页面数据处理一直不好 , 尤其是涉及到APP的内嵌H5页时 , 非常痛苦 。
因此 , 全埋点适用于业务多变、经常调整 , 且分析诉求比较轻量的场景 。 对于通用的功能 , 形态相对比较固定 , 且对数据分析颗粒度、下钻深度、聚合程度要求比较高 , 那就需要用到代码埋点
1.2代码埋点代码埋点也叫自定义埋点 , 从字面上即可理解:是针对想要的点位单独定义 , 并可以通过变量丰富埋点的信息 , 以支持上下游分析 。
代码埋点分为前端埋点和后端埋点 。
前端埋点 , 包括但不限于APP客户端、H5、微信小程序、PC网页 , 是指对具体的功能场景(如加载成功、浏览、点击等)进行明确的定义 , 由前端触发 , 采集上来的数据相比于全埋点 , 更准确、稳定 , 且通过变量字段 , 能够实现更细颗粒度数据的拆分、聚合和下钻 。
后端埋点 , 指触发了服务端接口调用(如:接口回调成功触发)的事件埋点 , 如最典型的注册成功事件、付费成功事件 。 后端埋点对数据的准确度要求更高 , 同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻 。 需要强调的是 , 后端事件一般采集的是已登录状态下的用户行为 , 如果想使用后端埋点事件作为流程分析的其中一环(如漏斗分析) , 则可能出现未登录的用户会漏掉的情况 。