前端埋点工程化
从事件建模、SDK、上报链路到数据质量、治理与合规，系统整理前端埋点的工程化主线。
#synthesis
#growing
#frontend
[!info] related notes
前端埋点工程化
范围
这条主线不只讨论“哪里加 track()”，而是讨论前端如何把用户行为、页面状态和运行时环境沉淀成可信数据资产。
为什么要放在一起理解
如果只把埋点理解成代码里的几个调用，很容易忽略这些真正决定成败的问题：
- 事件语义是否稳定
- 页面浏览和曝光口径是否明确
- 上报链路是否可靠
- 登录前后身份是否能关联
- 数据是否可去重、可采样、可治理
- 后续分析是否真的能落到业务决策
关系与依赖
- 埋点 负责解释“它是什么”
- 埋点事件模型 负责定义事件怎么建模
- 页面浏览埋点 和 曝光埋点 负责两类最常见也最容易出错的采集口径
- 前端埋点 SDK 负责采集、排队、上报和重试
- 埋点数据质量与治理 负责长期可维护性
一条完整链路
用户行为 / 页面状态 / 系统异常
↓
结构化事件
↓
前端 SDK 采集、补全、校验、排队
↓
上报网关 / 日志服务 / 消息队列
↓
清洗、去重、归因
↓
数仓 / OLAP / 看板 / 实验分析几个关键判断
事件不是指标
- 事件是原始事实
- 指标是基于事件计算出来的结果
- 所以前端埋点系统首先要保证事件口径稳定
全埋点不能替代核心业务埋点
- 全埋点适合探索和补充
- 核心转化链路仍然需要语义明确的代码埋点或前后端联合埋点
前端要记录行为意图，后端要确认业务结果
- 例如前端记录
payment_start - 后端确认
payment_success - 二者最好通过
trace_id或request_id串起来
SDK 的目标不是绝对不丢
- 浏览器环境天然不可靠
- 更现实的目标通常是允许少量丢失、允许重复、服务端可去重、整体可观测
和其他观测系统的关系
- 埋点更偏 Analytics，关心用户做了什么
- 性能监控体系 更偏 RUM，关心用户是否快、是否稳
- 错误监控更偏异常发现
- tracing 更偏链路定位
真正成熟的前端观测体系，通常是把这些能力协同起来，而不是混成一个模糊词。
Digital Biome