埋点 on Saiga

前端视角下的 A/B Test：埋点、分流与验证

wuwenzen@outlook.com (wuwj) — Thu, 20 Apr 2023 00:00:00 +0000

「做个 A/B 实验看看」这句话听起来很轻松，真正落地时会发现：

指标怎么算？
实验人群怎么分？
前端要怎么接入实验配置？
实验结束之后，代码怎么收口？

这篇文章从前端的角度，讲一次相对完整的 A/B 实验闭环。

1. 先确定：为什么要做这个实验？

我们当时的实验目标是：提高某投资流程的转化率。

假设是：

把原本一个超长的单页表单拆成多步引导，是否能提高「填写完成率」。

因此：

实验对象：访问该流程的真实用户；
对照组：看到旧版「单页表单」；
实验组：看到新版「多步引导」；
观测指标：完成率、平均耗时、中途流失位置等。

只有先把这些定义清楚，后续埋点和分流才有方向。

2. 埋点设计：先有指标，再谈实现

这次我们重点关心几个指标：

flow_enter：进入流程的人数；
flow_complete：完成流程的人数；
step_view：在多步表单中，每一步的曝光；
step_error：每一步表单提交失败次数。

在前端埋点上做了几件事：

所有埋点带上 experiment_id 和 variant（A / B）；
关键事件使用统一的 event_name + event_params 格式；
尽量避免把业务逻辑硬编码到埋点名里。

示例：

track('flow_enter', {
  experimentId: 'exp_split_form_v1',
  variant: currentVariant, // 'A' 或 'B'
});

track('step_view', {
  experimentId: 'exp_split_form_v1',
  variant: currentVariant,
  step: 1,
});

track('flow_complete', {
  experimentId: 'exp_split_form_v1',
  variant: currentVariant,
});

3. 分流：让实验「公平」且可控

3.1 基本原则

同一用户体验稳定
- 被分到 A 组，就一直看 A；
- 避免一次访问是 A，刷新变 B。
分配近似均匀

前端监控闭环：采集、告警到问题跟踪

wuwenzen@outlook.com (wuwj) — Mon, 05 Sep 2022 00:00:00 +0000

很多团队做前端监控的姿势是：

先接一个 SDK，看到了几个报错，然后就没然后了。

最后变成：

告警群天天响，大家学会了「静音」；
仪表盘很酷，但没人看；
真出大问题时，还是靠用户截图。

这篇文章想聊的是：怎么从「有监控」升级到「有闭环」：采集、告警、问题跟踪、复盘一条链路打通。

1. 前端到底要监什么？

可以按三个维度来想：

可用性
- JS 运行错误（Error、Promise 未捕获）；
- 资源加载失败（JS/CSS/图片）；
- 页面白屏/异常重定向。
性能
- 首屏指标（FCP/FP/TTI 等的近似值）；
- 接口耗时、失败率；
- 静态资源加载时间。
行为 & 转化
- 关键路径的曝光/点击/完成；
- 异常行为（频繁刷新、某步流失明显）。

实践上，可以先从：错误 + 性能 + 关键链路打点 三件事做起。

2. 采集：埋点 & SDK 一起用

2.1 错误采集

典型方式：

window.addEventListener('error', (event) => {
  reportError({
    type: 'error',
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
    stack: event.error?.stack,
  });
});

window.addEventListener('unhandledrejection', (event) => {
  reportError({
    type: 'unhandledrejection',
    reason: String(event.reason),
  });
});

结合 sourcemap 上传，可以把错误还原到源代码行。

2.2 性能采集

利用 Performance API：

别再只 console.log 了：前端错误收集与日志治理

wuwenzen@outlook.com (wuwj) — Fri, 03 Jul 2020 00:00:00 +0000

大部分前端开发一开始排查问题都是靠：

console.log('看看这里是什么');

这没问题，但当项目变大、用户变多、场景变复杂时，只靠 console.log 就完全不够用了——用户出问题时你根本看不到现场。

这篇文章聊聊我在实际项目里做前端错误收集和日志治理的一些经验。

1. 我们到底需要记录什么？

先看一个真实场景：

用户反馈：「页面有时候会白屏」
操作步骤：「我就是正常点点点，突然就白了」
浏览器：未知
系统：未知
URL：未知

如果我们没有任何前端错误监控工具，这个问题几乎无从排查。

所以，一套基础的前端日志/错误系统至少要能回答：

什么时间？
哪个用户？
在哪个页面？
用的什么浏览器/系统？
做了什么操作？
报了什么错（堆栈、接口信息等）？

所以日志结构（特别是错误日志）要包含几个核心字段：

interface FrontendLog {
  level: 'info' | 'warn' | 'error';
  message: string;
  stack?: string;
  url: string;
  userId?: string;
  time: number;
  ua: string; // user agent
  extra?: Record<string, any>;
}

2. 捕获错误的几个入口

2.1 全局 JS 运行时错误

window.onerror = function (message, source, lineno, colno, error) {
  reportError({
    message,
    stack: error && error.stack,
    url: window.location.href,
    extra: { source, lineno, colno },
  });
};

注意：

这个能捕获同步脚本错误。
对跨域脚本，如果没有正确配置，会只得到 Script error.，需要在 script 标签上加 crossorigin 且服务端正确设置 CORS/SourceMap。

2.2 Promise 未处理异常

现代前端很多逻辑是基于 Promise / async 的，window.onerror 捕不到，需要监听：