指标是 A/B 测试的"眼睛"看什么决定了你发现什么,看错了一切白费。本文从零到一系统性地设计 A/B 测试的指标体系。
北极星指标 公司的"唯一真相"
1 个
一级指标 核心业务域指标
3-5 个
二级指标 策略可影响的中间指标
10-20 个
过程指标 诊断/定位用的指标
50+ 个
技术指标 性能/稳定性指标
不限
为什么需要分级? 不是所有指标都适合做决策。用过程指标做上线决策,相当于"因为用户点击了更多所以策略有效"但点击更多可能意味着更难找到想要的内容。
| 层级 | 职责 | 数量约束 | 变动频率 | 用于什么决策 |
|---|---|---|---|---|
| 北极星 | 衡量公司为用户创造的核心价值 | 严格 1 个 | 年为单位 | 公司战略 |
| 一级指标 | 衡量核心业务域的终极结果 | 3-5 个 | 季度/半年 | 事业部 OKR |
| 二级指标 | OEC 的候选来源,策略可影响的中间结果 | 10-20 个 | 月/季度 | 实验 OEC |
| 过程指标 | 用户行为漏斗各环节的拆解 | 50+ 个 | 随时 | 诊断/探索 |
| 技术指标 | 性能、稳定性、错误率 | 不限 | 随时 | 发布监控 |
核心原则:
北极星:用户日均价值时长(消费类产品)
一级 用户规模:DAU、WAU
指标 用户粘性:次日留存率、7 日留存率
商业变现:人均 GMV、LTV
内容/供给效率:人均内容消费量、供给匹配率
二级 CTR、转化率、完播率、客单价、ARPU
指标 新用户激活率、功能渗透率、推送打开率
搜索使用率、推荐点击率、收藏率
退款率、复购率、评论率
过程 曝光量、点击量、页面停留时长、滚动深度
指标 分渠道新增、分入口流量、分端使用比例
弹窗触达率、运营位曝光率、CTA 点击率
活动参与率、分享率、邀请率
OEC(Overall Evaluation Criterion)是实验的唯一核心决策指标。它是一个复合指标,将多个方向性指标合并为一个方向一致的"分数":
$$OEC = w_1 \cdot M_1^ + w_2 \cdot M_2^ + ... + w_k \cdot M_k^*$$
其中 $M_i^*$ 是标准化后的指标值,$w_i$ 是指标权重。
单一指标的问题:
"用留存率决策" 可能偏向保守策略(不做任何变化留存最稳)
"用 GMV 决策" 可能偏向激进的变现策略(伤害用户体验)
OEC 的价值:
留存率(40%) + GMV(35%) + 用户活跃度(25%)
一个策略必须在三者之间取得平衡才算"好"
方法一:北极星分解法(最推荐)
1. 确认北极星指标:如 LTV
2. 用历史数据建模 LTV 的驱动因素:
LTV = f(留存率, 付费率, ARPU, 获客成本, ...)
3. 计算每个驱动因素对 LTV 的边际贡献(弹性系数):
_i = LTV / 指标_i
4. 归一化弹性系数得到权重:
w_i = _i / _j
方法二:取舍实验法(Trade-off Experiment)
当明确权重困难时,直接用实验来"问"用户:
设计一个实验,刻意让两个指标发生冲突:
- 对照组:现状
- 实验组 A:牺牲一点 GMV + 提升留存
- 实验组 B:牺牲一点留存 + 提升 GMV
看哪组的效果对长期 LTV 更有利,反向推导权重。
| 要求 | 说明 | 错误示例 |
|---|---|---|
| 方向一致 | 所有子指标对 OEC 的贡献方向一致(都希望大或都希望小) | 留存率(越大越好)和卸载率(越小越好)不应同时出现 |
| 可加性 | 子指标应为线性可加的量,而非比率 | 把"CTR"和"人均 GMV"直接相加(量纲不同) |
| 标准化 | 所有子指标需标准化到同一量级 | 收入(元级)和留存率(百分级)直接相加 |
| 稳定性 | OEC 的权重在一个实验周期内不变 | 实验中途改权重做二次分析 |
OEC 标准化方法:
$$M_i^* = \frac{M_i - \mu_i}{\sigma_i}$$
其中 $\mu_i$ 和 $\sigma_i$ 是实验前该指标在全体用户中的均值和标准差。
## OEC 设计文档
### 北极星指标
LTV(用户生命周期价值)
### 驱动因素分析
| 指标 | 弹性系数 | 方向 | 权重 |
|------|---------|------|------|
| 30 日留存率 | 0.42 | 越大越好 | 40% |
| 人均 GMV | 0.35 | 越大越好 | 30% |
| DAU 活跃天数 | 0.23 | 越大越好 | 20% |
| 客诉率 | -0.10 | 越小越好 | 10% |
### OEC 公式
OEC = 0.4 Z(留存率) + 0.3 Z(GMV) + 0.2 Z(活跃天数) - 0.1 Z(客诉率)
### 验证方式
- 用近 6 个月历史数据验证 OEC 与 LTV 的相关性 0.85
- 用过往 10 个实验验证 OEC 的决策结果与长期效果的一致性 80%
护栏指标(Guardrail Metrics)是实验中"不能变坏"的指标集合。它们的角色不是判断策略是否有效,而是判断策略是否有害。
| 类型 | 定义 | 判断标准 | 触发后的动作 |
|---|---|---|---|
| 反向护栏 | 绝对不能显著恶化的指标 | 实验组显著差于对照组 | 强制暂停实验 |
| 正向护栏 | 不能显著下降的指标 | 实验组显著低于对照组 | 标记风险,继续观察 |
| 监控护栏 | 需要观察但不直接干预的指标 | 仅记录趋势 | 记录,纳入报告 |
反向护栏的选择"四个不":
| 类别 | 典型指标 | 为什么是护栏 |
|---|---|---|
| 不能破坏信任 | 客诉率、退款率、负面评价率 | 短期 GMV 上涨但用户信任崩塌,得不偿失 |
| 不能伤害体验 | 页面加载时间、Crash 率、ANR 率 | 性能劣化会抵消一切功能优化 |
| 不能导致流失 | 卸载率、注销账户数 | 策略可以无效,但不能加速用户离开 |
| 不能触碰红线 | 合规违规数、数据泄露事件 | 零容忍 |
正向护栏的选择"两个确保":
| 类别 | 典型指标 | 为什么是护栏 |
|---|---|---|
| 确保大盘稳定 | DAU、WAU | 局部优化不能以牺牲大盘为代价 |
| 确保长期健康 | 7 日留存、30 日留存 | 短期 GMV 上涨但长期留存下降是虚假繁荣 |
问题:护栏指标也需要统计检验,但 Type-II error 在这里更危险"没发现护栏恶化"比"误报了护栏恶化"更严重。
解决方案:
{
"guardrail_metrics": [
{
"name": "crash_rate",
"type": "reverse",
"alpha": 0.10,
"effect_threshold": 0.001,
"action_on_breach": "pause_experiment"
},
{
"name": "uninstall_rate",
"type": "reverse",
"alpha": 0.10,
"effect_threshold": 0.002,
"action_on_breach": "pause_experiment"
},
{
"name": "dau",
"type": "positive",
"alpha": 0.10,
"effect_threshold": 0.01,
"action_on_breach": "flag_and_continue"
},
{
"name": "day7_retention",
"type": "positive",
"alpha": 0.10,
"effect_threshold": 0.005,
"action_on_breach": "flag_and_continue"
}
]
}
指标的敏感度(Sensitivity)衡量的是:在同样的样本量下,这个指标能检测到的最小效应有多小。
敏感度越高 越容易检测到微小的策略效果 实验效率越高。
对于一个实验(样本量固定),指标能检测到的 MDE 越小,敏感度越高。
$$MDE = \frac{(Z_{\alpha/2} + Z_{\beta}) \cdot \sigma}{\sqrt{n/2}}$$
其中 $\sigma$(指标的标准差)是决定敏感度的关键方差越小,敏感度越高。
用变异系数(CV = /)来比较不同指标的敏感度:
| 指标类型 | 典型 CV | 敏感度 | 说明 |
|---|---|---|---|
| 点击率(CTR) | 0.3-0.5 | 极高 | 二值变量,方差天然小 |
| 转化率 | 0.5-0.8 | 高 | 同上 |
| 人均使用时长 | 0.7-1.2 | 中 | 有个体差异,但不太极端 |
| 人均 GMV / 收入 | 1.5-3.0 | 低 | 长尾分布,极端值主导 |
| 留存率 | 0.2-0.3 | 高 | 二值变量,但 baseline 低时需要更多样本 |
关键洞察:
方法:用历史 AA 数据,模拟不同效应量的实验,计算每个指标的 Power 曲线。
对于每个候选指标:
1. 取历史 AA 数据(50% vs 50%,无真实差异)
2. 在实验组人工注入效应量 = 1%, 2%, 3%, ..., 10%
3. 每次运行 t 检验,记录 p < 0.05 的比例(= Power)
4. 画出 Power ~ 的曲线
Power 曲线越"陡峭" 指标敏感度越高
CUPED 将方差降低为 $(1-\rho^2)$ 倍,等效 MDE 降低为 $\sqrt{1-\rho^2}$ 倍:
| CV | (结合历史数据) | CUPED 后有效 CV | MDE 降低 |
|---|---|---|---|
| CTR(0.4) | 0.6 | 0.32 | -20% |
| GMV(2.0) | 0.7 | 1.43 | -29% |
| 时长(1.0) | 0.8 | 0.60 | -40% |
代理指标(Surrogate Metric)是用容易观测的短期指标代替难以观测的长期指标。例如:
风险:优化代理指标 提升北极星指标。这是 A/B 测试中最隐蔽的错误。
方法一:相关性验证(Correlation Check)
用历史数据验证代理指标的变化( 代理)和北极星指标的变化( 北极星)是否一致:
$$Corr(\Delta \text{代理}, \Delta \text{北极星}) > 0.7$$
但光看相关性不够相关不代表因果。
方法二:实验回测(Experiment Backtest)
用历史实验数据验证:
对于过去 N 个已完成的实验(有短期和长期结果):
1. 用代理指标(短期)做决策 "上线"或"不上线"
2. 用北极星指标(长期)做决策 "上线"或"不上线"
3. 计算一致性 = 代理决策与北极星决策一致的比例
一致性 > 85% 代理指标可用
一致性 70-85% 代理指标有局限,需谨慎使用
一致性 < 70% 代理指标不可用,必须换
方法三:代理指标的"致命缺陷"检测
检查是否存在"代理涨了但北极星跌了"的案例:
| 代理指标 | 可能的断裂场景 |
|---|---|
| CTR | 标题党提升 CTR,用户点进去后失望离开 |
| 使用时长 | 界面变复杂导致用户找不到功能 操作时间变长 |
| 推送打开率 | 过度推送提升打开率,但卸载率也在上升 |
| 转化率 | 降价提升转化率,但 ARPU 下降导致 GMV 跌 |
代理指标显著 ,北极星验证通过 可决策
代理指标显著 ,北极星验证不通过 不能决策,修正代理指标
代理指标不显著,北极星验证通过 代理指标敏感度不够,需要更敏感的代理
代理指标不显著,北极星验证不通过 两者一致,可决策
最常见的矛盾场景:
场景 1:CTR 显著 ,但留存显著
场景 2:GMV 显著 ,但客诉率显著
场景 3:新用户指标 ,老用户指标
场景 4:指标 A 说"好",指标 B 说"坏",OEC 不显著
当矛盾出现时,用指标树从"结果指标"向"过程指标"层层拆解,定位根因:
GMV 下降的矛盾诊断:
GMV
付费用户数 ARPU 退款额
新付费户 老付费户 客单价 购买频次
曝光点击 点击付费
转化率 转化率
诊断步骤:
示例诊断:
GMV 下降 3%
付费用户数:-1%(不显著)
ARPU:-2%(显著)
客单价:持平
购买频次:-2%(显著) 定位到这儿
分品类看:
高频品类(日用品)购买频次:持平
低频品类(数码3C)购买频次:-8% 根因!
退款额:持平
结论:策略(搜索排序调整)导致低频高客单价商品的曝光减少,
用户看不到 不买 GMV 下降。
| 矛盾模式 | 常见原因 | 诊断方向 |
|---|---|---|
| CTR 留存 | Novelty Effect / 标题党 | 分 Day 看趋势 + 内容消费深度 |
| GMV 留存 | 过度变现 / 用户被"收割" | 分新老用户看 + 客诉内容分析 |
| 时长 留存 | 界面变复杂 / 操作效率下降 | 分功能模块看时长分布 |
| 新用户 老用户 | 策略偏向新用户 / 学习成本 | 老用户 HTE 分析 + 使用时长变化 |
| 转化 GMV | 吸引低价值用户 / 客单价稀释 | 分用户价值层级看转化变化 |
| 实验组好 但 OEC 不显著 | 各子指标方向不一致 / 权重不合理 | 检查 OEC 各分项的效应方向 |
不同团队对"同一个指标"可能有不同的计算口径:
"活跃用户":
增长团队:当日至少启动 App 一次
内容团队:当日至少消费一篇内容
商业化团队:当日至少产生一次付费行为
同一个名字,三个不同含义
实验结论不可对比、不可复现
{
"metric_id": "M_DAU_001",
"name": "DAU",
"display_name": "日活跃用户数",
"definition": "在统计日(UTC+8 00:00 ~ 23:59:59)内,至少完成一次 App 启动的用户数",
"calculation": "COUNT(DISTINCT user_id) WHERE event = 'app_launch' AND date = target_date",
"data_source": "events.user_behavior",
"owner_team": "data_platform",
"sensitivity_tier": "L1",
"tags": ["user_scale", "north_star_component"],
"related_metrics": ["WAU", "MAU", "DAU/MAU"],
"caveats": "不含小程序和 Web 端的活跃用户,如需跨端数据请使用 M_DAU_CROSS_001"
}
| 规范 | 说明 |
|---|---|
| 唯一 ID | 每个指标有全局唯一的 ID,不允许重复 |
| 语义唯一 | 同一语义只允许一个指标定义,不同口径必须用不同 ID |
| Owner 制 | 每个指标有明确的 Owner 团队,口径变更需 Owner 审批 |
| 血缘追踪 | 记录指标的上下游依赖关系(上游:数据源,下游:哪个 OEC 使用了它) |
| 变更日志 | 指标的每次口径变更必须有记录(变更原因、影响评估、审批人) |
| 生命周期 | 指标有状态:Active / Deprecated / Sunset,废弃指标不能用于新实验 |
初创期(0-50 个指标)
用 Notion / 飞书文档管理
核心要求:语义统一
成长期(50-200 个指标)
用指标管理平台(如 Amundsen、DataHub、自研)
核心要求:血缘追踪 + 变更审批
成熟期(200+ 个指标)
指标的指标(Meta-metrics):追踪指标的使用频率、质量评分
核心要求:指标治理定期清理僵尸指标、合并重复指标
北极星指标是否已明确定义且全公司认可?
北极星到一级指标的驱动关系是否有数据验证?
OEC 的子指标是否有明确的权重推导过程?
OEC 是否经过了历史实验的回测验证?
护栏指标是否覆盖了"四个不"和"两个确保"?
护栏指标的 是否已适当放宽(建议 0.10)?
核心指标的敏感度(CV)是否已经量化?
是否使用了代理指标?如果是,是否经过验证?
是否有指标体系用于诊断实验结论矛盾?
所有指标是否已注册到统一的指标字典?
指标字典是否有 Owner 和变更审批流程?
是否定期审计指标的废弃和重复情况?