数据埋点方案——以内容产品为例

1 埋点与定义

数据采集，就是采集相应的数据，是数据流的起点，采集的准确性和全面性直接决定数据的质量，影响后续的所有环节。埋点是采集数据的重要来源。

1.1 什么是埋点

埋点是（用户行为）数据采集领域的术语，学名叫做事件追踪（Event Tracking），主要是针对特定用户行为或事件进行捕获、处理和发生的相关技术及其实施过程，如用户点击某个按钮的次数、阅读某篇文章的时长等等。

埋点是一种常用的数据采集方法，它是为了满足丰富的数据应用而做的用户行为过程及结果记录，是数据的主要来源，采集的数据常常用于分析产品的使用情况、用户行为偏好等，于是延伸出AB测试、用户画像、用户推荐系统等数据产品。

把埋点体系作为数据中台或 BI 体系的重要组成部分及其好处 埋点系统和数据仓库、分析体系、预警系统等子系统一样，需要放入整个公司的业务体系和数据体系里，方便统一规划。 首先，可以把行为数据作为数据体系的一部分进行整合。行为数据，换一个角度看也是一种业务数据，这种数据在业务系统里无法采集。建议把它作为一个数据源，方便把整个用户行为数据关联到业务或外部数据。 其次，可以把此时此刻的用户数据特征作为属性补充行为数据。整个数据体系中，有些数据在前端埋点时无法采集。比如在做某些优惠券逻辑时，只会传一个 ID 到前端页面上，实际再去埋点时，也只能拿到这些 ID 信息，其他无法采集。解决这个问题有很多办法，但通过前端业务侧解决的方式，通常风险比较大，因为要考虑接口设计、性能及各种并发问题，如果把这些数据问题放在业务侧，将会受到一定的阻力。而如果通过数据侧解决会相对容易，比如把 ID 采集回来后，它的优惠价格、历史信息及其所承载的数据含义等信息，在数据侧都可以直接关联。

1.2 埋点的类型

根据目前常见的数据埋点形式，可以将数据埋点分为全埋点（也可称无埋点）和代码埋点（自定义埋点），后者分为前端埋点与服务器埋点。

常见的数据埋点形式

根据埋点技术还可分为Web埋点/Javascript埋点、App埋点、接口埋点。

2 埋点设计

2.1 注意点

1. 埋点规划。在对埋点需求进行规划时，切忌一次性完成大量需求，最好对需求进行优先级排序处理，这样有助于管理产品文档，如果一次性处理几百个埋点，加上涉及到跨部门协同，撰写时难免会有纰漏，所以埋点规划的节奏非常重要。

2. 埋点尽可能全面和必要。当我们想到用某些数据进行机器学习的时候，才可以不用再去埋点，也不会损失历史数据的价值。全面的关键点是以事件驱动，需要上传的信息包括事件本身和触发事件的用户信息，以及触发元素本身所在实体（对于客观世界物体的抽象）的信息。 必要是指只有能够产生业务意义的事件及相关信息才需要上报。

3. 用户属性。设计埋点时要考虑用户属性设计。设计用户属性时，需要遵循一个最基本的原则，就是通过**事件分析系统、用户标签、用户画像系统计算出来的东西，就不要单独上报埋点。**比如想要获取用户近几日的消费单数，或是确认他是否为 VIP 用户，这些数据需求都可以通过事件计算出来。如果再单独埋点，不但会浪费开发资源，而且上报来的结果远不如整个系统内环计算来的灵活。 需要注意的是，有两种属性非常值得埋。一个是静态属性，比如说用户年龄、性别等，这些静态属性无法算出来，很有埋点的必要。另一个是通过算法和数据挖掘产生的挖掘标签，也值得单独埋点。

4. 了解预置属性。建议通读了解预置属性，一方面是防止事件所采集的属性，跟预置属性有所重叠。另一方面，通过预置属性，可以了解各端的数据特性，比如小程序的特性如何，它在封闭环境里可以返回哪些数据、不返回哪些数据？比如 H5 特性、客户端特性等等。

5. 确定节点口径。通常，一个事件会有很多下沉节点，比如某个按钮的点击事件，从用户在 APP 层的点击，到 APP 去请求应用接口，到服务器去确定接口，接到了请求后，到业务侧后台系统处理这个请求时是否成功，再到最后是否能把结果成功返回给客户端。 因此，整理需求做事件设计时，一定要明确它的节点口径，明确需要在什么样的层级采集。具体来看，一方面需要想清楚在哪个节点采集，另一方面也要看具体需求，在什么样的环境采集。通常来说，越靠近 APP 端，它所采集的事件越大，但可能对比业务端来说，它的准确性会相对较低。

2.2 事件的基本思维：4W1H

从业务角度出发，划分五个角度：

事件五要素

Who：对行为的发起者进行标识，一般使用账号及设备号进行标识。账号是常用的方式，通过身份证号、手机号、账号 ID 等信息区分用户；设备号多用于不需要登录的产品，通过设备的编码来区分用户。

When：记录行为的发生时间，一般使用服务器时间，即 Unix 时间戳记录行为发生时间；它是全球统一时间，不受地区的干扰。

Where：记录行为发生的地点，一般通过 GPS 进行定位，或者通过设备 IP 判断用户位置。

What：指用户行为的具体内容是什么，比如用户阅读一本书，那么购买的书名是什么？价格是多少？哪个出版社出版等信息。

How：行为是怎么发生的，一般包含在行为名称中，如提交某订单，也有若干行为是可以通过多种方式完成，如解锁 iPhone，可以输入密码解锁，也可以刷脸解锁，无论使用哪种方式都是一种可以记录的信息。

2.1.1 事件分类

根据所要埋的事件类型进行分类很有必要，一方面方便对需求进行优先级确认，另一方面设计埋点时，不同类型的事件需要对应各自的方法。

1. 核心事件。产品的核心流程及用户核心行为的分支事件，根据具体业务需求进行专门处理和参数设置。

2. 通用事件。对于通用的、泛化性的、活动等次要流程事件，可以进行抽象化处理。 比如，在日常工作中，经常遇到市场或活动运营同事提出某次活动的埋点需求，如果每次活动都单独处理成一个事件，随着时间的推移将会导致同类事件越积越多，不利于管理，因此对于这类相关的事件，需要进行抽象化的通用事件处理。

3. 边缘事件。所谓边缘事件，指的是零散的只查看点击或浏览行为的事件，比如 APP 端诸如设置、客服入口等功能按钮。 处理此类事件，有两种常见方法： 一种是做一个最基本的自定义事件容器，然后把相关按钮名称、所在页面及其他零散东西抽象化后放进去。 另一种是手动纠正一些全埋点进行上报。之所以要手动纠正，是因为前后端的技术架构不同，没有办法 100% 地适应全埋点，当全埋点数据出现未知或无法采集时，需要手动调 SDK，纠正所要采集的页面。

2.1.2 案例：具体行为埋点

针对APP首页、阅读器页面、支付会员订单行为，从五个角度分析，分为特有指标和公共指标两类，如下：

APP首页

阅读器页面

支付会员订单行为

2.2 新增埋点设计

2.1.1 埋点指标定义-事件表

在初期的数据建设阶段，先要做的是定义想要的数据，告诉前端开发和后台的同事需要的数据有哪些，定义这些数据的字段包括但不限于以下内容：

埋点指标定义

埋点位置：漫画业务覆盖了APP、Web和小程序平台，其中有部分核心功能、页面在三个平台都有涉及（如作品详情页），分开管理会造成指标冗余，因此对于多平台存在的核心指标，采用的是统一事件名定义，不同平台触发时，数据上报到同一个事件名上，通过平台类型（platform_type）进行拆分；

事件定义：比较难处理的是【触发步骤】的准确定义和描述，如阅读页面的进度数据，触发定义成加载和加载成功完全不同；又比如，首页模块浏览，模块长短不一，到何种深度会触发对应模块的浏览，需要定义时想清楚，与开发沟通实现细节，避免后期踩坑；

参数定义：用来定义事件的参数，也可以理解为事件维度。该字段决定了事件的颗粒度，直接影响到事件下钻的颗粒度，对于数据PM来说，平台不同位置的事件抽象后，尽可能提取出公用事件，然后通过事件变量进行区分，能减少：指标冗余、指标管理工作、培训成本，以及使用者的学习成本。当然这里也并不完全执着于抽象公用性，对于数据PM和开发来说，指标越精简越好，便于理解和管理，但对于运营同事来说，学习和使用成本高企，数据产生了但无法最大化应用侧价值，那就得不偿失，所以需要平衡。

以作品阅读器的事件参数为例：

作品阅读器的事件参数

一般来说可以通过【作品表】和【作品id】，就可以将【作品名称】、【类别】等信息查出来，但有时候根据具体需求也可以一起传，这里涉及到指标管理与数据使用便捷性的权衡：如果不传，在使用的时候免不了要跨表联查，是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式，来保证数据能比较高效使用，最大化数据的价值。

其他：变量值类型，比较常见的有：int、float、bool、string、timestamp；埋点形式，对于自己研发的数据采集系统，一般前端埋点和服务端埋点可以了，如果外采第三方数据采集服务，可能还会有全埋点；埋点版本和备注变更日志帮助使用人员和开发快速回忆这个点的修改历史。

以会员购买页为例，一个埋点事件最后的完整埋点设计如下：

一个埋点事件的完整埋点设计

2.1.2 埋点指标定义-用户表

用户表是记录用户信息、用户属性的表，通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联。事件与用户实现关联，事件表里一条条的数据记录，就不会再是孤立的统计数字，而是能够与具体的用户产生关联进行分析，或者用行为来圈定用户，给用户设定分群和标签。

事件表和用户表的关联

用户表的自定义维度设计与业务关联度最高，除了常规的用户id、用户昵称、注册时间、首次登录APP时间等字段外，其他偏业务属性字段需要一个比较全局的视角，不仅要与数据运营方沟通，而是要与公司每一个有分析诉求的部门进行沟通，采集他们的数据分析诉求，来提炼抽象出比较通用的用户表。

如果只是从事件表里把上报的数据聚合成统计数字或者图标，是没有很大意义的，还要能够下钻进行分析。事件表中参数的设计是为了从事件反映的用户行为侧进行下钻，而用户表的属性字段则是基于从产生行为的用户本身进行下钻。

举例：当日作品详情页的总浏览数据是上升的，但是总GMV却没有明显提高，从事件侧分析，发现某类异业合作主推的单作品详情页浏览数据上升，其他品类作品详情详页没有明确上升；从用户侧分析，该作品新增流量主要来自于渠道A。从此得出的初步判断是：1）单本对渠道A的用户拉新效果明显；2）但是该类用户被吸引来了，却没有下单，需要确认投放落地页与站内作品信息是否一致；3）该类用户对平台其他作品的兴趣不高。

用户表的属性字段设计核心：

采集共性诉求，提炼出通用、容易理解的用户表。这个工作其实并不难，考验的是数据PM沟通、提炼真实诉求，并整合成具体的需求的能力。

以漫画内容业务为例，用户属性表如下，基本覆盖了通用用户群的分析：

用户属性表举例

2.1.3 埋点指标定义-预置属性

除了前面提到的自定义事件和用户属性外，一般客户端或者第三方数据采集SDK还会采集一些预置默认的属性信息，这些可能不需要单独定义，但我们需要了解平台获取的预置字段有哪些。

神策APP SDK部分预置采集字段

神策APP SDK预置用户属性

2.3 通用埋点设计

在自定义埋点设计中，有一些通用的事件往往是比较复杂的，而且随着业务发展，会变得越来越复杂。比如，APP平台的分享事件，如果按功能模块，每个功能模块都设计了自己的分享事件，则这个事件会越来越分散，且想聚合做复合指标时，如通过分享/日活来衡量内容质量，分享事件要先聚合平台各功能模块的分享事件，太分散会产生应用上的问题。

建议仍然是将通用类型的埋点统一进行管理，通过变量字段进行拓展，来满足多功能模块的埋点需求。可以通过多个参数来进行区分。

对于通用埋点，有更新时（上新功能，或者下旧功能），就将对应type字段的埋点和值进行更新即可。（另：写上指标变更记录）

2.4 数据指标地图

数据能力推广的第一个难点，是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标，采用excel的方式进行管理的问题是指标一多起来，找起来不太方便，对于定义者来说自然很容易找到，但是对于使用者来说则不太友好。即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。

因此在数据指标表的第一个sheet，设计了一个数据指标地图，将不同功能模块的数据指标进行了拆解和说明，其他同事找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。

数据指标地图

另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和大数据组一起来明确具体内容了，需要开个小会进行确认，并且约定好在新增时及时更新对文档的解释。

3 埋点管理

本节中的管理模块可根据公司需求和资源分配，考虑进行产品化，能极大提升效率。

埋点管理模块

3.1 版本迭代功能埋点管理

随着版本迭代有新功能的埋点，或者针对之前功能的优化，所以需要对之前埋点进行调整。从埋点管理的角度，新增/修改的埋点，需要整合到之前的埋点系统里，这样能够方便使用者查阅整体的埋点明细。下面是基于使用Excel来管理APP版本迭代中埋点更新时的解决方案，并不是最优解，仅做参考。

版本迭代功能埋点需求管理流程

1. 功能在经过需求评审（=技术评审）后，基本确定了这一次要做的功能点，因此也可以梳理出要做的埋点有哪些。

2. 功能产品经理（后称功能PM）梳理相应的埋点清单（按照符合总表设计逻辑的字段进行梳理）；

3. 功能PM与数据产品经理（后称数据PM）做内部评审，评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单；

4. 功能PM与开发进行埋点需求评审，数据PM可旁听。

5. 数据PM整理该版本的需求文档，并更新到埋点管理文档或系统内。

举例：功能产品对签到功能进行优化，涉及到新增一些页面的分享功能。根据我们前面提到的原则，类似【分享】这类通用的功能组件，不要重复造轮子，而是要统一到一个事件上，通过类型来处理，因此，针对例子中的功能点，也将其提出的分享埋点，合并到总表中。 然后功能PM将仅该版本所涉及到的埋点拎出来，单独整理一份埋点文档，这份文档是单独给开发来看的，这样做的好处是：让开发同事只关注这个功能点相关的埋点就可以，可通过颜色标记来进行区分。

关于版本迭代中的埋点管理，相比于excel也有更好的工具化管理办法，如做一个web端埋点管理平台，可以看到所有的埋点，同时，功能PM可以在该平台上按照字段要求提交自己的埋点需求，然后走审批流程，能够进入开发的埋点，会打上版本标记，待上线后，对应的埋点会出现在平台总表里，供使用者查看。

3.2 埋点可视化管理

主要负责对埋点进行可视化管理，直观并易于理解。

可视化埋点

3.3 埋点状态监控

主要负责对埋点的存活状态、未知埋点发现及数据异常进行提醒。

1. 埋点的存活 主要是针对已经确定的埋点进行监控，而是否存活主要是通过测试人员进行回归测试来判断。

2. 未知埋点发现 主要是通过上报数据进行分析，如果出现了未知的埋点标识数据，则进行提醒，方便反向跟踪问题。

3. 数据异常提醒 主要从数据本身的阈值异常以及上下游埋点比例的阈值进行监控。

3.4 埋点测试

主要提供给测试人员使用，若与可视化管理模块联动可以让产品经理也很容易上手，进行埋点测试。

4 问题排查技巧

问题排查日常应用中常遇到三种问题：

1. 数据一致性问题 当埋点系统收集的数据和业务端、BI 等系统数据节点或口径不一致时，该如何处理？比如，关于新用户与老用户的定义差异，当埋点所定义的概念和市场及运营端同事的口径不同时，就会造成数据对不上的问题。 建议先跟运营或是对应的产品同事了解相关指标，它的口径和节点是怎样的，及时去修改属性和描述，比如不要笼统地定义为老用户或新用户，而是定义为注册用户、认证用户或下单用户等。

2. 准确性问题 把埋点系统的数据与业务端、BI 端数据进行校对，基本上三个数据大体一致。当然也不排除三端同时出现数据错误，这需要根据实际情况进行纠正。

3. 关于未知和空数据 出现这种情况的原因有很多，但有一种情况我们可以提前避免，就是在事先设计和定义属性时，一定要考虑到这个属性的空状态下该如何上报？是 0 还是空具体如何处理需要提前考虑清楚。

5 参考

1. 如何从0到1构建指标体系 | 人人都是产品经理

2. 数据产品经理：埋点的设计、管理与应用

3. 如何从 0 到 1 构建埋点体系

4. 《数据产品经理：实战进阶》