大家都该学学的埋点概念与使用

时事 2024-11-18 11:50 浙江


作者:UAENA
https://juejin.cn/post/7415911686929268788

首先回答一下什么是埋点：

埋点是一种用于跟踪用户在网站或应用中行为的数据采集技术，通过记录点击、浏览等操作，帮助团队进行用户行为分析、AB 实验、错误监听，指导优化方向和资源分配

为了让读者能够从头到尾彻底学会埋点，我会分别从 埋点的概念与使用、如何实现一个埋点 sdk 入手
这篇文章核心围绕埋点的概念与使用展开，涉及到几个维度：

🎶 埋点的基本概念
🧠 埋点研发流程优化
🚀 埋点数据的消费经验

我们直接进入主题，相信能给大家带来不少的收获

一、埋点的基本概念

在业务开发中，埋点是一定要做的，那作为一名合格的研发，我们先要了解埋点都有什么类型，可以有效解决什么问题，这一部分的内容比较基础，网上也有很多精彩的文章，有一定基础的同学可以直接跳过~

我们会从几个维度进行基本概念的介绍：

监控类型
上报方式
埋点的生命周期（从创建到数据消费）

1. 监控类型

基于我们要监控的内容，可以分为：数据监控、性能监控、异常监控等三个部分
我们先讲述一下几个类型的基本概念，后面会详细讲解如何实现的

1.1 数据监控

特点：

数据监控主要指对用户行为、业务数据等进行埋点监控，采集并上报关键信息。他的目的是：
=> 通过收集用户在系统中的行为数据，帮助产品经理、运营人员更好地分析用户行为，优化产品决策

举例：

用户操作数据：点击某个按钮、页面的浏览路径、搜索的关键词、用户停留时间等。
电商平台：监控用户的商品浏览记录、加入购物车、购买行为、支付情况等数据。
社交平台：记录用户点赞、评论、分享、发布动态等操作。

例如，在一个电商网站中，当用户点击了“购买”按钮，系统会埋点记录这次点击事件，包括用户 ID、商品 ID、点击时间等，都会被上报到服务器，用于分析转化率、购物路径优化等

优缺点：

优点：

数据量大，覆盖面广，有利于全面掌握用户的操作行为
为业务决策提供有力的数据支持，帮助进行 AB 实验、用户行为分析等

缺点：

数据量大时，可能增加数据处理和存储的成本
埋点较多时，可能影响页面性能
考虑数据的置信问题，埋点的开发维护成本会偏高

1.2 性能监控

特点：

性能监控关注的是系统性能的表现，重点监控页面的加载时间、渲染时间、资源请求时间。他的目的是：
=> 帮助开发者了解项目的性能数据，为性能优化做导向

举例：

监控页面从开始加载到完全展示各阶段的时间，如 FP、FCP、LCP、JS 初始化、主接口加载等

优缺点：

优点：

及时发现性能瓶颈，提升用户体验，降低用户流失率
可以通过历史数据跟踪性能优化效果，确保持续优化

缺点：

采集的部分性能指标（如两秒开率等）可能需要与服务端结合，增加开发复杂度

1.3 异常监控

特点：

异常监控主要用于捕获系统中的异常情况，包括 JavaScript 错误、接口请求失败、未处理的 Promise 错误、资源加载失败等，它的目的是：
=> 通过及时捕获并上报异常信息，帮助开发者迅速定位问题、解决问题

举例：

JavaScript 错误：捕获页面中运行时的 JavaScript 错误，如未定义变量。例如，当我访问某个页面时，某个 JavaScript 模块发生了错误，导致页面无法正常展示，异常监控会将错误信息、错误堆栈、用户操作等信息记录并上报
接口请求失败：监控 API 请求的状态码、超时情况等，如请求返回 500 错误或出现网络超时等问题
资源加载失败：监控页面中图片、视频、CSS、JS 文件的加载失败情况，帮助开发者检查资源引用路径或网络问题

优缺点：

优点：

实时捕获异常，帮助开发者迅速发现并修复问题，提高用户体验
能够自动化捕获大量错误信息，减少手动调试的压力

缺点：

捕获到的异常信息可能过多，数据筛选和处理的难度较高
需要额外的策略来区分重要异常和无关紧要的异常，以避免过多无效的报警

2. 上报方式

在了解了埋点的监控类型后，我们再看看埋点的上报都有哪些方式

2.1 手动上报

特点：

手动上报是指我们基于业务需求，在代码中显式地添加埋点逻辑
每当需要记录用户行为或系统事件时，手动调用上报函数，将数据发送至服务器，这种方式的可控性强，开发者可以精确地控制埋点位置和上报时机

举例：

在用户点击某个按钮时，开发者会在按钮的点击事件中调用埋点上报函数，如：

    button.addEventListener('click', () => {        sendEvent('click_button', { userId: '12345', time: Date.now() });    });

这种方式能够精确记录用户点击的时间、操作对象等详细信息。

页面展示：在页面加载完成时，埋点记录页面的展示情况

window.addEventListener('load', () => {    sendEvent('page_view', { page: 'homepage', time: Date.now() });});

组件 DOM 超出 50% 曝光：使用 IntersectionObserver API 监测页面上特定组件的可见性，当组件的可见部分超过 50% 时，自动上报组件的曝光情况

const observer = new IntersectionObserver((entries) => {    entries.forEach(entry => {        if (entry.isIntersecting && entry.intersectionRatio > 0.5) {            sendEvent('component_exposure', { component: 'banner', time: Date.now() });        }    });}, {    threshold: [0.5] // 超过50%可见时触发});
const component = document.querySelector('#banner');observer.observe(component);

IntersectionObserver - Web API | MDN (mozilla.org)

优缺点：

优点：

高度灵活，开发者可以精确控制上报时机、数据内容等
适合复杂业务场景或需要精确控制的埋点需求

缺点：

需要手动编写大量代码，增加了开发和维护成本
如果埋点较多，容易遗漏或出现冗余埋点，影响代码质量，甚至导致数据不置信

2.2 可视化上报

特点：

可视化上报是通过图形界面或后台工具来配置埋点，无需开发人员手动编写代码。在业务人员或测试人员通过可视化工具对页面上的元素（如按钮、链接等）进行选择和配置后，系统自动生成埋点逻辑并上报数据。这种方式降低了技术门槛，使非开发人员也能够参与埋点配置

大家可能好奇这种可视化的操作是如何实现的，这个会在后续的全流程实现模块中详细介绍~

举例：

使用一些埋点平台（如 GrowingIO、神策数据等），业务人员可以在后台系统的可视化界面上点击页面元素，配置该元素的埋点逻辑。系统会自动捕获该元素的操作，并将数据上报至服务器

优缺点：

优点：

减少了开发者的工作量，业务人员可以快速配置埋点
埋点配置灵活，可以根据需要随时调整，无需发布新的代码

缺点：

灵活性不如手动上报，复杂的业务逻辑可能无法通过可视化工具实现
依赖第三方工具，可能带来兼容性或平台限制的问题

2.3 自动上报（无埋点）

特点：

自动上报（无埋点）是指系统通过框架或插件自动捕获用户行为或系统事件，无需手动埋点

举例：

使用无埋点方案时，项目初始化阶段会注册相关的监听，这种方式依赖于 SDK 的能力，自动监听页面上的交互事件、网络请求、资源加载等，并将数据上报到后台进行分析

优缺点：

优点：

减少了开发和运维成本，开发人员无需为每个事件手动编写埋点逻辑

缺点：

灵活性较低，自动捕获的行为数据可能无法满足某些特定业务需求，且不容易精确控制上报的内容和时机

当然，一个优秀且完整的企业级埋点系统，是灵活支持各类监控类型的，不同的类型专门服务不同的场景，实现对目标项目的全方位监控

3. 埋点的生命周期

在了解了埋点类型和上报方式后，我们再来学习一下：一个需求中埋点的全流程

如果再精确到研发主要负责的范围，我们可以给出一个更精细化的图：

虽然该流程覆盖了埋点从需求确认到数据消费的各个步骤，但在需求确认、开发自测、数据监控等环节可能存在数据遗漏、埋点不准确、数据质量监控不足等问题：

需求确认与埋点设计环节容易遗漏场景：埋点需求的确认和埋点方案设计环节，产品经理对用户行为理解不全面，或者开发人员没有参与设计环节，可能会遗漏一些关键场景或不常见的边缘操作
开发和自测环节容易出现数据不一致：在埋点开发和自测阶段，开发人员可能会因为疏忽或理解偏差，导致埋点的事件数据与需求不符。例如，埋点位置不准确、上报参数不完整、或埋点上报的时间点不对
埋点对性能的影响未充分考虑：如果埋点过多或者不合理设置上报频率，可能会导致页面性能下降，例如页面加载变慢、用户操作卡顿等问题，影响用户体验

二、埋点研发流程优化

我们可以通过自动化工具、加强测试覆盖等方式为了提高埋点质量问题，同时确保埋点对性能的影响最小化，至于具体怎么做，下面会给出一些实践经验：

1. 类型代码约束

我们可以通过 Typescript 为埋点的上报提供类型约束，它能带来的收益很明确：
尽可能避免埋点过程中出现数据格式、字段不一致等问题（你要是不管 error，咱也没办法😀）

了解了收益后，我们再来学习一下类型代码的消费方式，以及一个合理的类型代码结构

我们先提供一套最基本的埋点上报函数的封装（sendEvent）：

type LogParams = Record<string, string | number | boolean | undefined | null>;
export const sendEvent = (event: string, params?: LogParams) => {  // 埋点上传};

然而这种类型提示非常的粗糙，对于上报时的检测效果很不理想，那如果要实现非常严格的代码检查，我们可以考虑用 ts 类型体操实现升级：

export const sendEvent = <T extends EventNames>(  event: T,  params?: TrackInterfaces[T]) => {  // 埋点上传};
export interface TrackInterfaces {  main_picture_click: MainPictureClick;  page_view: PageView;}
export type EventNames = "main_picture_click" | "page_view";
/** * 页面浏览 */export interface PageView {  /**   * 应用名称   */  appName: string;  /**   * 平台   */  device_platform: string;  /**   * 来源   */  enter_from: string;  /**   * 链接   */  page_url: string;  /**   * 页面名称   */  page_name: string;}

可以看到我们通过一个枚举类型，维护了项目所有包含的类型名称，通过 T extends EventNames 获取了函数中具体的事件名，再通过 TrackInterfaces 映射到了具体的一个类型，比如：

// 事件名 page_view => 映射类型 PageViewsendEvent('page_view',{    enter_form: 'douyin'    page_name: 'home'    // 参数……})

话都说到这里了，我们可以再深入一下，对于通参（公共参数，比如操作系统、手机型号等），如果每次都要传递，是不是有点麻烦，那如果我们要抽离出来，该怎么做呢？代码如下：

export interface TrackInterfaces {  main_picture_click: MainPictureClick;  page_view: PageView;}
export type EventNames = "main_picture_click" | "page_view";
// 公共属性type CommonParams = {  device_platform: string;  // ……};
type trackParams<T extends EventNames> = Partial<CommonParams> & Omit<TrackInterfaces[T], keyof CommonParams>;
export const sendEvent = <T extends EventNames>(  event: T,  params?: trackParams[T]) => {  // 埋点上传};

通过这种方式，我们把通参从具体的类型中剔除，可以放在一个独立的方法（比如叫 addCommonParams）中维护（一个变量，如 commonParams），在其他事件上报时插入即可

话说回来，维护一个类型代码结构也是相当困难啊，尤其是事件很多的时候，这种情况下，就必须要我们通过一些自动化工具来实现埋点数据转类型代码了

这个问题是我在团队中遇到的，基于这个问题，我开发了一套基于 VSCode 的埋点类型转换插件，核心借助 quick_type 实现，核心的实现逻辑如下：

从埋点管理平台获取事件数据结构 => 事件数据格式解析 => 投喂 quick_type 进行转换 => 进一步加工成合适的格式 => 插入项目代码

大家要是感兴趣也可以实现一下，后续我会考虑把这个插件重写一份并开源出来，也可以用 sdk 的方式提高适用面

2. 埋点测试用例

测试用例可以用很多种方式进行，比如单元测试、抓包测试等，其中单元测试可以通过如 Jest 或 Mocha 实现，存在一定 coding 成本，我们这边展开讲讲抓包测试的实现方式

最简单粗暴的，我们可以使用浏览器开发者工具、Charles 等工具，捕获网页上的网络请求，观察上报的参数是否符合埋点事件的要求
然而这样的方式比较笨，批量检查起来会比较麻烦，因此一般的埋点管理平台会提供一个界面，能够实时显示埋点上报的具体内容，类似于抓包工具，可以有效地提高测试阶段的效率与准确率

对于流程的优化，还有很多的思路，比如聚合上报埋点事件（单位时间内事件打包成一个请求进行上报），可以有效降低请求带来的性能影响，具体的实现就先不在这里详细讲述了

三、埋点数据的消费经验

高效消费埋点数据是数据驱动决策的重要环节，下面我将从多个角度来解释如何高效消费埋点数据，并进行有效的场景分析

等等，你说这都是产品或数据分析师的活？研发应该努力跳出自己的舒适圈，从各方面提高自己的业务能力、解决问题的能力，尤其在如今数据驱动业务的环境下，能做好这些的研发会更有核心竞争力

PV 和 UV

PV（Page View） ：页面访问量
UV（Unique Visitor） ：独立访客数

我们可以通过 PV 和 UV 评估不同页面的访问量。可以通过聚合查询每日/每周的 PV 和 UV 进行趋势分析：

SELECT page_name, COUNT(DISTINCT user_id) AS UV, COUNT(*) AS PVFROM page_view_eventsWHERE date BETWEEN '2024-09-01' AND '2024-09-08'GROUP BY page_name;

当然 SQL 这一步，埋点平台都会做好了，我们不用关心具体的实现，这里展示只是为了更好说明逻辑

事件行为分析

事件行为分析通过埋点捕捉用户的操作习惯和行为路径，是我们最常用的分析模式，常用的操作如下：

1. 分析 click_button 事件中按钮名称为某个具体值的 PV

SELECT     button_name,     COUNT(*) AS PVFROM eventsWHERE event_name = 'click_button'AND button_name = 'submit'  -- 按钮名称为 'submit'GROUP BY button_name;

WHERE event_name = 'click_button'：过滤出 click_button 事件，表示按钮点击行为
AND button_name = 'submit'：只筛选按钮名称为 submit 的点击事件
COUNT(*) AS PV：计算按钮被点击的总次数，即该按钮的 PV

结果：

假设返回的 PV 为 500，表示 submit 按钮被点击了 500 次

2. 分析 `purchase` 事件的用户停留时长的平均数和 90 分位数

90 分位数（90th percentile）表示的是在一组数据中，90% 的数值小于等于这个数值，而另外 10% 的数值大于这个数值

SELECT     AVG(duration) AS avg_duration,  -- 计算平均持续时间    PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY duration) AS p90_duration  -- 计算 90 分位数FROM purchase_eventsWHERE event_name = 'purchase';

AVG(duration)：计算所有 purchase 事件的 duration 字段的平均值
PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY duration)：计算 duration 的第 90 分位数
WHERE event_name = 'purchase'：只过滤出购买事件的数据

结果：

avg_duration：平均持续时间，例如返回 180 秒，表示用户平均花费 180 秒完成购买流程
p90_duration：90 分位数的持续时间，例如返回 300 秒，表示 90% 的用户花费少于 300 秒完成购买

路径转换分析

路径转换分析用于跟踪用户从进入系统到完成某个目标（如购买、注册、下单）的转化过程，可以查看用户经过的关键步骤，发现在哪一步可能有大量用户流失

转换分析应该按用户 ID 逐个跟踪，确保每个用户的行为链可以被完整记录下来

假设我们有一个电商平台，目标是分析从用户进入首页到完成购买的路径转化率

步骤 1: 定义事件表结构

假设数据库中存储了用户的事件数据，每个事件都有 user_id 和 event_name：

CREATE TABLE user_events (    user_id VARCHAR(50),   -- 用户 ID    event_name VARCHAR(50),  -- 事件名，如 "page_view"、"add_to_cart"    event_time TIMESTAMP   -- 事件发生时间);

步骤 2: 查询每个用户在各个步骤的转化情况

为了简单起见，假设路径有三个关键步骤：

page_view：进入产品详情页。
add_to_cart：将产品加入购物车。
purchase：完成购买。

下面的 SQL 查询可以计算每个用户是否完成了从 page_view 到 add_to_cart 再到 purchase 的全路径。

SELECT     user_id,    MAX(CASE WHEN event_name = 'page_view' THEN 1 ELSE 0 END) AS viewed_product,    MAX(CASE WHEN event_name = 'add_to_cart' THEN 1 ELSE 0 END) AS added_to_cart,    MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) AS purchasedFROM user_eventsWHERE event_name IN ('page_view', 'add_to_cart', 'purchase')GROUP BY user_id;

步骤 3: 计算路径中的转化率

上面的查询会生成一个结果表，显示每个用户是否完成了某个操作步骤。基于这些数据，可以进一步计算转化率。例如，下面的 SQL 可以计算从查看产品到加入购物车再到完成购买的转化率。

WITH conversion_data AS (    SELECT         user_id,        MAX(CASE WHEN event_name = 'page_view' THEN 1 ELSE 0 END) AS viewed_product,        MAX(CASE WHEN event_name = 'add_to_cart' THEN 1 ELSE 0 END) AS added_to_cart,        MAX(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) AS purchased    FROM user_events    WHERE event_name IN ('page_view', 'add_to_cart', 'purchase')    GROUP BY user_id)SELECT    COUNT(*) AS total_users,    SUM(CASE WHEN viewed_product = 1 THEN 1 ELSE 0 END) AS total_viewed_product,    SUM(CASE WHEN viewed_product = 1 AND added_to_cart = 1 THEN 1 ELSE 0 END) AS total_added_to_cart,    SUM(CASE WHEN viewed_product = 1 AND added_to_cart = 1 AND purchased = 1 THEN 1 ELSE 0 END) AS total_purchased,    (SUM(CASE WHEN viewed_product = 1 AND added_to_cart = 1 THEN 1 ELSE 0 END) * 100.0) / SUM(CASE WHEN viewed_product = 1 THEN 1 ELSE 0 END) AS cart_conversion_rate,    (SUM(CASE WHEN viewed_product = 1 AND added_to_cart = 1 AND purchased = 1 THEN 1 ELSE 0 END) * 100.0) / SUM(CASE WHEN viewed_product = 1 AND added_to_cart = 1 THEN 1 ELSE 0 END) AS purchase_conversion_rateFROM conversion_data;

输出结果：

total_users：所有参与路径的用户数
total_viewed_product：访问了产品详情页的用户数
total_added_to_cart：添加了购物车的用户数
total_purchased：完成购买的用户数
cart_conversion_rate：从查看产品到加入购物车的转化率
purchase_conversion_rate：从加入购物车到完成购买的转化率

最终的结果一般会以漏斗图的形式展现，如：

通过这些结果，我们可以直观地看到每个关键节点的用户流失情况，并根据这些转化率数据进一步优化流程或产品设计比如，add_to_cart 的转化率较高，但 purchase 的转化率较低，这可能意味着在支付环节出现了问题

异常值与极端行为分析

有时，我们需要分析极端的用户行为（如长时间不操作或过于频繁操作）。通过分析这些异常行为，研发可以定位到系统中的潜在问题或优化点

例如，某个用户反复多次点击某个按钮，这可能是系统卡顿或用户困惑导致的行为。

 SELECT user_id, COUNT(*) AS click_countFROM event_logWHERE event_name = 'click_button'GROUP BY user_idHAVING click_count > 10;

数据变更归因

在埋点数据分析过程中，数据变更归因也是非常重要的，归因分析的场景可以应用于多种情况，如性能优化效果、A/B 测试结果等

以下是几个常见的数据变更归因分析的应用场景：

1. 某次性能优化，1.5 秒开率增长远大于 2 秒开率增长

在一次性能优化后，发现产品的秒开率（即页面在 1.5 秒内完全加载的比例）有了显著提升，但相比之下，2 秒内的开率增长较为缓慢

其中，优化前 2s 开率 > 50%

用户的秒开率呈近似正态分布的形式，一次性能优化可以理解为分布左移，表现如下（图画的有点粗糙，请见谅）：

可见有时候数据分析是需要经过严谨的推论才能给出置信的答案的

这时候又要问了：这不应该是数据分析师（DA）做的事吗？汇报的时候 DA 不一定会帮你分析，很多时候都得依赖自己，还是那个标准：跳出自己的舒适圈~

2. A/B 实验增长、下跌分析归因

A/B 实验是常用的用增手段，用来验证某个新功能或设计的效果（在 C 端业务比较常见）
通过对比 A 组（原始版本）和 B 组（新版本）的转化率，可以分析出某些指标的增长或下跌原因

我们可以分析两个版本在关键指标上的表现差异，找出新版本带来的改进点或不足之处
例如：

B 组的页面停留时间增加，说明新版本可能增强了用户的兴趣
B 组的转化率下降，可能是用户在新版本的交互上出现了问题

推荐阅读点击标题可跳转

点击获取精选前端开发资源。「前端大全」日常分享 Web 前端相关的技术文章、实用案例、工具资源、精选课程、热点资讯。

大家都该学学的埋点概念与使用

一、埋点的基本概念

1. 监控类型

1.1 数据监控

特点：

举例：

优缺点：

1.2 性能监控

特点：

举例：

优缺点：

1.3 异常监控

特点：

举例：

优缺点：

2. 上报方式

2.1 手动上报

特点：

举例：

优缺点：

2.2 可视化上报

特点：

举例：

优缺点：

2.3 自动上报（无埋点）

特点：

举例：

优缺点：

3. 埋点的生命周期

二、埋点研发流程优化

1. 类型代码约束

2. 埋点测试用例

三、埋点数据的消费经验

PV 和 UV

事件行为分析

1. 分析 click_button 事件中按钮名称为某个具体值的 PV

结果：

2. 分析 purchase 事件的用户停留时长的平均数和 90 分位数

结果：

路径转换分析

步骤 1: 定义事件表结构

步骤 2: 查询每个用户在各个步骤的转化情况

步骤 3: 计算路径中的转化率

输出结果：

异常值与极端行为分析

数据变更归因

1. 某次性能优化，1.5 秒开率增长远大于 2 秒开率增长

2. A/B 实验增长、下跌分析归因

2. 分析 `purchase` 事件的用户停留时长的平均数和 90 分位数