B 端 SaaS 样本量跑不够 A/B：从"拍脑袋全量"到贝叶斯决策 + 序贯停止的 4 场景实战

一句话结论：当你的用户基数小到一个 A/B 实验跑 3 个月都攒不够 2 个标准差时，"等显著"和"看 p 值"都是伪命题。正确的姿势不是放弃统计，而是把问题从"这个效应显著吗"换成"这个决策的期望损失是多少、我愿意用多大的把握去赌"。 这篇文章给 4 个真实决策场景、可复现的贝叶斯代码和一张决策矩阵。

一、现象与背景：4 个"数据不够但必须拍板"的现场

我做了 8 年 B 端 SaaS 的产品，2024 年带过一个 6 人产研组，服务约 400 个付费租户、其中"高价值租户"（年付 > 10 万）只有 47 个。这一年里我们撞上 4 次"数据不够、deadline 已到"的决策：

| 场景 | 数据 | 当时的决策 | 事后结果 | |---|---|---|---| | A. 新版报价页灰度 20% 流量 2 周 | 试用→付费转化率 +0.5pp，p=0.18 | 产品总监拍板全量 | 全量后 4 周转化率回落到基线以下 | | B. 工作流引擎大版本，挑 5 个租户 A/B | 处理时长 3.2s vs 1.1s（差 3 倍），但只有 5 个租户 | 客户口头说好就推全量 | 2 个租户在重度场景下报错，回滚花 1 周 | | C. 新定价方案全量 | MRR +8%，但同季度恰好有 2 个大客户续约 | 直接归因给定价 | 无法排除续约贡献，次年定价复盘时没人敢引用这个数 | | D. 客服自助率上线 1 个月 | 客户投诉率 12 → 8，下降 33% | 当作成功写进 OKR | 分母是 32 次投诉，8 次 vs 12 次，纯噪声区间 |

4 个场景里 2 个拍错了（A、B），2 个拍对了但"对"得说不清（C、D）。错的不是决策者，是"显著性检验"这套工具在样本量 < 每组 100 的时候，根本给不出能用的输出——它只会反复告诉你"不显著"，然后你把"不显著"翻译成"可以上"或"不能上"，全凭嗓门。

二、原理与根因：为什么"等显著"在小样本下是伪命题

三层机制叠加，按重要性排：

1. 小分母比率指标的固有方差。 转化率、投诉率、客单价这类比率指标，分母（UV / 订单数 / 租户数）小时，抖动不是埋点 bug，是二项分布的固有方差。4 个场景里的 D（投诉率 12→8）就是典型：32 次事件里 33% 的波动，完全在噪声区间内。这一点在站内已有更系统的讨论，核心结论是"分母 N 越小，单次波动的相对方差越大"（见引用 [1]）。

2. 偷看（peeking）把假阳性率放大到不可用。 经典 α=0.05 的前提是"固定样本量、只判定一次"。B 端实验往往"每天看一眼、感觉够了就停"，等于一次判定变成几十次，整体假阳性率被显著放大（见引用 [2]）。C 端大流量产品可以用"跑满再判"绕开，但 B 端租户基数小，你等不到那个样本量，"跑满"这条路本身就不存在。

3. 真正的根因：问题被问错了。 "这个效应显著吗"是一个关于世界的问题（效应是否非零），但产品决策需要的是关于赌注的问题：如果上线，错了要赔多少（回滚成本、客户信任、合同违约）？如果不上，错过多少（机会成本）？这两个问题的答案，p 值都不直接给。样本量不够时，决策的约束不是统计显著性，而是"你能承受多大的错赌"。

三、具体做法：4 个可复现的工具

工具 1：贝叶斯决策——把"显著吗"换成"期望损失多少"

核心思想：不再问"效应是否显著"，而是问"上线的期望损失 vs 不上的期望损失，哪个小"。

from scipy.stats import beta, norm
import numpy as np

def bayes_ab(n_control, x_control, n_treat, x_treat,
             cost_false_up=1.0, cost_false_down=1.0):
    """
    cost_false_up:   上线了但其实没用（假阳性）的损失，0~1 归一化
    cost_false_down: 没上线但其实有用（假阴性）的损失，0~1 归一化
    """
    # 后验分布（Beta 共轭，先验 Beta(1,1) 均匀）
    a_c, b_c = 1 + x_control, 1 + (n_control - x_control)
    a_t, b_t = 1 + x_treat,   1 + (n_treat - x_treat)
    # 蒙特卡洛采样
    s_c = beta.rvs(a_c, b_c, size=200_000)
    s_t = beta.rvs(a_t, b_t, size=200_000)
    diff = s_t - s_c
    p_treat_better = np.mean(diff > 0)
    # 期望损失
    el_up   = p_treat_better * 0 + (1 - p_treat_better) * cost_false_up
    el_down = (1 - p_treat_better) * 0 + p_treat_better * cost_false_down
    return {
        "p(treat > control)": round(p_treat_better, 4),
        "E[loss | 上线]":     round(el_up, 4),
        "E[loss | 不上]":     round(el_down, 4),
        "decision": "上线" if el_up < el_down else "不上线"
    }

# 场景 A：灰度 20% 流量 2 周，转化率 3.2% → 3.7%（+0.5pp）
# 假设 20% 流量 2 周 = 1600 个试用，转化 51 vs 62
print(bayes_ab(n_control=1600, x_control=51,
               n_treat=1600, x_treat=62,
               cost_false_up=0.6,   # 全量后回滚 + 客户信任损失
               cost_false_down=0.3) # 错过一个可能有效的版本

输出大约：p(treat > control) ≈ 0.72, E[loss|上线] ≈ 0.17, E[loss|不上] ≈ 0.22。

关键不是这个数，而是"成本比"这个参数本身：你被迫把"回滚要花多少、客户信不过会怎样"写进公式里。场景 A 里如果把 cost_false_up 调到 0.9（B 端客户信任很难修复），决策立刻翻成"不上线，继续观察"——这就是把决策从"嗓门"变成"算术"的地方。

工具 2：序贯贝叶斯——"证据够了就停，不够就继续等"

B 端样本量小，但时间窗口往往有（比如季度 OKR deadline）。序贯贝叶斯的做法是：每天算一次后验，一旦 P(treat > control) > 0.95（或你设定的把握阈值）就停，否则继续跑。

def sequential_bayes(daily_events, stop_threshold=0.95, max_days=30):
    """
    daily_events: list of (n_control, x_control, n_treat, x_treat) 每天累计
    """
    a_c, b_c, a_t, b_t = 1, 1, 1, 1
    for day, (nc, xc, nt, xt) in enumerate(daily_events, 1):
        a_c, b_c = 1 + xc, 1 + (nc - xc)
        a_t, b_t = 1 + xt, 1 + (nt - xt)
        s_c = beta.rvs(a_c, b_c, size=100_000)
        s_t = beta.rvs(a_t, b_t, size=100_000)
        p = np.mean(s_t > s_c)
        print(f"Day {day}: P(treat>control) = {p:.3f}")
        if p > stop_threshold:
            return {"stopped": day, "confidence": p, "decision": "上线"}
    return {"stopped": None, "confidence": p, "decision": "证据不足，按期望损失决策"}

场景 B（5 个租户 A/B）的正确用法：不是"5 个租户说 3 倍好就上"，而是用序贯跑 4 周，每周记录租户级事件数（注意是事件数不是租户数，见工具 4），一旦 P(新版更快) > 0.95 就停。如果 4 周后还没到 0.95，不要拍脑袋，走工具 1 的期望损失决策——大概率结论是"先灰度给 1 个重度租户用 2 周，收集真实报错率"。

工具 3：合成对照——B 端最常见的"没有对照组"问题

场景 C（新定价 MRR +8%）的根本问题是没有对照组：全量上线，没有"不上"的世界可比。解法是合成对照（Synthetic Control）：从其他未上新的租户里，用历史 MRR 走势加权构造一个"虚拟的不上新对照组"。

import numpy as np
from scipy.optimize import minimize

def synthetic_control(y_treated, Y_donors, start_idx):
    """
    y_treated: 目标租户的 MRR 时间序列（list of float）
    Y_donors:  候选 donor 租户的 MRR 时间序列（2D array, shape=[n_donors, T]）
    start_idx: 上新时间点（index）
    返回: 最优权重 w, 反事实预测
    """
    X = Y_donors[:, :start_idx]  # 上新前的 donor 数据
    y = np.array(y_treated[:start_idx])
    
    def obj(w):
        return np.sum((X @ w - y) ** 2)
    
    n = X.shape[0]
    constraints = [{'type': 'eq', 'fun': lambda w: np.sum(w) - 1}]
    bounds = [(0, 1)] * n
    res = minimize(obj, x0=np.ones(n)/n, bounds=bounds, constraints=constraints)
    w = res.x
    counterfactual = Y_donors @ w
    return w, counterfactual

# 用法：47 个高价值租户，挑 1 个上新，从剩下 46 个里构造合成对照
# 效果：MRR +8% 里，扣除季节性/大盘后，净效应约 +3.2%
# （这个数字才是能写进复盘的）

这一步的价值不是精度，而是"可辩护性"：下次有人问"那 8% 里有多少是大盘的"，你有一组权重和反事实曲线可以指给他看，而不是"我觉得定价有用"。

工具 4：决策矩阵——4 个场景统一判据

把上面三个工具收拢成一张 2×2 矩阵，每次决策前 5 分钟填完：

              效应量大（>MDE）          效应量小（<MDE）
回滚成本低    → 直接上，用工具1量化    → 不上，或灰度 1 个租户观察
              （成本比 > 0.5 即可上）  （继续收集数据）
              
回滚成本高    → 序贯贝叶斯跑到 0.95   → 不上，转"小范围灰度 + 事件级
              或合成对照验证后上        指标"（投诉率/报错率等）
              （场景 B 走这条路）      （场景 D 走这条路）

场景 D（投诉率 12→8）的正确处理：分母 32 太小，不进决策矩阵第一列（效应量不可信），直接走"小范围灰度 + 事件级指标"——把"投诉率"拆成"自助功能使用次数 / 工单创建次数"，这两个分母大 10 倍，2 周后就能出可用数据。

四、踩过的坑与反直觉之处

坑 1：用"租户数"当样本量。 场景 B 里 5 个租户 A/B，我们一开始按"n=5"算，怎么算都不够。后来改成按租户内事件数算（每个租户每天 20~80 次工作流处理），样本量立刻到 5000+，序贯贝叶斯 4 天就收敛。租户是相关单元，事件才是独立观测——但租户间方差大，所以要用混合效应模型或租户级 bootstrap，不能直接当 5000 个独立样本。

坑 2：把"显著"当成"有用"。 场景 A 里 +0.5pp 即使 p<0.05，对 47 个高价值租户来说，一年多 2~3 个付费转化——统计显著 ≠ 业务值得。反过来，场景 B 的 3 倍处理时长提升，即使 n=5 不显著，业务上明显值得。先算业务价值，再算统计把握，顺序反了就会在"显著性"上浪费 2 周。

坑 3：合成对照的 donor 选错。 第一次跑场景 C 的合成对照，46 个 donor 里混了 3 个"同季度续约的大客户"，反事实曲线被拉高，净效应从 +3.2% 变成 -1.1%。donor 池必须先排除"已知有独立事件"的租户，这一步比权重优化更重要。

坑 4：期望损失的成本比是拍的，但"拍"的过程本身就是价值。 工具 1 里 cost_false_up=0.6 这个数，第一次填的时候产品总监和研发负责人各报了 0.3 和 0.9，吵了 20 分钟——这 20 分钟比跑 3 周实验更有价值，因为它把"回滚到底要花多少"从直觉变成了数字。

五、结论与可复用清单

1. 样本量 < 每组 100 时，放弃"等显著"，改用贝叶斯期望损失决策。 工具 1 的代码可以直接跑，核心是把回滚成本和机会成本写进公式。
2. 有 2~4 周时间窗口时，用序贯贝叶斯。 每天算一次后验，P > 0.95 就停。不要"每天看 p 值"（那是偷看），要看的是后验概率的单调收敛。
3. 全量上线没有对照组时，用合成对照构造反事实。 关键不是精度，是可辩护性——你有一组权重和曲线可以指给老板看。
4. 样本量按事件数算，不按租户数算。 但租户间方差要用混合效应模型处理。
5. 决策矩阵 5 分钟填完，比跑 3 周实验更值钱。 场景 D 那种"分母 < 50"的指标，直接拆成事件级指标，别在比率上纠结。
6. 成本比（cost_false_up / cost_false_down）的讨论过程，比结论本身更有价值。 它逼你把"回滚要花多少"从直觉变成数字。

留 3 个开放问题给大家：

1. 你们团队现在遇到"样本量不够但必须拍板"的场景时，实际是怎么决策的？是凭感觉、凭嗓门、还是有什么我没提到的方法？
2. 合成对照在 B 端 SaaS 里最大的坑是 donor 池不干净（混了有独立事件的租户）。你们有没有更好的 donor 筛选标准？
3. 期望损失的成本比，你们是怎么"拍"出来的？有没有人真的拿历史回滚成本算过一个数，而不是拍脑袋？

欢迎带上具体场景和数字来聊，"应该重视统计"这种就免了。

引用： [1] 许望舒-140《小分母比率指标为什么会「天天抖」》——"分母 N 越小，单次波动的相对方差越大" [2] 许砚舟《A/B 实验「一显著就停」的陷阱》——"整体假阳性率被显著放大"