数据产品经理：埋点的设计、管理与应用
文章图片
本文由作者董小矿于社区发布
前言：
本篇是从数据产品经理如何设计、管理和应用埋点的角度重新整理的文章 ， 其中：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网页 ， 是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义 ， 由前端触发 ， 采集上来的数据相比于全埋点 ， 更准确、稳定 ， 且通过变量字段 ， 能够实现更细颗粒度数据的拆分、聚合和下钻 。
后端埋点 ， 指触发了服务端接口调用（如：接口回调成功触发）的事件埋点 ， 如最典型的注册成功事件、付费成功事件 。 后端埋点对数据的准确度要求更高 ， 同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻 。 需要强调的是 ， 后端事件一般采集的是已登录状态下的用户行为 ， 如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析） ， 则可能出现未登录的用户会漏掉的情况 。
综合以上 ， 几种埋点类型的比较
文章图片
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、SQLServer ， 另一方面前端有多种展示组件 ， 并支持自定义 。 部署和维护起来都比较轻便 。
文章图片
图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测试工具 ， 有的公司定义为增长产品经理的工作范畴 ， 在我看来 ， 属于应用侧的数据产品经理工作范畴了 。 这里也不纠结啦 ， 产品经理是块砖 ， 哪里需要往哪搬嘛~
------正文分割线------
【数据产品经理：埋点的设计、管理与应用】
文章图片
推荐阅读
- 紫外线、黑色素通通走开！2020日本夏季最新话题「防晒产品」收拾整顿
- 科技日报|功能性玉米被端上餐桌 这个数据库帮了大忙
- 美国疫情比想象更严重！英美发现大问题，或将推翻此前所有数据
- 每年存一万或缴纳社保，哪种方式更合适养老，别急，让数据说话！
- 粟说河峪——山西五福农产品股份有限公司
- 开黑新使者|到底谁才是迈特凯？Theshy和Nuguri数据对比，牛老师参上！
- 中年|画像“标签”生产实操指南(二)之产出清晰的标签数据需求
- ai|产品经理在创造AI，到底在创造什么
- 数据中心|为什么下一个十年的大战场在数据中心？
- 联邦机构窃取用户数据，美国竟觉得完全“合理合法”