[!info] related notes

• 所属 MOC: 前端工程化 MOC
• 相关概念: 埋点, 埋点事件模型, 页面浏览埋点, 曝光埋点, 前端埋点 SDK, 埋点数据质量与治理, 性能监控体系
• 易混淆概念: 性能监控体系, AI 前端监控指标

前端埋点工程化

范围

这条主线不只讨论“哪里加 track()”，而是讨论前端如何把用户行为、页面状态和运行时环境沉淀成可信数据资产。

为什么要放在一起理解

如果只把埋点理解成代码里的几个调用，很容易忽略这些真正决定成败的问题：

• 事件语义是否稳定
• 页面浏览和曝光口径是否明确
• 上报链路是否可靠
• 登录前后身份是否能关联
• 数据是否可去重、可采样、可治理
• 后续分析是否真的能落到业务决策

关系与依赖

• 埋点 负责解释“它是什么”
• 埋点事件模型 负责定义事件怎么建模
• 页面浏览埋点 和 曝光埋点 负责两类最常见也最容易出错的采集口径
• 前端埋点 SDK 负责采集、排队、上报和重试
• 埋点数据质量与治理 负责长期可维护性

一条完整链路

用户行为 / 页面状态 / 系统异常
        ↓
结构化事件
        ↓
前端 SDK 采集、补全、校验、排队
        ↓
上报网关 / 日志服务 / 消息队列
        ↓
清洗、去重、归因
        ↓
数仓 / OLAP / 看板 / 实验分析

几个关键判断

事件不是指标

• 事件是原始事实
• 指标是基于事件计算出来的结果
• 所以前端埋点系统首先要保证事件口径稳定

全埋点不能替代核心业务埋点

• 全埋点适合探索和补充
• 核心转化链路仍然需要语义明确的代码埋点或前后端联合埋点

前端要记录行为意图，后端要确认业务结果

• 例如前端记录 payment_start
• 后端确认 payment_success
• 二者最好通过 trace_id 或 request_id 串起来

SDK 的目标不是绝对不丢

• 浏览器环境天然不可靠
• 更现实的目标通常是允许少量丢失、允许重复、服务端可去重、整体可观测

和其他观测系统的关系

• 埋点更偏 Analytics，关心用户做了什么
• 性能监控体系 更偏 RUM，关心用户是否快、是否稳
• 错误监控更偏异常发现
• tracing 更偏链路定位

真正成熟的前端观测体系，通常是把这些能力协同起来，而不是混成一个模糊词。

Related notes

• 前端工程化MOC
• 埋点事件模型
• 前端埋点 SDK
• 曝光埋点