埋点
什么是埋点
是一个数据采集技术,提前在应用,插入工具,并收集用户行为,为了能更好的,分析理解用户需求,做业务决策和研究,提升体验,转换率, ai应用化
埋点的分类
- 代码埋点,无痕埋点,圈选埋点,曝光埋点,服务端埋点
你知道哪几种埋点方案？它们各自的优缺点是什么？
| 分类 | 优势 | 劣势 |
|---|---|---|
| 代码埋点 | 准确,复杂交互场景够灵活 | 发版慢,长达几周,耦合,业务代码,容易错埋漏埋 |
| 无痕埋点 | 链路长,全面,高效 | 脏数据多,数据分析,难度大 |
| 圈选埋点 | 发版快,即可生效,操作简单,点击绑定即可,开发人员无需接入,产品自主 | 复杂交互场景,难以满足, 代码规模重构,易造成id 丢失,埋点失效 |
| 曝光埋点 |
团队采取的方案为?
无痕埋点做兜底,可视化埋点做主导,代码埋点做其余情况兜底,补充
最终业务目标是为了尽可能全面的收集,统一埋点数据,并且全面ai应用化铺垫, 所以以无痕打底,为了埋点迭代高效,统一,用可视化埋点主导, 但是业务本身固有弊端,代码埋点做其兜底,最终共建了埋点体系
埋点数据上报方式
| 方式 | 优势 | 劣势 |
|---|---|---|
| img | 兼容性好,跨域, | get 请求受限于请求参数限制,路径形式,无法获取响应状态 |
| xml/fech | 数据量大,响应可判断 | 可能阻塞 页面卸载事件 unload 啥意思 |
| sendBeacon | 不阻塞主线程,数据可靠 | 兼容性, 无法获取 响应, |
为什么页面即将关闭时，XHR/Fetch 上报会丢失数据？
当页面开始卸载（beforeunload / unload 事件触发）时，浏览器会立即中止所有尚未完成的异步网络请求以及js执行,所以会丢失
在 SPA（单页应用，如 Vue/React）中，你如何监控 PV？
利用的是路由切换,popstate 等
如何实现元素曝光埋点
如何设计一个点击事件埋点？
埋点 SDK 会带来哪些性能问题？你如何优化？
- js 阻塞,sdk 逻辑中,初始化操作,存放到requestIdelCallback 中
- 频繁上报: 队列,批量上报
- 数据冗余, 前端做好,降采样,降频, 只上报,正确标注,id 的元素.
如何做前端的错误监控埋点？
如果让你设计一个数据上报队列，你会如何设计？
队列数据结构 requestIdelcallback 定时清空队列 阈值上报 卸载强制上报,
如果让你从 0 设计一个前端埋点 SDK，你的设计思路是什么？
数据采集层 数据清洗 数据上报 插件化 打包和发布
高可用、高性能、可扩展、低侵入
事件监听支持
概述
wind-monitor-client 支持多种类型的事件监听，这些事件分为两个级别：页面级别和元素级别。所有支持的事件类型由远程配置控制，通过 /monitorWeb/fingerPrint 接口的 eventWhiteList 字段进行管理。
事件分类
页面级别事件
页面级别事件监听整个页面的状态变化和用户行为，包括：
事件类型 描述 触发时机
pageView 页面浏览 页面加载完成时触发
pageLeave 页面离开 用户即将离开页面时触发
browserClose 浏览器关闭 浏览器窗口关闭时触发
pageVisible 页面可见 页面从隐藏变为可见时触发，金融终端里仅监听页面tab之间的切换
pageHidden 页面隐藏 页面从可见变为隐藏时触发，金融终端里仅监听页面tab之间的切换
scroll 页面滚动 页面发生滚动时触发
contentMenu 右键菜单 用户触发右键菜单时触发
hashchange 哈希路由变化 HashRoute变化时触发
history 历史记录变化 HistoryRoute变化时触发
元素级别事件
元素级别事件仅监听带有 data-uc-id 属性的元素，包括：
事件类型 描述 触发时机
click 点击事件 用户点击元素时触发
dbclick 双击事件 用户双击元素时触发
inputChange 输入变化 输入框内容发生变化时触发，如Input用户输入时
stateChange 状态变化 元素状态发生变化时触发，如Select的选择框内容发生变化时
mouseover 鼠标悬停 鼠标悬停在元素上时触发
远程配置控制
配置接口
事件监听列表通过 /monitorWeb/fingerPrint 接口的 eventWhiteList 字段进行远程控制：
{
"fingerprint": "104090e69e184126b9c5001b0d0a970d",
"userId": 123456,
"disable": false,
"disabledFieldList": "",
"disabledTerminalList": "S26",
"considerList": "dom,route,pv,input,scroll,style,contentMenu",
"eventWhiteList": "pageView,pageLeave,browserClose,pageVisible,pageHidden,scroll,click,inputChange,stateChange,contentMenu",
"serverTime": "2025-07-25T06:24:48.6266036+00:00",
"logLevel": 1,
"maxCacheMessages": 12,
"monitorPerformance": true,
"monitorError": false,
"monitorBehavior": true
}
配置说明
eventWhiteList：逗号分隔的事件类型列表，只有在此列表中的事件才会被监听
实时控制：可以通过修改此配置来动态启用或禁用特定事件类型，配置变更后，新的监听规则会实时生效
数据收集
元素标记：确保需要监听事件的元素都添加了 data-uc-id 属性
数据存放：利用 v 字段存放元素级的相关数据
数据收集规则参考：Web 控件支持度
注意事项
元素级别事件限制：只有带有 data-uc-id 属性的元素才会触发元素级别事件
配置优先级：远程配置的 eventWhiteList 优先级高于本地配置
兼容性考虑：不同浏览器对某些事件的支持可能存在差异
1. 行为监控sdk 具体支持了哪些事件，页面级别，元素级别，这些作为全局远程配置，是如何做的，只有针对于 元素级别事件限制，并非真正的全埋点
48 /55
具体行为数据上报格式，依据什么样的原则设定
数据格式规范
基本原则
• 使用JSON格式进行数据传输
• 采用压缩字段名减少数据体积
• 时间戳统一使用毫秒级时间戳
• 字符串字段使用UTF-8编码
• 数值字段使用合适的数据类型
来自 <http://10.106.42.38/consider/docs/preview/docs/tracking/auto-tracking/data/user-log-standard>
Sdk 具体是怎么接入的
import { init, WindMonitorProvider } from "@wind/wind-monitor-client";
const monitorClient = window.monitorClient = init({
appName: "{web项目名称,与软件仓库保持一致}",
monitorBehavior: true,
circleMark: true,
});
ReactDOM.render(
<WindMonitorProvider client={monitorClient}>
<AppIntlProvider>
<App />
</AppIntlProvider>
</WindMonitorProvider>,
document.getElementById('root')
);
你的插件标记，具体哪些，哪类元素会被自动标记，哪些会过滤掉
1. Wind UI 相关控件：来自 @wind/icons、@wind/wind-ui、@wind/wind-ui-form、@wind/wind-ui-table 等包的组件，查看wind-ui组件支持度。
2. 原生 HTML 标签：满足以下条件之一的标签会被标记，查看原生标签支持度。
• 类名中包含 consider
• 绑定了以下任一事件: onClick、onDoubleClick、onContextMenu
3. 第三方控件：通过 markHoc 机制处理的第三方控件和特定业务场景。
来自 <http://10.106.42.38/consider/docs/preview/docs/start>
那埋点整体的选择和流程是什么样的
埋点采集方式概述
体贴2.0的数据上报总体来说有两种方式：自动上报和手动上报。在此基础上，还提供了数据自定义、可视化埋点和代码埋点等扩展功能来满足不同的业务需求。
自动上报
自动上报是体贴2.0的核心功能，SDK会根据不同组件自动监听不同的事件并上报相应的内容。
特点：
• 无需配置 ：安装SDK后自动生效，无需额外配置
• 标准化数据 ：根据组件类型自动上报标准化的数据格式
• 元素信息采集 ：只能上报当前元素相关的信息
• 无功能点绑定 ：自动上报时不会上报功能点代码
适用场景：
• 页面访问、离开事件
• 按钮、链接等标准控件的点击事件
• 表单输入、滚动等基础交互行为
• 需要快速获得用户行为数据的场景
自动上报的局限性
自动上报虽然便捷，但也存在两个主要缺点：
1. 数据单一：只能上报当前元素相关的信息，无法满足复杂的业务需求
2. 缺少功能点绑定：无法与万得的功能点进行关联
解决方案
针对自动上报的局限性，体贴2.0提供了两种解决方案：数据自定义和可视化埋点
数据自定义
数据自定义通过函数回调的方式，允许开发者在自动上报的基础上自定义额外的数据内容，存储到 b 字段中。
特点：
• 基于自动上报：在自动上报的基础上扩展数据
• 上下文信息：可以上报事件发生时的上下文状态值
• 业务数据关联：支持关联业务相关的状态信息
适用场景：
• 某个事件需要上报上下文的某些状态值
• 自动上报的内容无法满足实际业务需求
• 需要在标准数据基础上增加业务特定信息
可视化埋点（开发中）
可视化埋点是在体贴系统中，通过页面可视化的方式，由产品经理绑定对应的功能点。
特点：
• 无需代码：通过可视化界面配置，无需开发人员参与
• 功能点绑定：支持将用户行为与万得功能点进行精确绑定
• 产品驱动：由产品经理主导，更贴近业务需求
• 标准化管理：提供统一的埋点配置和管理界面
适用场景： -需要与体贴1.0功能点对齐的场景 -产品经理需要直接参与埋点配置的场景 -标准化的用户行为追踪需求
手动上报
手动上报是通过代码主动调用SDK接口来上报数据的方式，适用于自动上报无法满足需求的场景。
核心特点：
• 高度灵活：可以在任何代码执行点手动上报数据
• 精确控制：能够精确控制埋点触发时机和上报内容
• 自定义数据：支持上报任意自定义的业务数据
• 功能点绑定：可以主动绑定功能点代码
• 兜底方案：当其他埋点方式都无法满足需求时的最终解决方案
主要适用场景：
1. 复杂业务逻辑：需要上报涉及多个步骤或条件判断的业务流程
2. 多数据关联：需要关联多个控件或业务数据的场景
3. 条件触发：需要在特定业务条件下才触发埋点的场景
4. 非UI事件：自动上报无法监听的事件，如API响应、状态变化等
5. 第三方集成：需要与第三方系统集成的特殊场景
6. 兜底需求：其他埋点方式都无法满足的特殊需求
如何选择埋点方式
在实际项目中，建议按照以下优先级选择埋点方式：
1. 优先使用自动上报
默认数据已满足需求，优先使用自动上报：
• 无需任何额外的配置和动作
• 系统自动采集基础用户行为数据
• 适用于快速获得用户行为洞察的场景
2. 需要补充数据时使用数据自定义
当自动上报的内容无法满足业务需求时：
• 使用函数回调自定义上报数据
• 在 b 字段中存储额外的业务信息
• 获取事件发生时的上下文状态值
• 关联业务相关的状态信息
3. 需要功能点绑定时使用可视化埋点（开发中）
当需要与万得功能点进行绑定时：
• 由产品经理在系统中配置功能点绑定
• 通过可视化界面选择页面元素内容定义为属性
4. 特殊场景使用手动上报
当以上方式都无法满足需求时：
• 使用代码手动上报
• 实现完全自定义的埋点逻辑
• 适用于复杂业务逻辑和多数据关联场景
• 作为兜底方案，处理特殊需求
