一、埋点的管理
1.1 新增埋点设计
1.1.1 埋点指标定义-事件表
一款互联网产品每天生成的数据量庞大且结构复杂，若全部存储会占据大量硬盘空间。此外，未经定义和标记的数据难以有效利用。因此，在数据建设的早期阶段，关键步骤之一是确定所需数据并与前端开发人员和后端团队沟通。此定义包括但不限于以下字段：
埋点位置：平台覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（类似于电商平台的商品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；
功能模块：对应埋点所属的大功能板块，如【电子书】功能模块，会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因：对于我司业务，区分度比较高，功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异；
埋点事件：这个文档我是同时要给开发和运营的同事看的（分开维护的成本太高），对于运营同事来说，他们要关注的字段是下面这些：
而开发同事关注的是下面这些字段：
因此，在考虑同一个埋点时，至少需要考虑到上述字段，而在更大平台上的埋点字段可能会更多。
在定义和描述【触发时机】时，可能会遇到一些较难处理的情况。举例来说，对于某个页面的PV数据，如果将触发时机定义为加载和加载成功，则获得的数据会有很大差异。另外，对于首页模块（也被称为楼层）的浏览，不同模块的长度会不一样，需要准确定义何时触发对应模块的浏览。在确定这些定义时，需要充分思考，并与开发人员进行明确沟通，以避免后期出现问题。
事件变量定义：用来定义事件的参数，也可以理解为事件维度（也有一些实践是把事件表和维度表分别进行管理，我司实践是把二表合二为一）。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。
尽管数据的一般性规则对于数据产品经理和开发人员来说越简洁越好，以便于理解和管理，但这并不意味着完全忽视操作人员的需求。对于运营同事来说，学习和使用数据可能需要付出高昂成本，而且即使数据已经产生，也可能无法最大化其价值。因此，我们需要在数据的一般性原则和操作人员的需求之间进行平衡。
举一例，电商产品，商品详情页的事件变量怎么设计，见下图：
在这种情况下，您可能会有疑问，为何需要传递"商品id"，通过查询"商品信息表"即可获得"商品名称"、"品牌"和"一二级类目"的信息。
在这个问题中涉及到了指标管理和数据使用便捷性之间的权衡。如果不传递数据，就不可避免地需要进行跨表联查，这会影响使用效率。为了保证数据能够高效使用并最大化数据的价值，在指标管理中常常需要通过以时间换取空间的方式进行处理。
其他说明：变量值类型，比较常见的有：int、float、boole、string、timestamp；埋点形式，对于自己研发的数据采集系统，一般前端埋点和服务端埋点可以了，如果外采第三方数据采集服务，可能还会有全埋点（详细见上篇文章）；埋点版本和日志，则是帮助你和开发快速回忆这个点的前世今生。
牢记：好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。
以上，综合下来，以电商商详页举例，一个埋点事件最后的字段如下：
1.1.2 埋点指标定义-用户表
用户表是一张用来记录用户信息和属性的表，通过用户的唯一标识（user_id），可以实现用户表和事件表之间的关联。通过此关联，事件表中的数据记录就不再是孤立的统计数字，而是与具体的用户相关联，可以进行分析和行为定位，以便为用户设定分群和标签。
作为IT工程师，用户表的自定义维度设计需要与业务关联度最高。除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外，其他偏业务属性字段需要采用一个更全局的视角考虑。这不仅涉及与数据运营方的沟通，还需要与公司每个有分析需求的部门沟通，收集他们的数据分析需求，以抽象出更通用的用户表设计。
在前文已提及，仅将上报数据从事件表中聚合为统计数字或图表是意义不大的，还需具备下钻分析的能力。事件表的变量字段的设计旨在从事件反映的用户行为侧进行下钻分析，而用户表的属性字段则基于产生该行为的用户本身进行下钻分析。
举简单一例：当日商品详情页的总浏览数据是上升的，但是总GMV确没有明显提高，从事件侧分析，发现某类异业合作主推的单品商详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。
经初步分析，可以得出以下结论： 1）针对渠道A的用户拉新效果显著，但存在一个问题：尽管这些用户被吸引来了，但却没有下单。这一现象非常奇怪，需要核实投放的落地页和站内商品信息是否一致，特别是价格信息是否一致。 2）另外，需要注意的是，这类用户对平台其他商品的兴趣较低。
就用户表属性字段设计而言，我们应该专注于采集用户的共性需求，并提炼出简洁易懂的通用用户表。这项工作实际上并不困难，而是考验数据产品经理在沟通交流中提取真实需求，并将其整合为具体需求的能力。以我所任职公司从事内容服务平台为例，以下是基本覆盖通用用户群分析的用户属性表。
1.1.3 埋点指标定义-默认属性
除了前文提到的自定义事件和用户属性，通常客户端或第三方数据采集SDK还会采集一些默认的属性信息。这些默认属性通常不需要单独定义，但数据产品经理需要明确平台获取的默认字段有哪些。
1.2 通用埋点设计
在自定义埋点设计中，有一些通用事件往往具有复杂性，并且随着业务的发展而变得越来越复杂。举例来说，对于APP平台的分享事件而言，如果每个功能模块都设计了自己的分享事件，那么这个事件会变得越来越分散。而当我们希望通过分享次数与日活跃用户数来衡量内容质量时，我们需要首先将平台各功能模块的分享事件进行聚合。如果事件过于分散，这可能会导致应用上的问题。
因此，我强烈建议将通用类型的埋点集中管理，并通过变量字段进行扩展，以满足各种多功能模块的埋点需求。以分享事件为例，可以使用多个变量来区分不同情况。
在处理通用埋点时，当有新功能推出或旧功能下线时，需要更新相应type字段的埋点和对应值。此外，还需要记录指标的变更情况。
1.3 数据指标地图
面临数据能力推广的首要难题是确保在平台上哪些数据对所有人可见。一种方法是通过在各个平台上设定指标进行管理，我之前尝试过使用Excel表格来管理，然而，问题在于当指标数量增多时，查找变得不太便捷。对于定义者（即我自己）来说，很容易找到需要的指标，但对于其他使用者来说则不太友好。即便是通过中文名称来搜索，仍然存在使用不同关键词进行搜索的情况，例如：模块、版块、板块。
因此，在数据指标表的第一个工作表中，我们设计了一个数据指标地图，用于将不同功能模块的数据指标进行拆解和说明。在运营同事查找数据指标之前，他们可以首先打开指标地图，大致了解各个模块的指标所在位置，然后再去对应的工作表中查找具体指标的定义和可下钻的维度信息。
另一方面，我们还需要对数据仓库中各个表进行定义。当我们通过自助取数的方式从数据仓库中获取数据时，会遇到以下问题：我们有哪些表？这些表对应的是哪个业务领域的数据？这些表中包含哪些字段？这些字段的含义是什么？为了明确具体内容，我们需要与大数据团队一起开会进行确认，并约定好更新解释表格的规定，以便及时更新新添加的表格的解释。这是一项并不复杂的工作，但需要确保及时进行。
1.4 版本迭代功能埋点管理
由于版本迭代中引入了新功能的埋点或对先前功能进行了优化，因此需要调整先前的埋点。从埋点管理的角度来看，新增/修改的埋点需要整合到先前的埋点系统中，以便使用者方便查阅完整的埋点明细。
以下是我基于使用Excel来管理APP版本迭代中埋点更新的解决方案，我认识到这可能不是最佳解决方案，仅供参考。作为一名IT工程师，我相信有更专业的方法来解决此问题。
在这个背景下，我们的APP迭代周期为两周一个版本。我们有三位负责具体功能设计和产品跟进的功能产品经理。他们在设计产品功能时，会提交与功能相关的埋点需求。经过功能评审后，我们会和他们进行一次沟通，来确定埋点需求，并将其梳理出来。
处理流程：功能在经过需求评审（=技术评审）后，基本确定了这一次要做的功能点，因此也可以梳理出要做的埋点有哪些。所以从这个节点的处理流程是：
作为IT工程师，你需要进行数据追踪清单的整理，这个清单需要按照设计规范中的字段逻辑来进行梳理。你可以将自己的角色称为功能产品经理（功能PM）。
功能产品经理（Function PM）与数据产品经理（Data PM）进行内部评审，目的是为了对功能点进行整理，确保与总埋点文档保持兼容，并生成一个可供开发人员查阅的埋点清单。
3）功能PM与开发进行埋点需求评审，数据PM可旁听。
举一个例子，针对签到功能，功能产品进行了优化，其中涉及新增一些页面的分享功能。其最初提交的埋点需求如下图所示，其中红色标记的是与分享相关的埋点需求：
（数据PM需要要求功能PM按照统一的字段进行埋点的设计，初期的事件定义或者变量定义或许不规范，没关系，这个能力可以随着做几个版本逐步提高，但是字段规范一定要先定义好）
图11：功能产品提交的相关埋点清单
在评审这期埋点前，数据PM查看在总表里，有分享相关的埋点：
图12：查阅总表，分享事件之前已经有签到功能的埋点
根据我们之前所讨论的原则，我们应该避免重复发明类似【分享】这样的常见功能组件，而是应该将其整合到一个事件上，使用类型来处理。因此，对于这个示例中的功能点，我们将把与分享有关的埋点，合并到总表中，如下图所示：
图13：通过新增类型解决埋点需求
然后，功能项目经理将仅关联到该版本的数据追踪代码整理为一个独立的文档。该文档专门用于供开发人员查看。这一做法的好处是让开发团队只关注与该功能相关的数据追踪事项（我通常会使用颜色标记来进行区分）。
图14：给开发看的埋点文档
如果这是第一次执行此操作，请与开发人员明确：在本文档中，被标记为不同颜色的内容代表了该功能迭代中需要新增或修改的部分。对于那些在文档中未列出的type类型的数据埋点，不要删除，而是不要进行修改（之前有一位误解的同事认为未在表格文档中列出的内容都应该被删除，结果删除了一部分后才与我进行沟通……）。
关于版本迭代中的埋点管理方面，为了更好地管理埋点，有一种更专业的方法，即建立一个web端平台。通过该平台，可以全面查看所有的埋点，并且功能PM可以按照字段要求提交自己的埋点需求，并通过审批流程。只有通过开发的埋点会被标记为相应版本，一旦上线，对应的埋点会出现在平台总表中供使用者查看。这种方案非常好，我们原本计划推出这个平台，但由于个人原因，我离开了那家公司，所以这个计划没有继续进行下去。
上述解决方案适用于中型以上公司，通常在C轮融资之前的初创公司往往没有足够的资源来实施这样一个全面的数据指标管理平台。
1.5 埋点实践中可能会遇到的问题和解决方案
1.埋点设计过程中不注意事件和属性的命名规范，导致埋点无法使用或难以理解
在许多企业中都会出现这个问题，最初可能是随意起一个事件名或属性名，没有明确的规则限制。当埋点数量逐渐增加时，会出现混乱。例如，当同事离职时，接手项目的人无法理解前任同事如何设计埋点；另外，如果不同业务线的同事完成埋点设计而没有命名规范，开发和数据分析同事都会遇到困难。这些问题会导致先前努力开发的埋点无法使用，进而需要额外的工作来处理数据。
在制定埋点事件的命名规则时，应该考虑到企业的发展现状，包括拥有的产品线和业务线的数量。通常情况下，可以采用以下规则：使用"产品线_业务线_页面名称（按钮名称）_动作"的格式命名埋点事件，例如"app_ShengXian_BuyNowIcon_Click"表示在app的生鲜业务线中点击了"立即购买"按钮。当然，企业也可以根据部门和业务线的划分自定义命名规则。为了避免后续不必要的治理成本，我们应当在前期就规定好这些规则，并确保所有同事都遵守。这样做能够减少以后需要进行的修补工作。
2.埋点可解释性差，需要花费时间进行理解
如果第一个问题是关于埋点命名不规范，那么第二个问题就是使用埋点的人无法确定某个埋点被埋在了哪里以及其确切含义。为了使用某个埋点，他们需要不断向埋点开发的同事查询或者自行推测，这可能导致数据结果产生偏差，从而导致错误的业务决策。此外，理解埋点还需要额外的时间投入，这会降低工作效率。
解决此问题的方法是通过使用"埋点地图"的方式。在设计埋点时，将涉及到的页面或按钮截图并圈选，并将其放在埋点需求文档的第一列或最后一列。如果需要，可以在备注列进行补充说明。这样可以方便开发同事理解需求，避免错误埋点，并使使用埋点的业务同事快速了解埋点的位置，减少不必要的沟通成本。如果有能力的企业还可以开发自己的埋点管理平台，业务同事可以将要埋点的截图上传并简单说明，在平台上根据需求进行埋点，验收上线后便捷地使用。这样可以减少维护文档带来的不便，特别适用于业务线多、场景复杂的企业。
3.埋点冗余，浪费开发资源
尽管解决了问题（1）和（2），仍然不可避免地会出现埋点事件或属性的冗余。这是因为每位同事在埋点设计方面有不同的习惯。例如，对于页面浏览行为，有的同事可能使用属性page_name（页面名称），而其他同事可能使用属性page_title（页面标题）。然而，这两个属性都表示用户正在浏览的页面，很明显，这两个属性可以标准化统一。从这个例子可以看出，如果没有限制，事件或属性的冗余现象就会出现，从而导致开发资源和服务器资源的浪费。
为了最大程度地重复利用各种事件和属性名称，我们可以在埋点规则和埋点地图的基础上设计一个名为“埋点资源库”的系统。该系统包含了之前已经使用过的所有埋点事件名和属性名。如果我们在后续的设计过程中发现某些名称可以被重复利用，我们可以直接从资源库中获取而不需要重新设计。然而，对于那些使用文档进行埋点更新的公司来说，这种方法可能会比较麻烦，因为检索之前使用过的名称需要时间和精力。如果公司有能力、具备资金和资源，最好的方法是设计一个埋点管理平台，该平台可以直接通过系统管理埋点资源库，从而提供方便和高效的埋点管理。
二、埋点应用
一旦完成埋点部署，我们就能够获取到之前无法获取到的数据。接下来，根据我个人的经验总结，我将分享一些关于如何将数据从浅层应用传递到深层应用的应用场景。
2.1 可视化
基于业务日志和埋点采集数据，有何方法能够立即将数据转化为价值？我建议首先进行可视化处理。这一建议的原因在于，初期的数据采集、记录和清洗工作耗费大量时间和精力。对于领导来说，投入人力资源进行一项看不到产出的任务，久而久之可能会产生质疑。
对于数据本身而言，经过清洗后的数据最有效的应用领域是可视化。对于那些每天需要查看Excel数据的领导来说，可视化的结果能够提供清晰明确的产品展示，从而获得上级的认可。这对于推进数据项目的后续进展来说绝对具有积极的影响。
在可视化阶段，推荐使用成熟的产品框架，而不是自行开发，以节省精力。在这个阶段，主要目标是尽快展现由数据采集产生的价值，并获得相关部门的认可，以增强项目团队成员的信心。因此，应该采取简洁高效的方式，遵循拿来主义原则。
2.1.1 数据大屏
作为IT工程师，我愿以更专业的方式重新表述上述观点：数据大屏展示具有强大的视觉冲击力，对于关注整体指标的高层管理人员而言，大屏提供了快速了解全局数据的解决方案。此外，如果贵公司需要经常接待其他单位、外出汇报或参展，动态数据大屏将成为具有最高曝光度的产品。
2.1.2 开源数据展示工具
数据大屏可以满足一般的展示需求，但对于更定制化和操作性强的需求来说不足够。在这种情况下，可以考虑使用其他工具来实现需求。这些工具的核心功能是连接数据库并读取数据，然后根据特定的维度（如日期、周期、项目名称）对数据进行聚合，从而形成不同的看板。在这些看板中，用户可以下载源数据和使用简单的SQL查询。这样就能够满足更深入的数据展示和分析要求。
工具推荐：Superset、Grafana
2.2 数据应用平台
作为一个IT工程师，我理解数据的价值在于与具体业务场景相结合，并利用成熟的分析场景对其进行分析。尽管前文提及的数据展示工具在可视化方面有所不足，但它们无法提供业务分析所需的功能。实际上，要实现业务增长，我们需要利用事件分析、漏斗分析、留存分析、归因分析以及更详细的用户画像和精准营销等成熟分析场景，将数据赋予真正的业务价值。
对于这类数据应用工具，已经有一些成熟的厂商提供了标准化产品。如果公司没有达到自行研发数据平台的规模，建议考虑采购这些产品。我们推荐的平台有GrowingIO、神策和TalkingData。
2.3 数据仓库
数据采集、录入，最终会落入到数据仓库中，成为数据仓库中的“弹药”。从19年大火的“数据中台”，去掉面子，里子就是一个数据仓库。数据仓库汇聚各业务端的原始数据，和主题数据，其建设过程是一个随着业务发展不断更新的过程。只是做数据的ETL本身并不是数据仓库的价值，其核心是能够收录好业务侧需要使用的数据，或者在业务侧提出新的数据需求时，能够快速响应。
根据数据仓库设计的经典三层结构（ODS层、EDW层、DM层），数据产品经理在数据仓库建设中承担以下职责：
1）约定进入ODS层的原始数据的维度、周期；
2）定义EDW层主题宽表的字段、周期；
3）需要结合具体业务，设计DM层应用表的字段和周期。优先设计通用的主题表和应用表，以确保尽可能的通用性。
4）设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。
参考资料：
1.微信公众号（大数据学习与分享）-《数仓埋点体系 | 埋点设计、管理与应用》
