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

文章图片
本文由作者董小矿于社区发布
前言：
本篇是从数据产品经理如何设计、管理和应用埋点的角度重新整理的文章，其中：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网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细颗粒度数据的拆分、聚合和下钻。
后端埋点，指触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付费成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端事件一般采集的是已登录状态下的用户行为，如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况。