本文由作者 董小矿 于社区发布
前言：
本篇是从数据产品经理如何设计、管理和应用埋点的角度重新整理的文章，其中：1.埋点类型、2.1新增埋点设计、2.3产品指标地图部分的内容，与本人之前的文章有重叠，还请知晓。
本文较长，目录如下：
1.1 全埋点
1.2 代码埋点
2.1 新增埋点设计
2.2 通用埋点设计
2.3 产品指标地图
2.4 版本迭代功能埋点管理
3.1 低垂的果实：可视化
3.2 数据应用平台
3.3 数据仓库
1埋点的类型埋点：在期望的点位，埋设一个记录的标记。这个点位，一般多是指用户与产品进行一次次交互的接触点。通过收集这些标记点的数据，可以帮助产品运营及开发同学了解功能的整体使用、运行情况，并通过数据基础上做出下一步调整或优化的方向。遇事不拍脑袋，而是用数据说话，这是数据埋点最大的价值。在AB测试的场景下，数据埋点为实验组的效果提供数据支持，其本质也是数据决策的基础。根据目前常见的数据埋点形式，可以将数据埋点分为全埋点，和代码埋点（也就自定义埋点）。
图0：可视化埋点（也叫圈选）这种方案的弊端之一是耗流量和存储空间，全埋点采集的数据一般会根据情况设定一个销毁时限，比如7天。即：全采集过来的数据，如果7天之内没有被使用，则会删除。而一旦对圈选数据做了圈选定义之后，则被定义的页面数据、控件数据，则会一直采集，且不会删除。全埋点，其优势和特点是功能上线时，不需要开发做额外的埋点定义工作，用的时候再根据需求去获取对应的数据，因此也叫无埋点。全埋点的缺点也很明显：
1）耗用户流量、占存储空间；
2）一旦版本迭代，对页面的路径做修改，或者控件位置、文案有修改，原来的圈选数据可能就会出错，需要重新圈选，之前利用圈选指标设定的分析模型都要替换；
3）圈选指标无法区分细部参数，比如：商品详情页，无法通过圈选数据来区分是哪一个商品或哪一个类目；
4）对web的页面数据处理一直不好，尤其是涉及到APP的内嵌H5页时，非常痛苦。
因此，全埋点适用于业务多变、经常调整，且分析诉求比较轻量的场景。对于通用的功能，形态相对比较固定，且对数据分析颗粒度、下钻深度、聚合程度要求比较高，那就需要用到代码埋点
2
埋点的管理比较完几种类型埋点的特点，在具体的功能场景时，就要根据情况选择对应方案，进行埋点方案的设计了。全埋点不需要设计，这里的埋点管理主要是围绕自定义埋点展开。
图1：埋点指标定义上图是我目前管理我司平台埋点的字段，分别解释下：埋点位置：我司平台覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；功能模块：对应埋点所属的大功能板块，如【电子书】功能模块，会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因：对于我司业务，区分度比较高，功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异；埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：
图2：运营同事关注的字段而开发同事关注的是下面这些字段：
图3：开发同事关注的字段因此针对同一个埋点，至少要考虑的是以上这些字段。（更大平台的埋点字段会更多，欢迎交流）其中，比较难处理的是【触发时机】的准确定义和描述，举个例子，某页面的pv数据，触发时机定义成加载和加载成功，会是完全不同的数据；又比如，首页模块（也有叫楼层）浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；事件变量定义：用来定义事件的参数，也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理，我司实践是把二表合二为一）。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标约精简越好，便于理解和管理，但可能对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。举一例，电商产品，商品详情页的事件变量怎么设计，见下图：
图4：商品详情页事件变量这里你可能会有疑问，如果是传一个【商品id】，其实也就可以通过【商品信息表】，把【商品名称】、【品牌】、【一二级类目】给查出来了，为什么还需要传？这里就涉及到指标管理与数据使用便捷性的权衡：如果不传，在使用的时候免不了要跨表联查，是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式，来保证数据能比较高效使用，最大化数据的价值。其他说明：变量值类型，比较常见的有：int、float、boole、string、timestamp；埋点形式，对于自己研发的数据采集系统，一般前端埋点和服务端埋点可以了，如果外采第三方数据采集服务，可能还会有全埋点（详细见上篇文章）；埋点版本和日志，则是帮助你和开发快速回忆这个点的前世今生。如果这篇文章你只记住一句话，我希望是：好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。以上，综合下来，以电商商详页举例，一个埋点事件最后的字段如下：
图5：举例-商品详情页事件指标设计
图6：事件表和用户表的关联用户表的自定义维度设计与业务关联度最高，除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外，其他偏业务属性字段需要一个比较全局的视角，不仅要与数据运营方沟通，而是要与公司每一个有分析诉求的部门进行沟通，采集他们的数据分析诉求，来提炼抽象出比较通用的用户表。如上面提到的，如果只是从事件表里把上报的数据聚合成统计数字或者图标，是没有很大意义的，还要能够下钻进行分析。事件表中变量字段的设计是为了从事件反映的用户行为侧进行下钻，而用户表的属性字段则是基于从产生行为的用户本身进行下钻。举简单一例：当日商品详情页的总浏览数据是上升的，但是总GMV确没有明显提高，从事件侧分析，发现某类异业合作主推的单品商详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。从此得出的初步判断是：1）单本对渠道A的用户拉新效果明显；2）但是该类用户被吸引来了，却没有下单，很奇怪，需要确认投放落地页与站内商品信息是否一致，尤其是价格；3）该类用户对平台其他商品的兴趣不高。说回用户表的属性字段设计，回到那句核心：采集共性诉求，提炼出通用、容易理解的用户表。这个工作其实并不难，考验的是数据PM沟通、提炼真实诉求，并整合成具体的需求的能力。以我司做内容服务的平台举例，用户属性表如下，基本覆盖了通用的用户群的分析：
图7：用户表维度举例
图8：默认采集字段（部分）
图9：分享埋点事件对于通用埋点，有更新时（上新功能，或者下旧功能），就将对应type字段的埋点和值进行更新即可。（另：写上指标变更记录）
图10：数据指标地图另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和大数据组一起来明确具体内容了，这个工作并不复杂，就是需要开个小会进行确认，并且约定好，新增表格时，及时更新对表格的解释。
1）功能产品经理（后称功能PM）梳理相应的埋点清单（按照符合总表设计逻辑的字段进行梳理）；
2）功能PM与数据产品经理（后称数据PM）做内部评审，评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单；
3）功能PM与开发进行埋点需求评审，数据PM可旁听。
举一例：功能产品对签到功能进行优化，涉及到新增一些页面的分享功能，其最初提交的埋点需求如下图，标红的是分享相关的埋点需求：（数据PM需要要求功能PM按照统一的字段进行埋点的设计，初期的事件定义或者变量定义或许不规范，没关系，这个能力可以随着做几个版本逐步提高，但是字段规范一定要先定义好） fill=%23FFFFFF%3E%3Crect x=249 y=126 width=1 height=1%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
图11：功能产品提交的相关埋点清单在评审这期埋点前，数据PM查看在总表里，有分享相关的埋点：图12：查阅总表，分享事件之前已经有签到功能的埋点根据我们前面提到的原则，类似【分享】这类通用的功能组件，不要重复造轮子，而是要统一到一个事件上，通过类型来处理，因此，针对例子中的功能点，也将其提出的分享埋点，合并到总表中，如下图：图13：通过新增类型解决埋点需求然后，功能PM将仅该版本所涉及到的埋点拎出来，单独整理一份埋点文档，这份文档是单独给开发来看的，这样做的好处是：让开发同事只关注这个功能点相关的埋点就可以（我习惯通过颜色标记来进行区分）：图14：给开发看的埋点文档如果是第一次这样做，需要跟开发说清楚：这份文档里标颜色的，是这个功能迭代中需要新增/修改的点，没有在文档里看到的type类型的埋点，不是删掉，而是不要动（曾经有位憨厚的小哥，因为没沟通清楚，认为不在表格文档里的，都是要删了的，删了一半了，才找我沟通......）。关于版本迭代中的埋点管理，相比于excel一定要更好的工具化的管理办法，之前跟一个同行聊过，他们采用的方案是，做一个web端平台，可以看到所有的埋点。同时，功能PM可以在该平台上按照字段要求提交自己的埋点需求，然后走审批流程，能够进入开发的埋点，会打上版本标记，待上线后，对应的埋点会出现在平台总表里，供使用者查看。这个方案就很不错，本来计划推这套平台，后来我因个人原因离开了这家公司，就没有再继续。上面这个方案适用于有一定体量的公司，个人认为在C轮之前的公司，大多都是没有精力去做这样一套数据指标管理平台的。
3
埋点应用埋点有了，能采集到之前获取不到的数据了，下一步该如何使用，下面是从我的经验总结的，数据从浅层应用，向深层应用传递的应用场景。图15：数据大屏
图16：superset截图
1）约定进入ODS层的原始数据的维度、周期；
2）定义EDW层主题宽表的字段、周期；
3）设计DM层应用表的字段、周期（需要结合具体业务，设计尽可能通用的主题表、应用表）；
4）设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。
以上，是数据产品经理关于数据基础能力建设（数据埋点、数据工具、数据仓库）过程中的部分工作内容，基于此，做用户标签、精准推荐、AB测试工具，有的公司定义为增长产品经理的工作范畴，在我看来，属于应用侧的数据产品经理工作范畴了。这里也不纠结啦，产品经理是块砖，哪里需要往哪搬嘛~
13122402111
13122402111