Firebase A/B测试用户随机分入测试变体的机制问询

Firebase A/B测试采用的是基于稳定哈希的伪随机分流，不属于主动调度式平衡随机化，本质是带一致性保证的简单随机化，不会根据各组实时用户占比调整新用户的分组结果。

• 分流计算完全不依赖实时组内用户数：系统不会统计当前实验组、对照组已有多少用户再做分配，你提到的“实验组100人、对照组98人时优先把新用户分给对照组”的逻辑不存在。
• 具体分流计算规则：系统会将「用户唯一标识（默认是Firebase生成的应用安装实例ID，若配置了登录用户ID绑定则使用业务侧用户ID）+ 实验全局唯一ID」拼接为固定字符串，通过固定种子的MurmurHash算法计算出稳定哈希值，再将哈希值归一化到0-1的数值区间，按照预先配置的分流比例切分区间，用户哈希值落在哪个区间就分到对应组。以50/50分流为例，归一化值小于0.5进对照组，大于等于0.5进实验组。
• 比例收敛特性：大样本量级下，各组用户占比会概率性收敛到配置的目标比例，小样本下出现的小幅比例偏差属于正常随机波动，不是系统调度的结果。同时这种计算方式能保证同一用户不会在实验周期内被分到不同组，避免组间串扰。

以下是与Firebase官方SDK实现一致的核心分流逻辑代码片段，可直接用于承包商交付核验：

function assignAbGroup(userUniqueId, experimentId, groupRatioConfig) {
  // groupRatioConfig 50/50分流配置示例：{ control: 50, treatment: 50 }
  const hashInput = `${userUniqueId}_${experimentId}`;
  // 采用Firebase官方使用的固定种子MurmurHash算法计算哈希
  const hashResult = murmurHashV3(hashInput, 12345); // 种子为实验全局固定值
  const normalizedHash = Math.abs(hashResult % 10000) / 10000; // 归一化到0-1区间

  let ratioAccumulator = 0;
  for (const [groupName, ratio] of Object.entries(groupRatioConfig)) {
    ratioAccumulator += ratio / 100;
    if (normalizedHash < ratioAccumulator) {
      return groupName;
    }
  }
}

核验要点：只要承包商实现的分流逻辑没有引入实时查询各组用户数再调整分配的规则，且满足「哈希输入包含用户ID+实验ID、固定种子稳定哈希、按固定比例切分哈希区间」三个特征，就完全符合Firebase官方的随机化协议。

内容的提问来源于stack exchange，提问作者Michelle DM