东辑事厂1. AB实验中的单元定义：从概念到实践
在AB实验的设计与实施过程中，"单元"是最基础也最容易被忽视的核心概念。我第一次真正理解单元的重要性，是在一次失败的实验复盘会上——当我们发现实验组和对照组的核心指标差异完全无法解释时，最终发现问题的根源竟然是开发团队和分析团队对"单元"的理解存在根本性分歧。
分流单元（Assignment Unit）决定了实验流量如何划分，它像是实验的"最小原子"，直接关系到样本的随机性和独立性。常见的分流单元包括：
- User ID：最常用的单元类型，适合用户级长期效果评估
- Device ID：在跨设备场景下作为补充标识
- Session ID：适用于短期、会话级的效果验证
- Cookie ID：在未登录场景下的替代方案
而分析单元（Analysis Unit）则是我们计算指标时的统计基础，它决定了"一个数据点代表什么"。在理想情况下，分流单元与分析单元应该保持一致（即User-Level实验用User-Level指标），但实际业务中常常需要面对二者的分离：
python复制# 典型的分流单元实现代码示例（伪代码）
def assign_experiment_group(user_id, experiment_name):
hash_value = hash(f"{user_id}_{experiment_name}")
return "control" if hash_value % 100 < 50 else "treatment"
关键认知：分流单元决定了实验的随机化机制，而分析单元决定了指标的统计性质。二者的错配会导致辛普森悖论等统计陷阱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分流单元的选择逻辑与业务适配
2.1 用户级分流（User-Level Assignment）
这是最常见也最稳妥的分流方式，以系统注册的用户ID作为分流依据。我在电商平台的实验表明，用户级分流能有效避免同一用户在不同设备上的行为干扰。其实施要点包括：
- 需要稳定的用户标识体系
- 新老用户要分开分层（新用户行为方差通常更大）
- 典型适用场景：会员体系改版、个性化推荐算法
但去年我们遇到一个典型案例：当实验针对的是未登录用户的商品详情页改版时，使用User ID会导致超过60%的流量被归类为"未分组"，最终不得不改用Cookie ID作为分流单元。
2.2 会话级分流（Session-Level Assignment）
在内容型产品中，Session级分流可能更合适。某新闻App的实测数据显示，当测试文章排版样式时：
- 用户级分流：CTR提升2.3%（p=0.12）
- 会话级分流：CTR提升4.1%（p=0.03）
这种差异源于内容消费行为的会话独立性。但需要注意：
- 需要确保会话间的独立性（避免同一用户多次进入不同组）
- 不适合长期效果评估（用户可能在后续会话中被重新分组）
- 典型应用场景：落地页优化、促销活动测试
2.3 混合分流策略
在复杂的业务场景下，我们开发了一套混合分流方案：
- 核心业务指标采用User-Level分流
- 页面级功能采用PageView-Level分流
- 运营活动采用Session-Level分流
通过分层正交设计确保各实验互不干扰，这在我们的618大促实验中减少了37%的样本量需求。
3. 分析单元的统计学考量与陷阱规避
3.1 单元间的依赖性风险
最常见的分析误区是忽视单元间的依赖性。在一次首页改版实验中，我们最初按PV计算点击率，得出"改版提升CTR 15%"的结论。但改用User-Level分析后，实际提升只有7%。这是因为：
- PV-Level分析：假设每次浏览是独立事件
- User-Level分析：考虑用户行为的内在一致性
r复制# 模拟展示依赖性影响（R代码示例）
set.seed(123)
users <- data.frame(
user_id = rep(1:1000, each=10),
group = rep(c("control","treatment"), each=5000),
ctr = ifelse(rep(rnorm(1000), each=10) > 0, 0.3, 0.1)
)
pv_results <- t.test(ctr ~ group, data=users) # 错误方法
user_results <- t.test(aggregate(ctr ~ user_id + group, data=users, mean)$ctr ~
aggregate(ctr ~ user_id + group, data=users, mean)$group)
3.2 指标稀释效应（Dilution Effect）
当分析单元大于分流单元时会出现指标稀释。在某社交App的案例中：
- 分流单元：单个好友推荐（Recommendation-Level）
- 分析单元：用户级转化率（User-Level）
导致推荐算法改进的效果被非实验好友的交互行为稀释。解决方案包括： - 使用精准匹配指标（如只计算实验推荐好友的互动）
- 采用增量模型（Incrementality Model）进行效果估计
3.3 时间维度的影响
分析单元的时间粒度选择同样关键。在订阅制产品的实验中，我们发现：
- 按日分析：波动过大（±15%）
- 按周分析：稳定可解释（±5%）
- 按月分析：可能错过早期信号
我们的经验法则是：选择能覆盖用户完整决策周期的最小时间单位。对于电商购买行为，通常需要7-14天的观察期。
4. 工业级实践中的特殊案例处理
4.1 网络效应（Network Effect）的干扰
当实验单元之间存在社交关系时，传统分流方法会失效。我们在社交游戏中的解决方案是：
- 基于社交图谱进行集群抽样（Cluster Sampling）
- 使用边缘实验（Edge-Level Experiment）设计
- 采用Hashed Network ID确保一致性
java复制// 网络集群分桶示例
public String getNetworkBucket(String userId) {
String networkId = getUserNetworkHash(userId);
return Math.abs(networkId.hashCode() % 100) < 50 ? "control" : "treatment";
}
4.2 小流量实验的单元调整
当实验流量低于5%时，可能需要调整单元选择策略：
- 扩大单元粒度（如从Product-Level改为Category-Level）
- 延长实验周期（获取足够样本量）
- 使用序贯检验（Sequential Testing）方法
在某金融产品的风控实验中，我们将分流单元从"单次交易"调整为"用户日累计交易"，使所需样本量减少60%同时保持统计功效。
4.3 跨平台实验的单元一致性
对于多端产品，必须建立统一的单元体系。我们的三端一致方案：
- 优先使用Account ID作为核心单元
- 设备ID作为fallback方案
- 通过ID-Mapping表解决匹配问题
- 在服务端统一实现分流逻辑
这套方案在内容平台的跨端推荐实验中，将指标一致性从72%提升到了94%。
5. 监控与诊断：如何验证单元选择合理性
5.1 AA测试验证法
在正式实验前，我们必做AA测试：
- 用相同单元定义将流量分为A/A两组
- 比较核心指标的差异
- 验证p-value分布是否均匀
- 检查指标差异的置信区间
某次AA测试暴露的问题：当使用Session ID作为单元时，转化率的p-value<0.01的比例达到8%（预期5%），说明存在隐藏的依赖性。
5.2 敏感性分析框架
我们开发的诊断方法包括：
- 单元粒度测试：比较不同层级分析结果
- 时间切片分析：检查效果随时间变化
- 交叉验证：用不同随机种子重复实验
python复制# 敏感性分析示例
def run_sensitivity_analysis(data, unit_levels):
results = {}
for unit in unit_levels:
df = aggregate_by_unit(data, unit)
effect_size = calculate_effect(df)
results[unit] = {
'effect': effect_size,
'ci': calculate_confidence_interval(df)
}
return results
5.3 经验判断指标
在实践中总结的启发式规则：
- 用户级指标的日波动率应<5%（成熟产品）
- 会话级实验的持续时间不宜超过2周
- 当不同单元分析结果差异>20%时需警惕
在最近一年的实验中，这套规则帮我们提前识别了83%的单元定义问题。