从样本量到置信区间：A/B测试全流程实战指南

1. 实验设计从样本量开始：先算明白再动手

做A/B测试这么多年，我最大的感受是：绝大多数实验失败，都不是死在分析方法上，而是死在实验设计阶段。最常见的一个场景就是——产品经理兴冲冲跑过来，说我们要上线一个新功能，帮你配好了实验，三个小时后问"数据出了吗？效果怎么样？"

三个小时能看出什么？三个小时连统计显著性需要的样本量零头都不够。

所以我想先聊一个很多教程不会开篇就讲的东西：样本量计算。这是整个实验框架的发动机，发动机没调好，后面全白搭。

1.1 为什么样本量是实验的第一步

要回答"实验要做多久、需要多少用户"，本质是在回答一个问题：我们有多大的把握，检测出真实存在的差异？

这里有个核心概念叫统计功效（Statistical Power），一般设定在80%或者90%。意思是说，如果新版本真的比旧版本好5个百分点，我们有80%或90%的概率能通过实验检测到这个差异。剩下的20%或10%，就是"真实存在差异但实验没看出来"的概率，统计学上叫第二类错误（β）。

另一个配套概念是显著性水平（α），通常取5%。意思是说，如果新版本其实没效果，我们有5%的概率会误判为有效果，这就是第一类错误。

这两个参数加上两个业务参数——基线转化率和最小可检测提升（MDE，Minimum Detectable Effect）——共同决定了样本量。最小可检测提升是业务方拍板的核心问题：我们希望检测出多小的效果？1%的提升？还是必须5%的提升才值得上线？这个值设得越小，需要的样本量就越大，实验周期就越长。

我很喜欢用一个类比来解释：样本量估算就像钓鱼选鱼竿，你想钓1公斤以上的鱼，和想钓0.1公斤以上的鱼，用的装备完全是两码事。MDE就是那条"最小值得钓的鱼"。

1.2 样本量计算公式与Python实现

对于转化率这类二值指标（用户要么转化，要么没转化），最常用的样本量近似公式是：

[
n = \frac{(Z_{\alpha/2} + Z_{\beta})^2 \cdot 2p(1-p)}{\delta^2}
]

其中：

• (p) 是基线转化率（对照组目前的转化率）
• (\delta) 是最小可检测提升（绝对值）
• (Z_{\alpha/2}) 是显著性水平对应的Z值，α=0.05时取1.96
• (Z_{\beta}) 是功效对应的Z值，功效=80%时取0.84，功效=90%时取1.28
• (n) 是每组所需样本量

直接看公式可能有点抽象，我把它写成Python函数，你直接调用就行：

python复制from scipy import stats

def calculate_sample_size(
    baseline_rate: float,
    minimum_detectable_effect: float,
    alpha: float = 0.05,
    power: float = 0.8,
) -> int:
    """
    计算两样本比例检验所需的每组样本量。
    
    参数:
        baseline_rate: 基线转化率，比如 0.2 表示20%
        minimum_detectable_effect: 最小可检测提升（绝对差值），比如 0.02 表示2个百分点
        alpha: 显著性水平，默认为0.05
        power: 统计功效，默认为0.8
    返回:
        每组所需样本量（向上取整）
    """
    z_alpha = stats.norm.ppf(1 - alpha / 2)
    z_beta = stats.norm.ppf(power)
    
    p = baseline_rate
    delta = minimum_detectable_effect
    
    n = (z_alpha + z_beta) ** 2 * 2 * p * (1 - p) / (delta ** 2)
    return int(n // 1 + 1)

# 示例：基线转化率20%，希望检测出2%的绝对提升，α=0.05，功效=80%
sample_size = calculate_sample_size(baseline_rate=0.2, minimum_detectable_effect=0.02)
print(f"每组需要 {sample_size} 个用户")

我实际跑一下，基线转化率20%、MDE=2个百分点时，每组需要约6150个用户，两组加起来一万二。如果你的产品日活只有五千，那这个实验要跑将近三天才能出结果。MDE改成1个百分点，样本量立刻变成约24600个，实验周期翻四倍。

这就是为什么MDE的设定极其关键。它不是拍脑袋拍的，而是业务上要回答：一个功能如果只带来0.5%的提升，值不值得承担全量上线的风险？ 如果值得，你就准备好海量样本；如果不值得，干脆把MDE调大，实验早点结束。

1.3 样本量参数敏感性速查

为了让你少走弯路，我把不同参数组合下的样本量列成一个表，方便快速估算实验规模。

从这张表能读出几件事：

第一，基线转化率越靠近50%，方差越大，需要的样本量越多。 同样是MDE=2%，基线10%需要3458个，基线50%就需要约9600个。

第二，功效从80%提到90%，样本量大约增加34%。 很多团队想都不想就设90%甚至95%，结果实验周期拉长一倍，还不如在80%功效下多做几轮实验迭代得快。

第三，α从5%收紧到1%，样本量急剧膨胀。 除非涉及资金安全、法律合规这类极高风险的改动，否则真的没必要用1%。

我见过太多团队，样本量没算清楚就上线，跑了一周发现对照组和实验组各攒了三千个用户，一算功效只有40%，这意味着即使新版本真的好用，也有60%的概率检测不出来。这不是数据分析的问题，是实验设计的问题。

2. 指标体系与分流策略：框架的地基

样本量解决了"做多久"的问题，接下来要解决"怎么做才干净"的问题。一个高效的实验框架，在正式跑实验之前，必须想清楚两件事：用什么指标评判胜负，以及怎么把用户分到不同的组里。

这两件事如果做不好，后面再高级的统计方法都救不回来。

2.1 指标体系：核心指标、护栏指标、过程指标三层设计

很多团队做实验只看一个指标，比如只看点击率。这是非常危险的——点击率涨了，但人均时长掉了、投诉率涨了，这种"胜利"很可能是个陷阱。

我的建议是建立三层指标体系：

第一层：核心指标（决策指标）。 整个实验唯一用来做上线/不下线决策的指标。通常是一个，最多两个。比如电商场景下是支付转化率，内容场景下是人均阅读时长。注意，核心指标必须是北极星指标或者它的一级拆解指标，不能是虚荣指标（比如UV、PV这种）。

第二层：护栏指标（Guardrail Metrics）。 用来监控"实验组是否伤到了不该伤的东西"。电商场景里，核心指标是转化率，护栏指标就是客单价、退款率、投诉率。内容场景里，核心指标是阅读时长，护栏指标就是跳出率、负反馈比例。护栏指标不需要达到显著性，但如果出现恶化趋势且接近显著性边界，就需要拦截实验、停止放量。

第三层：过程指标（诊断指标）。 用来解释"核心指标为什么变了"。比如实验组的支付转化率提高了，过程指标能告诉我们，是首单转化提升了，还是复购转化提升了？是搜索页进来的用户转化好了，还是信息流进来的用户转化好了？过程指标不参与决策，但参与归因分析。

有了三层指标，你搭建框架的时候就要预留指标配置的位置，而不是临时取数、临时写SQL。我用Python习惯把指标配置定义成字典结构：

python复制experiment_metrics = {
    "primary": {
        "name": "purchase_rate",
        "type": "ratio",
        "aggregation": "user_level",
        "decision": True,
    },
    "guardrail": [
        {"name": "refund_rate", "type": "ratio", "aggregation": "user_level"},
        {"name": "avg_order_value", "type": "continuous", "aggregation": "user_level"},
    ],
    "diagnostic": [
        {"name": "first_purchase_rate", "type": "ratio", "aggregation": "user_level"},
        {"name": "repeat_purchase_rate", "type": "ratio", "aggregation": "user_level"},
    ],
}

这个字典会贯穿整个框架：样本量计算、日常监控、最终分析，全都从这里面读配置。好处是，实验的"胜负标准"在跑实验之前就定死了，不会被事后调来调去。

2.2 分流策略：完全随机与分层随机

指标定好了，接下来是分流。

完全随机最简单，对每个进入实验的用户，按哈希值取模或者生成随机数，决定分到哪个组。实现起来没问题，但它有个缺点：在小样本量下，分组之间的用户特征可能不均衡。 比如实验组里的新用户比例恰好比对照组高5个百分点，而新用户的转化率本来就偏低，那实验组输就不一定是产品方案的问题，而是分流运气的问题。

分层随机能缓解这个问题。做法是先把用户按照关键特征切成若干个层（strata），比如新老用户、注册渠道、活跃度等级，然后在每个层内部独立随机分组。这样做的好处是，每一层里的实验组和对照组用户结构完全一致，组间可比性大幅提高。

在Python里实现分层分流，我习惯用pandas + numpy的组合：

python复制import pandas as pd
import numpy as np
import hashlib

def assign_stratified_2groups(
    user_df: pd.DataFrame,
    id_column: str = "user_id",
    strata_columns: list = None,
    control_ratio: float = 0.5,
    salt: str = "20240201",
) -> pd.DataFrame:
    """
    分层随机分流到对照组或实验组。
    
    实现思路：
    1. 根据分层字段组合出“分层ID”
    2. 在每个分层内部，用user_id + salt 做哈希后取模分流
    """
    df = user_df.copy()
    
    if strata_columns:
        df["stratum_id"] = df[strata_columns].astype(str).agg("_".join, axis=1)
    else:
        df["stratum_id"] = "all"
    
    def _assign_group(group):
        group = group.copy()
        hash_values = group[id_column].astype(str) + salt
        hash_int = hash_values.map(lambda x: int(hashlib.md5(x.encode("utf-8")).hexdigest()[:8], 16))
        group["group"] = np.where(hash_int % 100 < control_ratio * 100, "control", "treatment")
        return group
    
    df = df.groupby("stratum_id", group_keys=False).apply(_assign_group)
    return df

# 示例使用
users = pd.DataFrame({
    "user_id": np.arange(1, 10001),
    "is_new": np.random.choice([0, 1], size=10000, p=[0.7, 0.3]),
    "channel": np.random.choice(["search", "feed", "ads"], size=10000),
})

users_with_group = assign_stratified_2groups(
    users,
    strata_columns=["is_new", "channel"],
    control_ratio=0.5,
    salt="experiment_20240201",
)

# 验证分层是否均衡
check = users_with_group.groupby(["is_new", "channel", "group"]).size().unstack(fill_value=0)
check["treatment_ratio"] = check["treatment"] / (check["control"] + check["treatment"])
print(check)

这里要做个关键提醒：哈希必须加盐（salt）。 盐通常是一个随机的实验编号或日期字符串。如果不加盐，每次实验对同一个用户的分组是固定的，会导致前一个实验的影响一直延续到后一个实验，组间污染非常严重。盐的作用就是让每一次实验都重新洗牌。

加盐之后还要注意一个概率问题。用户ID经过哈希取模，理论上每个用户进入实验组的概率是50%，但实际上每个用户进入实验组的概率完全随机的，不取决于用户ID的任何规律。我们只是用哈希的方法把用户稳定地映射到组里，保证同一个用户在实验期间不会在组间跳来跳去。

2.3 SRM：实验分组是否被破坏的体检指标

分流做完，有个体检指标必须盯：样本比例不均衡（SRM，Sample Ratio Mismatch）。

我们的预期是对照组和实验组各占50%，但有时候因为埋点漏采、前端缓存、服务端路由bug，实际的两组比例会偏离50%。一旦偏离超过一定幅度，实验结论就不可信了。比如对照组实际只有40%、实验组60%，那转化率差异可能只是两组用户结构不同导致的，而不是产品方案导致的。

SRM的判断用卡方检验就行，我一般会在实验数据接入后先跑一遍：

python复制from scipy.stats import chi2_contingency

def check_srm(control_n: int, treatment_n: int, expected_ratio: float = 0.5):
    """检查两组样本量是否显著偏离预期比例"""
    observed = [control_n, treatment_n]
    total = control_n + treatment_n
    expected = [total * expected_ratio, total * (1 - expected_ratio)]
    
    chi2, p_value, dof, expected_freq = chi2_contingency([observed, expected])
    return p_value

# 示例
p_val = check_srm(control_n=4800, treatment_n=5200, expected_ratio=0.5)
print(f"SRM检验p值: {p_val:.4f}")

有个实操经验很重要：如果SRM检验的p值小于0.01，通常说明分流系统有严重bug，这个实验应该立刻停掉排查，而不是继续跑下去。 如果p值在0.01到0.05之间，属于灰色地带，需要结合具体流失人群、流失原因来判断。我一般保守起见，也会终止实验排查原因。

3. Python核心代码：从Z检验到置信区间的完整实现

框架搭好了，分组没问题了，数据攒够了，接下来才进入最激动人心的环节：分析结果。这里我用Python演示一套完整的实验分析流程，从比率类指标到连续类指标，从点估计到置信区间，全部给出可运行的代码。

3.1 比率类指标：转化率的Z检验与置信区间

A/B测试里最常见的指标就是转化率，比如点击率、注册率、购买率。这类指标本质上是二项分布，在大样本下可以用正态近似，用Z检验来判断两个比例的差异是否显著。

我直接封装一个函数，输入对照组和实验组的转化用户数和总用户数，输出Z值、p值和置信区间：

python复制import numpy as np
from scipy import stats

def proportion_ab_test(
    control_conversions: int,
    control_total: int,
    treatment_conversions: int,
    treatment_total: int,
    alpha: float = 0.05,
):
    """
    两样本比例Z检验 + Wald置信区间。
    
    返回:
        dict: 包含转化率、差值、置信区间、p值等核心结果
    """
    p_control = control_conversions / control_total
    p_treatment = treatment_conversions / treatment_total
    
    # 合并比例（零假设下的共同比例）
    p_pooled = (control_conversions + treatment_conversions) / (control_total + treatment_total)
    
    # 标准误
    se = np.sqrt(p_pooled * (1 - p_pooled) * (1 / control_total + 1 / treatment_total))
    
    # Z统计量
    z_score = (p_treatment - p_control) / se
    p_value = 2 * (1 - stats.norm.cdf(abs(z_score)))
    
    # Wald置信区间（差值的95%置信区间）
    diff = p_treatment - p_control
    se_diff = np.sqrt(p_control * (1 - p_control) / control_total + p_treatment * (1 - p_treatment) / treatment_total)
    z_alpha = stats.norm.ppf(1 - alpha / 2)
    ci_lower = diff - z_alpha * se_diff
    ci_upper = diff + z_alpha * se_diff
    
    # 相对提升
    relative_lift = diff / p_control if p_control > 0 else None
    
    return {
        "control_rate": p_control,
        "treatment_rate": p_treatment,
        "absolute_diff": diff,
        "relative_lift": relative_lift,
        "ci_lower": ci_lower,
        "ci_upper": ci_upper,
        "z_score": z_score,
        "p_value": p_value,
    }

# 示例：对照组10000人，转化2000人；实验组10000人，转化2150人
result = proportion_ab_test(
    control_conversions=2000,
    control_total=10000,
    treatment_conversions=2150,
    treatment_total=10000,
)

print(f"对照组转化率: {result['control_rate']:.4f}")
print(f"实验组转化率: {result['treatment_rate']:.4f}")
print(f"绝对提升: {result['absolute_diff']:.4f}")
print(f"相对提升: {result['relative_lift']:.2%}")
print(f"95%置信区间: [{result['ci_lower']:.4f}, {result['ci_upper']:.4f}]")
print(f"p值: {result['p_value']:.4f}")

这个代码跑出来，如果p值小于0.05，说明转化率差异在统计上显著；置信区间如果整体在0以上，说明实验组有更高的转化率且这个差异不太可能是抽样误差。

3.2 连续类指标：人均时长的t检验

转化率是比率，但很多核心指标其实是连续值，比如人均时长、客单价、GMV。这类指标不能直接套Z检验，因为它们的分布通常不是二项的，我们用t检验（独立样本t检验）来处理。

t检验的基本假设是两组数据近似正态分布。真实业务里，人均时长这种东西往往是长尾分布，偏得厉害。这个问题的处理办法是，先对指标做变换（比如对数变换），或者直接用bootstrap方法替代参数检验。但在常规场景下，大样本的t检验对非正态分布有一定的稳健性，你可以先看分布再决定。

我的建议是：能聚合到用户级别的指标，先聚合，再跑t检验。 比如人均时长，先把每个用户的累计时长算出来，形成两个用户级别的数组，再跑t检验：

python复制from scipy import stats

def continuous_ab_test(control_values, treatment_values, alpha: float = 0.05):
    """
    独立样本双侧t检验 + Cohen's d效应量。
    
    参数:
        control_values: 对照组每个用户的指标值列表（或数组）
        treatment_values: 实验组每个用户的指标值列表（或数组）
    """
    control_values = np.asarray(control_values, dtype=float)
    treatment_values = np.asarray(treatment_values, dtype=float)
    
    # 独立样本t检验（默认方差齐性假设，如果方差不齐可使用equal_var=False）
    t_stat, p_value = stats.ttest_ind(control_values, treatment_values, equal_var=False)
    
    mean_control = control_values.mean()
    mean_treatment = treatment_values.mean()
    diff = mean_treatment - mean_control
    
    # 标准误和置信区间
    se = np.sqrt(control_values.var(ddof=1) / len(control_values) + treatment_values.var(ddof=1) / len(treatment_values))
    dof = se**4 / ((control_values.var(ddof=1) / len(control_values))**2 / (len(control_values) - 1) + 
                   (treatment_values.var(ddof=1) / len(treatment_values))**2 / (len(treatment_values) - 1))
    t_alpha = stats.t.ppf(1 - alpha / 2, df=dof)
    ci_lower = diff - t_alpha * se
    ci_upper = diff + t_alpha * se
    
    # Cohen's d（标准化效应量）
    pooled_std = np.sqrt(((len(control_values) - 1) * control_values.var(ddof=1) + 
                          (len(treatment_values) - 1) * treatment_values.var(ddof=1)) / 
                         (len(control_values) + len(treatment_values) - 2))
    cohens_d = diff / pooled_std if pooled_std > 0 else 0
    
    return {
        "mean_control": mean_control,
        "mean_treatment": mean_treatment,
        "absolute_diff": diff,
        "relative_lift": diff / mean_control if mean_control != 0 else None,
        "ci_lower": ci_lower,
        "ci_upper": ci_upper,
        "t_stat": t_stat,
        "p_value": p_value,
        "cohens_d": cohens_d,
    }

# 示例：模拟两组用户的人均时长
np.random.seed(42)
control_duration = np.random.exponential(scale=10, size=5000)  # 均值约10
treatment_duration = np.random.exponential(scale=10.5, size=5000)  # 均值约10.5

res = continuous_ab_test(control_duration, treatment_duration)
print(f"对照组人均时长: {res['mean_control']:.2f}")
print(f"实验组人均时长: {res['mean_treatment']:.2f}")
print(f"绝对提升: {res['absolute_diff']:.2f}")
print(f"95%置信区间: [{res['ci_lower']:.2f}, {res['ci_upper']:.2f}]")
print(f"p值: {res['p_value']:.4f}")
print(f"效应量Cohen's d: {res['cohens_d']:.4f}")

注意我特意加了Cohen's d效应量。它回答了一个p值回答不了的问题：这个差异在实际中到底有多大？ Cohen's d的经验判断标准是：0.2小效应，0.5中等效应，0.8大效应。线上实验通常能做出0.1甚至0.05的效应就已经来之不易了——A/B测试的效应量普遍偏小，所以样本量才需要那么大。

3.3 差值置信区间才是决策主力

有个观念我想反复强调：p值只是"有没有差异"的证据，置信区间才告诉我们"差异有多可信、有多大"。 如果你的实验报告里只有p值，而没有置信区间，这份报告的决策价值是打了折扣的。

置信区间能帮你判断三件事：

第一，差异是否为0。 如果95%置信区间不包含0，说明效应在统计上显著。

第二，差异的最小可能值。 置信区间的下限，是最保守的估计。比如转化率提升的95%置信区间是[0.3%, 2.1%]，那么即使打对折，新版本至少也有0.3%的提升，这个时候上线决策压力就小很多。但如果置信区间是[-0.1%, 2.5%]，下限是负的，那你就要谨慎了——这个实验可能是无效的。

第三，效应大小是否值得。 即使置信区间是[0.1%, 0.2%]，p值也显著，但如果你的业务决策阈值是"提升必须超过1%才值得上线"，那这个显著的结果也不足以支撑上线。

这也是为什么我上面两个函数都返回了置信区间，而不是只给一个p值。做决策的时候，多看一下区间两端的数，能少踩很多坑。

4. 结果解读中的五个隐蔽陷阱

很多人以为A/B测试的难点在代码实现，或者在埋点采集——这些当然重要，但我踩过最深的坑，全部在结果解读环节。这一节我集中讲五个隐蔽陷阱，每个都是实际项目中反复出现的。

4.1 陷阱一：p值"碰线"与偷看数据

p值小于0.05就宣布胜利？没那么简单。A/B测试有一条铁律：不能反复偷看数据，更不能看到p值小于0.05就提前停止实验。

为什么？因为p值本身是随机变量，实验过程中反复查看p值，就像反复买彩票看是否中奖——总有一次会撞到小于0.05的。这在统计上叫"多重比较问题"或"p值篡改"。

我举个例子。假设实验没有任何真实效果，你每跑一天就看一次p值。实验跑30天，至少有一天p值<0.05的概率有多高？粗略估算一下：如果每天独立判断，错误的概率大约是1 - (0.95)^30 ≈ 78.5%。也就是说，哪怕新版本完全没效果，只要你天天偷看，有近八成的概率会看到一个"显著"的p值。 这是个极其可怕的数字。

正确的做法是：实验开始前就用第一节的样本量公式算好所需样本量和持续时间，期间不看不分析，到时间节点一次性分析。如果实在要监控，只看两类指标：数据质量指标（比如埋点缺失率）和安全事件指标（比如严重的线上故障），不要看效果p值。

4.2 陷阱二：显著性不等于实际意义

p值小于0.05，只说明"这个差异不太可能是抽样误差造成的"，但完全不说明"这个差异值得上线"。

我见过一个案例：某团队优化了一个按钮文案，实验组转化率比对照组高了0.1个百分点，p值=0.03，看起来"显著胜出"。但仔细一算，这个提升给公司带来的增量营收，折合成年化还覆盖不了这次开发的成本。这就是统计显著和业务显著之间的鸿沟。

业务显著的判断标准应该在实验设计阶段就定好：最小可检测提升（MDE）就是业务意义上"值得上线"的门槛。 如果置信区间的下限低于MDE，哪怕p值显著，这个实验带来的实际收益也可能打不到你的预期。

所以我在实验结论模板里，永远写两栏：统计结论（p值、置信区间）和业务结论（是否达到MDE、增量收益估算），两者缺一不可。

4.3 陷阱三：新奇效应与首因效应

新产品功能上线时，用户因为新鲜感而表现异常，这叫新奇效应。它的典型表现是：实验组短期数据暴涨，但一段时间后回落。反过来，如果新功能改变了用户熟悉的交互路径，用户短期内因为不适应而表现更差，过一段时间适应后反而变好，这叫首因效应。

这两类效应共同指向一个结论：只看实验前几天的数据做决策，等于开车只看后视镜。

处理办法有几个：

• 设置最短实验周期。 至少要覆盖一个完整的业务周期，比如电商平台至少要7天（覆盖周末高峰期），内容平台至少72小时（覆盖完整的用户活跃周期）。
• 做时间切片分析。 把实验周期切分成多个时间段，逐段计算效应量。如果发现效应量前3天是+5%，后5天变成+1%，说明新奇效应在消退，需要延长实验继续观察。
• 用"留存效应"做二次确认。 如果实验组的次日留存率、7日留存率也显著高于对照组，那这个效果的可信度就高很多。

代码上，时间切片分析并不复杂。只需要按天（或按小时）分组，分别调用比例检验函数：

python复制# 假设daily_data是一个DataFrame，列包括：
# date, group, conversions, total_users
import pandas as pd

def daily_power_analysis(daily_data: pd.DataFrame):
    results = []
    for date, day_df in daily_data.groupby("date"):
        control = day_df[day_df["group"] == "control"].iloc[0]
        treatment = day_df[day_df["group"] == "treatment"].iloc[0]
        
        r = proportion_ab_test(
            control_conversions=control["conversions"],
            control_total=control["total_users"],
            treatment_conversions=treatment["conversions"],
            treatment_total=treatment["total_users"],
        )
        results.append({"date": date, "lift": r["absolute_diff"], "p_value": r["p_value"]})
    
    return pd.DataFrame(results)

拿到这张按天分布的结果表，你会很清楚地看到效果是不是稳定、是不是在衰减。

4.4 陷阱四：辛普森悖论与整体分解

整体数据显著，细分到各个层级却不显著甚至相反，这就是辛普森悖论。电商场景里特别容易发生。

举个例子：实验组的整体转化率看起来比对照组的整体转化率高，但当你拆开新用户和老用户分别看时，实验组在两个人群里的转化率其实都低于对照组。为什么会这样？因为实验组里新用户的比例恰好远高于对照组，而新用户整体转化率低于老用户，所以整体一平均，实验组反而"胜出"了。

这说明多维度交叉分析在实验复盘里不是可选项，而是必选项。我通常至少会做三个维度的交叉：新老用户、渠道（搜索/推荐/广告）、设备（iOS/Android）。如果发现整体结论和分层结论不一致，立刻停下来排查分流是否均衡（回到SRM检查），再排查是否忽略了某个关键分组变量。

4.5 陷阱五：多重比较与"假阳性"放大器

一个实验只比一个核心指标，犯错的概率是5%。但如果一个实验同时比较20个指标，每个指标都单独判断是否显著，那么一个指标假阳性的概率就变成 1 - (1 - 0.05)^20 ≈ 64.2%。

解决多重比较问题有几个思路：

• 事前列出核心指标和护栏指标，控制指标数量。 一般不超过5个。
• 用Bonferroni校正收紧p值阈值。 比如5个指标，每个指标的α就从0.05变成0.01。这在statsmodels里一行代码就能实现。

python复制def bonferroni_correction(p_values: list[float], alpha: float = 0.05):
    """Bonferroni校正：返回调整后的显著性阈值和是否通过"""
    m = len(p_values)
    adjusted_alpha = alpha / m
    significant = [p <= adjusted_alpha for p in p_values]
    return {"adjusted_alpha": adjusted_alpha, "significant": significant}

注意Bonferroni是偏保守的，有时候会漏掉真阳性的发现。如果实验指标很多，可以考虑FDR（错误发现率）控制方法，用statsmodels.stats.multitest.multipletests里的fdr_bh方法。但对于业务实验，我强烈建议从源头减少指标数量，而不是靠统计校正兜底。

5. AA测试与长期效果追踪：实验后别急着全量

实验出结果了，p值显著了，置信区间也好看，是不是就可以直接全量上线了？我的经验是：先冷静，做一轮AA测试和长期效果评估再动手。

5.1 AA测试：验证实验系统没"偏袒"

AA测试，就是对照组和实验组实际上跑的是同一个版本，用来验证实验框架本身是否无偏。一个靠谱的实验框架，AA测试应该绝大多数时候"不显著"。

我每次上线一个新实验分流模块，都会先跑最少3天的AA测试，核心关注两件事：

• SRM检验的p值是否大于0.1。 如果SRM显著，说明分流模块有bug。
• 核心指标的p值是否大于0.05。 如果显著，说明两组虽然跑同一个版本，但用户结构或埋点采集已经不可比了。

AA测试的时间不需要太长，因为它的目的不是检测效果，而是检测偏差。3到5天足够了。跑完AA测试如果两个检查都通过，再大规模上正式实验，我心里就有底了。

Python里可以用第一节的SRM检验和第三节的proportion_ab_test，把实验组的"转化数"换成对照组自己的转化数，跑一遍看看p值。

5.2 长期效果：短期显著不代表长期赚钱

哪怕实验在统计上稳如老狗，我也不会直接宣布胜利。A/B测试本质上是一个短期观察实验，通常跑1到2周就出结果，但产品改动的影响是长期的。短期的转化率提升，有可能是通过"透支用户信任"换来的。

我习惯在实验结束后做两件长期追踪：

第一，全量后继续监控护栏指标至少2周。 比如退款率、投诉率、负反馈率这类指标，如果实验期间没有显著变化，但全量之后开始爬升，说明实验样本量还不充分，或者短期数据覆盖不了长尾效应。

第二，做增量效果归因。 实验组相对对照组的增量效果，是不是真实的新增价值？还是说只是把用户未来的需求提前释放了？典型例子是促销类活动：实验组看起来GMV大幅提升，但活动结束后销售开始萎靡。所以，这类实验的核心指标不能只看活动期间的GMV，还要看活动结束后的回访率和复购率。我把这个叫做"拉长时间窗口的真实影响评估"。

5.3 多实验并行时的隔离与协调

当实验越来越多，难免出现多实验并行的局面。比如推荐算法在跑A实验，同时支付流程在跑B实验，一个用户可能同时进入两个实验。这时候要警惕实验间的交互效应。

处理思路有几个：

• 实验分域： 每个实验只影响自己负责的用户域，多个实验用户域之间不重叠。这种做法最干净，但对流量要求高。
• 实验分层： 给不同的实验分配不同的用户哈希维度。比如实验A用user_id哈希分流，实验B用device_id哈希分流，这样两个实验的组别分配相对独立。但要注意哈希的盐不能一样，否则用户会正好形成相关性分组。

我建议实验平台建立一个全局实验注册表，记录每个实验的分配机制和影响范围。新实验上线之前，先查一下有没有和正在运行的实验冲突，尤其是两个实验都改到同一个核心漏斗环节的时候。

这部分的代码其实就两件事：实验注册表的增删查改，以及分流哈希冲突检测。前者你可以用一张简单的数据表维护，后者只需要比对实验参数里的salt和分流维度，有冲突就换一个salt。

写在最后：实验框架不是代码，是决策习惯

这篇文章写下来，你会发现我用Python做的事情其实不多——算样本量、分层分流、Z检验、t检验、置信区间、AA测试，加起来不过几段代码。真正的核心是一套决策习惯：先定MDE再开实验，先做AA再信分组，先看置信区间再做判断，先做时间切片再谈结论。

我见过太多团队，把A/B测试当成一个"用数据说服老板"的工具，而不是一个"帮自己判断该不该上线"的决策系统。结果就是实验设计粗糙、数据解读随意、上线决策冲动，最后统计显著的效果全量上线后翻车。

如果你只记住一个要点，我希望是：实验框架的价值，不是提供一组统计数字，而是倒逼整个团队在动手之前就把"什么算赢、凭什么信、输了怎么办"想清楚。 这几件事想清楚了，代码只是最后落地的工具；这几件事没想清楚，再漂亮的Python代码也只是给错误决策披了一层科学外衣。

最后再分享一个小技巧：每次实验结束，我都建议团队写一份一页纸的实验复盘，格式固定——实验假设、核心指标变化、置信区间、是否达到MDE、是否触发护栏指标、是否发现异常分层。写多了你会发现，大部分实验其实"没结论"或"假阳性"，但真正有价值的产品洞察，往往就藏在那几个"异常分层"里。这个习惯，比任何统计模型都值钱。