最近团队在做首页改版时，产品经理和运营同学频繁提到AB测试（A/B Testing），但实际落地时发现大家对技术实现的理解差异很大。今天结合我们的踩坑经历，聊聊AB测试的工程化实现。

一、为什么你的AB测试可能不准？

去年我们曾用简单随机分流做按钮颜色测试，结果发现：

• 新用户群体中B方案转化率高出15%
• 但老用户群体却出现3%的下降

后来排查发现是随机分流时未考虑用户分层，导致实验组（Experimental Group）和对照组（Control Group）的用户画像分布不均。这种样本偏差（Sampling Bias）会直接导致辛普森悖罗（Simpson's Paradox）。

二、主流分流方案技术对比

1. 简单随机分流（Random Allocation）
2. 优点：实现简单，O(1)时间复杂度

3. 缺点：无法保证流量均匀，存在局部热点

4. Cookie分流（Cookie-Based）

5. 优点：用户标识稳定

6. 缺点：清理Cookie会导致用户实验组别变化

7. 一致性哈希（Consistent Hashing）

8. 优点：流量分配稳定，O(log n)时间复杂度

9. 缺点：需要维护虚拟节点环

10. 分层哈希（Stratified Hashing）

11. 结合用户特征分层（如：新客/老客、iOS/Android）
12. 每个层内单独哈希，保证各层流量比例
13. 时间复杂度O(k)，k为分层数量

三、Python实现分层哈希分流

from typing import Dict, Any
import hashlib
import json

class ABTestAllocator:
    def __init__(self, experiments: Dict[str, float]):
        """
        :param experiments: 实验配置字典 {实验名: 流量比例}
        """
        self.experiments = experiments

    def _get_strata(self, user: Dict[str, Any]) -> str:
        """用户分层逻辑"""
        # 示例：按设备类型+用户等级分层
        return f"{user.get('device_type', 'unknown')}_{user.get('user_level', 0)}"

    def allocate(self, user_id: str, user: Dict[str, Any]) -> str:
        """
        :return: 分配到的实验组名称
        """
        stratum = self._get_strata(user)
        hash_input = f"{user_id}_{stratum}".encode('utf-8')
        hash_val = int(hashlib.md5(hash_input).hexdigest(), 16) % 100

        cumulative = 0
        for exp_name, ratio in self.experiments.items():
            cumulative += ratio * 100
            if hash_val < cumulative:
                return exp_name
        return "control"  # 默认返回对照组

# 单元测试示例
def test_allocator():
    allocator = ABTestAllocator({"red_button": 0.3, "blue_button": 0.3})

    # 测试同用户ID多次分配结果一致
    user = {"device_type": "ios", "user_level": 2}
    assert allocator.allocate("user123", user) == allocator.allocate("user123", user)

    # 测试不同分层用户分配差异
    user_android = {"device_type": "android", "user_level": 2}
    assert allocator.allocate("user123", user) != allocator.allocate("user123", user_android)

四、生产环境注意事项

1. 冷启动问题
2. 初期流量不足时，建议采用贝叶斯统计（Bayesian Statistics）代替频率学派方法

3. 设置最小样本量（如每组至少1000个UV）再开始统计

4. 数据采集优化

5. 前端采用navigator.sendBeacon()异步上报
6. 服务端用Kafka做削峰处理
7. 关键指标建立实时监控看板

五、真实案例避坑指南

1. 用户ID泄露风险
2. 错误做法：直接使用手机号作为用户标识

3. 正确方案：采用单向哈希生成匿名ID

4. 多实验流量正交

5. 错误做法：所有实验共用同一分流维度

6. 正确方案：建立流量分层矩阵（如：10%流量专门测试支付流程）

7. 统计显著性误判

8. 错误做法：每小时检查p-value（p值）
9. 正确方案：使用序贯检验（Sequential Testing）方法

六、开放问题讨论

当遇到以下场景时，你会如何设计分流策略？

• 用户地域分布极度不均（如90%用户来自华东）
• 需要同时测试注册页表单字段和CTA按钮
• 移动端网络环境差异大（3G/4G/WiFi）

欢迎在评论区分享你的实战经验！