电商与内容平台的A/B测试平台搭建

CH-40-05-015·约 18 分钟·AI商业与行业解决方案·更新 2026-08-14

「回味轩」连锁餐厅的老板想做一道新菜，但他不敢直接把菜单全换掉——万一口味不对，老顾客全跑光了。于是主厨想了个办法：让一半门店试推新菜，另一半保持原样，一周后对比两边的翻台率和好评率，用数据说话。这个办法听起来简单，真正落地时却要解决一连串问题：顾客怎么公平地分到两组？几道新菜同时测试会不会互相干扰？好评率高百分之几才算真的有提升？于是，他们建了一间「中央试味实验室」，把所有新菜的验证流程标准化。这就是电商与内容平台的A/B测试平台在做的事——把「对比实验」从一次性的小聪明，升级为可规模化的基础设施，让推荐算法、页面改版、定价策略都在这套体系里被科学地检验。

岗位关联

掌握A/B测试平台的设计与管理，是AI从业者把算法改进转化为业务增长的关键能力——它能让你用科学方法证明模型价值，避免「拍脑袋决策」。

可视化演示
平台架构设计
实验管理流程
指标对接体系
分层分流模型
互斥实验策略
正交实验设计
效果评估决策
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

动态演示电商与内容平台的A/B测试平的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

电商与内容平台的A/B测试平：AB测试 A/B测试平台概述 A/B测试平台原理核心机制可视化电商与内容平台的A/B测试平整体架构与关键组件

平台架构设计

回味轩的中央试味厨房划分了四个工位：入口处有师傅给顾客做抽签分组（分流层）、厨房白板记录每道菜在哪个窗口试吃（实验层）、餐位下装着感应器记录用餐时长和光盘程度（数据层）、后厨角落坐着统计师傅核算各组满意度（分析层）。四个工位各司其职，整套流程才能转起来。

电商与内容平台的A/B测试平台同样分为四层。实验层是产品经理和算法工程师的入口，负责配置实验名、流量比例、评估指标；分流层是核心引擎，决定每个用户进入哪个实验组；数据层负责埋点采集用户行为；分析层负责样本量预估、显著性检验和结论输出。四层缺一不可，就像试味厨房少了一个工位，试菜结论就会失真。

设计平台时第一步是想清楚样本量。这就好比试吃新菜前要先算好请多少位顾客——请少了，顾客评价的波动会掩盖菜品的真实水平；请多了，浪费成本还拖慢决策。

回到厨房的比喻：主厨不会凭感觉说「叫几十个人来尝尝就行」，而是先拿公式算出需要约3万人试吃，才能放心下结论。平台架构的第一块基石，就是把这种「科学计算」变成每个实验的默认动作。

n = \displaystyle \frac{(z_{\alpha/2} + z_{\beta})^2 \times 2p(1-p)}{\delta^2}

这个公式告诉你：要检测出多大的效果差异，至少需要多少样本量。「差异越小，需要的食客越多」。

显著性水平分位数$z_{\alpha/2}$ 是显著性水平对应的标准正态分位数，通常α取0.05时约为1.96，代表「允许误判的概率上限」。
$z_{\alpha/2} = 1.96 \ (\alpha = 0.05)$
统计功效分位数$z_{\beta}$ 是统计功效对应的分位数，通常功效取0.8时约为0.84，代表「真实差异能被检测出来的概率」。
$z_{\beta} = 0.84 \ (\text{功效}=0.8)$
基线方差$p(1-p)$ 是对照组转化率的方差，转化率越接近50%，不确定性越大。
$p(1-p) \approx 0.05 \times 0.95 = 0.0475$
最小可检测效果$\delta$ 是希望检测出的最小绝对提升幅度，比如从5%提升到5.5%，则δ=0.005。
$\delta = |p_{\text{实验}} - p_{\text{对照}}| = 0.005$
汇总公式分子是两个分位数之和的平方乘以两倍方差，分母是效果量的平方；效果量越小，所需样本量爆炸式增长。
$n = \frac{(1.96 + 0.84)^2 \times 2 \times 0.0475}{0.005^2} \approx 29768$

实验管理流程

试味厨房墙上贴着一张「试菜流程卡」。每道新菜必须走四步：先填写试菜申请单，写清测试目标和评价标准；再由前台领班安排试吃批次和人数；试吃期间值班大厨每天检查有没有顾客抱怨等位变久；试吃期结束后主厨签字决定转正或撤下。任何一步没走完，菜就不能上正式菜单。

A/B测试平台把这张流程卡数字化了。立项创建阶段，实验负责人要写下假设：新推荐算法能让点击率提升10%，并且选定核心指标和护栏指标。流量分配阶段，平台根据样本量公式计算需要多少流量，把用户按比例划入实验组和对照组，通常实验组流量占比为10%到50%。

运行监控阶段，平台实时检查样本量是否达标、两组用户特征是否均衡、护栏指标是否告警。结束下线阶段，实验结论归档，实验代码从线上摘除，避免长期运行污染后续实验。

流程卡之所以贴在墙上，是因为主厨深知：不按流程走的试菜，要么结论不可信，要么偷偷跑几个月没人管，最后还占着厨房资源。实验管理流程的价值，正是让每一个实验都有始有终、可追溯、可清理。

r = \displaystyle \frac{n}{N}

实验流量占比等于实验所需样本量除以平台每日可用流量。像试味厨房安排「今晚请多少桌客人试菜」一样。

所需样本量$n$ 是前面样本量公式算出的总样本量，包含对照组和实验组。
$n = 30000$
平台总流量$N$ 是平台当前的日活跃用户数，是流量池的总大小。
$N = 200000$
流量占比$r$ 是实验需要拿走的流量比例，剩余流量留给其他实验和正常业务。
$r = \frac{30000}{200000} = 15\%$

指标对接体系

评价新菜不能只看「光盘率」——还要看顾客吃完有没有皱眉、上菜速度有没有被拖累。试味厨房给每道菜配了一张双面评价表：正面是核心指标（光盘率、复购意愿），背面是护栏指标（差评数、出餐延迟）。正面决定这道菜能不能转正，背面决定转正后会不会砸了招牌。

A/B测试平台的指标体系同样分两面。核心指标直接反映实验目标，比如电商场景的转化率、客单价、GMV，内容平台的点击率、停留时长、次日留存。护栏指标是不希望被实验破坏的底线，比如页面延迟率、崩溃率、投诉率——推荐算法改版哪怕提升了点击率，如果造成页面卡顿，也不能上线。

指标要落到数据上，依赖事件上报。平台通过埋点采集曝光、点击、下单等行为事件，上报链路需要幂等去重，确保同一事件不重复计数。结果计算阶段，平台按实验维度聚合指标，常用的衡量指标是相对提升率。

这张双面评价表让试味厨房从「拍脑袋说好吃」走向「用数据说值得」。双面指标的设计也提醒所有实验者：核心指标的上涨如果建立在损害用户体验之上，终究会反噬业务。

\text{lift} = \displaystyle \frac{\bar{x}_B - \bar{x}_A}{\bar{x}_A}

提升率是实验组相对对照组的相对涨幅。好比实验组光盘率55%、对照组50%，提升率就是10%。

对照组均值$\bar{x}_A$ 是对照组的指标平均值，代表现状水平。
$\bar{x}_A = 0.50$
实验组均值$\bar{x}_B$ 是实验组的指标平均值，代表改动后的水平。
$\bar{x}_B = 0.55$
相对提升两者差值除以对照组均值，得到相对提升幅度，常用于业务汇报。
$\text{lift} = \frac{0.55 - 0.50}{0.50} = 10\%$

分层分流模型

试味厨房门口有一台摇号机。每位顾客领到的号码由「日期+桌号+姓名」混合计算得出，保证随机又稳定——同一位顾客下次再来，拿到的号码不变。这样前后两次试吃的反馈才能对应到同一个人身上。

分层分流模型正是这台摇号机的工程化实现。平台将全部流量划分为若干层，每个层拥有独立的「摇号空间」（分桶空间）。同一用户在不同层中拿到的桶号互不关联，就像同一位客人在不同门店拿到的试吃号各不相同。

用户分桶通常采用一致性哈希算法：对用户ID拼接层标识后做哈希取模。这样同一用户在同一层的桶号在整个实验周期内保持稳定，不会因为实验配置变化而重新分桶，保证了实验组的纯净性。

摇号机的设计保证了公平和稳定。分层分流模型让平台能同时服务几十个实验，每个实验拿到的都是「干净的样本」——这正是数据驱动决策可信的前提。

\text{bucket} = \displaystyle \text{hash}(\text{user\_id} + \text{layer\_salt}) \bmod k

把用户ID和层编号拼在一起做哈希，再对总桶数取模。像摇号机把不同信息混在一起后摇出一个号码。

哈希函数$\text{hash}(\cdot)$ 将任意长度的字符串映射为一个整数，比如 MD5 或 MurmurHash。
$\text{hash}(\text{user\_id}) = 8612345$
层盐值$\text{layer\_salt}$ 是每个层独有的字符串，确保同一用户在不同层得到不同桶号。
$\text{layer\_salt} = \text{"layer\_3"}$
取模分桶$\bmod k$ 将哈希值映射到 0 到 k-1 的桶号，k 是层内总桶数。
$\text{bucket} = 8612345 \bmod 100 = 45$

互斥实验策略

同一桌客人不能同时试吃两道都在测试的菜。如果一道菜测口味、一道菜测份量，客人吃完只说「整体不错」，你根本分辨不出哪道菜的哪个改动起了作用。所以餐厅规定：同一时段、同一张餐桌上，只能测一道测试菜。

互斥实验策略就是这条规定在平台中的体现。当两个实验改动的是同一个用户流程（比如同时改商品详情页的按钮颜色和文案，或者同时改推荐算法的两处逻辑），它们就不能让同一批用户同时进入，否则效果互相混淆，算不清功劳归谁。

实施互斥实验的方法是把这些实验放进同一个「互斥域」。互斥域拥有独立的流量池，域内划分多个子空间，每个实验占用其中一块。用户进入互斥域时，只能被分配到其中一个实验，保证用户集合不重叠。

互斥策略牺牲了一部分并行能力，换来的是干净的因果推断。就像餐厅宁愿让一桌客人只专注评价一道菜，也不愿意为了效率让他们同时试两道菜、最后什么都说不清。

\text{bucket} = \displaystyle \text{hash}(\text{user\_id}) \bmod N

在互斥域内，用户先被哈希到总桶空间，再按实验预定的桶区间划分归属。像一张餐桌上，客人要么试菜A要么试菜B。

总桶空间$N$ 是互斥域的全部桶数，比如100个桶。
$N = 100$
用户分桶对用户ID哈希后取模，得到该用户在互斥域内唯一的桶号。
$\text{hash}(\text{user\_id}) \bmod 100 = 72$
桶区间划分互斥域把桶号区间划分给不同实验，比如0-49号桶给实验A，50-99号桶给实验B，用户落进哪个区间就参加哪个实验。
$72 \in [50, 99] \Rightarrow \text{分配至实验B}$

正交实验设计

如果换一个场景：A门店测试新意面，B门店测试新甜品——两家店互不干扰，完全可以同时进行。这就是正交实验的思路：改动发生在不同环节、不同模块时，实验可以并行不悖。

正交实验让同一用户可以同时参与多个不同层的实验。因为每层使用不同的哈希盐值，同一用户在第1层分进实验A的实验组，在第2层可能分进实验B的对照组——两组实验互不影响，因为它们衡量的是不同环节的指标变化。

实现正交的关键是「层间独立性」。每层用不同的盐值做哈希分桶，保证用户在各层的分布彼此正交。实验平台通常会预留多个正交层：UI 层、推荐层、定价层、推送层等，每层内部再划分互斥域。

正交实验让平台从「一次只测一个」进化到「同时测几十个」。回到餐厅的比喻：互斥是让同一桌客人只评价一道菜，正交是让不同门店的试菜同时进行——两者配合，实验效率和科学性兼得。

\text{bucket}_j = \displaystyle \text{hash}(\text{user\_id} + \text{salt}_j) \bmod k

第 j 层用专属盐值做哈希分桶。同一用户在不同层拿到的桶号互不相关，从而可以同时参加多个实验。

层标识$\text{salt}_j$ 是第 j 层的专属盐值，保证层间分桶相互独立。
$\text{salt}_1 = \text{"rec\_layer"}, \ \text{salt}_2 = \text{"price\_layer"}$
层内分桶第 j 层的用户桶号由拼接盐值后的哈希取模得到。
$\text{bucket}_1 = \text{hash}(u + \text{"rec\_layer"}) \bmod 100 = 23$
跨层独立性同一用户在另一层的桶号与第一层无相关性。
$\text{bucket}_2 = \text{hash}(u + \text{"price\_layer"}) \bmod 100 = 68$

效果评估决策

试吃期结束，统计师傅拿出计算器：实验组平均分4.3，对照组4.1，看起来涨了。但他知道均值背后有波动——万一只是这批客人心情好呢？他会算这个差异是不是「随机误差」。如果差异小到可能是运气，就不能转正；只有通过显著性检验，才敢签字全量推广。

效果评估决策环节回答三件事：提升是否显著、提升幅度有多大、能否放心发布。显著性检验用 t 检验判断两组差异是否由随机波动造成；置信区间给出提升幅度的可能范围；决策规则结合核心指标和护栏指标给出结论。

即使显著提升，主厨也不会一次性全量推新菜——他会先在1%的店推一周，观察无异常再扩到10%、50%、100%，这就是灰度发布。效果评估不只是算数字，更是一套「小步快跑、有据可依」的决策文化。

t = \displaystyle \frac{\bar{x}_1 - \bar{x}_2}{\sqrt{\frac{s_1^2}{n_1} + \frac{s_2^2}{n_2}}}

t统计量衡量两组均值差异相对标准误的倍数。如果 |t| 大于1.96，说明差异显著，不是运气好。

分子均值差$\bar{x}_1 - \bar{x}_2$ 是两组均值的绝对差值。
$\bar{x}_1 - \bar{x}_2 = 0.013$
分母标准误$\sqrt{s_1^2/n_1 + s_2^2/n_2}$ 是差值波动幅度的估计。
$\sqrt{\frac{0.048}{5000} + \frac{0.049}{5000}} = 0.0044$
t统计量两者比值，衡量差异相对波动的显著性。
$t = \frac{0.013}{0.0044} \approx 2.95$
判断标准|t| 大于1.96则差异在95%置信水平下显著。
$|2.95| > 1.96 \Rightarrow \text{显著}$

AI 应用场景

电商首页推荐算法改版

阶段：模型上线前验证

解决的问题：排序算法调整后，离线指标（如 AUC）提升不代表线上转化率一定提升。传统方式直接全量上线，一旦效果变差，损失巨大且无法归因。

具体案例：某电商平台将首页推荐算法从 LR 升级为 DeepFM，平台为这次改版创建了A/B实验：5%流量进入新算法实验组，5%留在旧算法对照组。两周后统计发现，新算法点击率提升8%、GMV提升3%，且页面延迟率无恶化；运行一周稳定后，灰度放量至100%全量上线。

内容平台信息流交互改版

阶段：产品体验优化

解决的问题：信息流从双列改为单列，涉及UI布局、滚动加载、曝光计数等多个环节。如果与其他实验同时改版，指标波动难以归因。

具体案例：某短视频平台将「双列点击进详情」改为「单列沉浸式播放」。改版实验与「推荐算法阈值调整」实验放入互斥域，避免同一用户同时体验两个变更。实验组人均时长提升12%，但广告点击率下降5%，护栏指标触发告警；经权衡后决定回滚本次改版。

跨境电商多市场定价策略

阶段：策略分层验证

解决的问题：不同国家用户的消费力差异大，统一调价可能影响部分市场。传统做法是各市场独立决策，重复建设成本高。

具体案例：某跨境电商平台利用正交分层，把定价实验放在独立的「定价层」，同时让推荐位实验和运费策略实验在其他层并行。定价层里，东南亚市场测试「满减改折扣」，欧洲市场测试「运费门槛调整」，两者互不干扰，一周内同时得出有效结论。

Python 演示

python43 行

import mathimport random  def hash_bucket(user_id, layer_salt, bucket_num=100):    """将用户ID与层标识拼接后哈希取模，得到0到bucket_num-1的桶号"""    key = f"{user_id}_{layer_salt}"    return sum(key.encode("utf-8")) % bucket_num  def assign_group(user_id, exp_layer, split_ratio=0.5, bucket_num=100):    """根据桶号比例决定用户进入实验组还是对照组"""    bucket = hash_bucket(user_id, exp_layer, bucket_num)    return "treatment" if bucket / bucket_num < split_ratio else "control"  def run_experiment(n, base_rate, lift):    """模拟一次A/B实验，返回两组转化率与t统计量"""    random.seed(42)    control = [0] * n    treatment = [0] * n    for i in range(n):        if random.random() < base_rate:            control[i] = 1        if random.random() < base_rate * (1 + lift):            treatment[i] = 1    c_mean = sum(control) / n    t_mean = sum(treatment) / n    c_var = sum((x - c_mean) ** 2 for x in control) / (n - 1)    t_var = sum((x - t_mean) ** 2 for x in treatment) / (n - 1)    t_stat = (t_mean - c_mean) / math.sqrt(c_var / n + t_var / n)    return c_mean, t_mean, t_stat  if __name__ == "__main__":    N = 5000    base = 0.05    lift = 0.30    c_mean, t_mean, t = run_experiment(N, base, lift)    print(f"对照组转化率: {c_mean:.4f}")    print(f"实验组转化率: {t_mean:.4f}")    print(f"提升幅度: {(t_mean - c_mean) / c_mean * 100:.2f}%")    print(f"t统计量: {t:.4f} (|t|>1.96 则差异显著)")

目的：用 Python 模拟A/B测试平台的用户分桶和显著性检验流程，演示「哈希分桶 → 分配实验组 → 计算转化率 → t检验」的完整链路。

def hash_bucket(user_id, layer_salt, bucket_num=100):定义核心分桶函数，把用户ID和层标识哈希后映射到桶号。
key = f"{user_id}_{layer_salt}"拼接层标识，确保不同层的分桶互不相关，实现正交。
bucket / bucket_num < split_ratio按桶号比例划分实验组与对照组，50%流量进入实验组。
if random.random() < base_rate:模拟对照组用户是否发生转化，baseline以5%概率随机生成。
t_stat = (t_mean - c_mean) / math.sqrt(c_var / n + t_var / n)计算 t 统计量，判断两组差异是否显著。

常见误区

误区实验结束后直接比较两组转化率，谁高谁就赢，哪个高就上线哪个。

正解两组指标差异可能只是随机波动。必须做显著性检验（t检验或卡方检验），确认差异在统计意义上可靠。就像试菜时一组4.1分、一组4.3分，如果不算波动，可能只是这组客人恰好心情好多打了分。还要同时看置信区间和护栏指标。

为何常见：直觉上「高就是好」最省事，但随机波动是客观存在的，缺少统计思维就容易得出错误结论。

误区平台支持多个实验并行，所以把改动同一模块的多个实验同时放开，数据各算各的就行。

正解改动同一流程的实验如果共用流量，会互相污染。比如同时改商品详情页的按钮和文案，用户看到的是「组合效果」，无法归因到单一改动。正确做法是把相关实验放入互斥域，让用户只进其中一个实验。

为何常见：平台交互上实验是各自独立的，容易让人忽略业务层面的相互影响；工程师习惯从代码角度思考，而不是用户流程角度。

误区实验跑了足够多天、收集了几百万样本，结果一定准确可靠。

正解样本量大不等于样本质量高。如果分流不均匀（比如某组的用户大部分来自晚高峰时段）、上报链路有丢数、或者实验期间发生了大促活动，样本再多结论也失真。平台需要做样本均衡性检查（SRM），并尽量控制实验期间的外部干扰。

为何常见：「大数据」三个字给人的安全感超出了它实际能保障的范围，人们容易忽略数据质量比数量先决。

误区A/B测试是前端交互优化的小工具，算法层的大改动没法用它验证。

正解A/B测试恰恰是推荐算法、搜索排序、定价策略等核心模型上线前最重要的验证手段。算法工程师通过实验对比新旧模型的线上效果，用数据决定是否灰度放量。试味实验室里既测得了「摆盘方式」，也测得了「核心配方」。

为何常见：日常接触到的案例多是页面样式类实验，导致大家低估了它作为「模型评估基础设施」的价值。

面试题

Q1. A/B测试平台中「互斥实验」的核心目的是什么？

单选题 · easy

A.防止两个实验使用同一套代码
B.避免同一用户同时进入多个互相影响的实验← 正确答案
C.降低平台服务器负载压力
D.减少数据存储的空间开销

答案：B。互斥实验的核心是流量隔离，避免同一用户同时体验多个改动，导致无法归因。这与代码复用、服务器负载、存储空间无关。就像同一桌客人不能同时试吃两道测试菜。

Q2. 正交实验设计最主要的优势是什么？

单选题 · mid

A.实验过程不需要随机抽样
B.同一用户可参与多个独立实验互不干扰← 正确答案
C.实验结果一定达到统计显著
D.无需计算实验所需样本量

答案：B。正交实验通过层间独立分桶，让同一用户能在不同层参与不同实验，大幅提升实验并行容量。它不能免除随机抽样，也不保证显著，样本量计算依然必要。

Q3. 实验样本量计算最主要的决定因素是？

单选题 · easy

A.团队研发预算的规模
B.希望检测出的最小提升幅度← 正确答案
C.服务器集群的机器数量
D.产品经理的经验判断

答案：B。样本量公式中，最小可检测效果δ越小，所需样本量越大（平方关系）。预算、服务器、经验都不能替代统计规律——想测出「细微差别」，就要备足「试吃人数」。

Q4. 对照组转化率为5%，希望检测出10%的相对提升，显著性水平0.05，功效0.8，公式中δ应取多少？

单选题 · hard

A.0.050
B.0.005← 正确答案
C.0.500
D.0.010

答案：B。10%相对提升 = 从5%提升到5.5%，绝对差值为0.5个百分点，即δ=0.005。混淆绝对百分比和相对百分比是常见错误——若把0.05代入，样本量会少算约100倍。

Q5. 分层分流模型中，用户分桶通常采用什么方法？

单选题 · easy

A.按用户名拼音字母排序
B.对用户ID哈希后取模← 正确答案
C.按用户注册时间分组
D.使用随机数每次重新洗牌

答案：B。一致性哈希取模能保证同一用户在实验期间桶号稳定，又不依赖业务特征。按拼音或注册时间会产生偏斜样本；每次随机洗牌会导致用户实验中换组，污染结果。

Q6. 两个实验放在同一互斥域内共享流量池，这意味着什么？

单选题 · mid

A.用户只会进入其中任意一个实验← 正确答案
B.两个实验覆盖的用户数翻倍
C.两个实验必须同时启动上线
D.两个实验共享同一个对照组

答案：A。互斥域把流量池按桶区间切块，用户落进哪块就只参加对应实验。互斥域不是增加用户数，也不要求同时上线，更不是共享对照组——每个实验有自己的对照和实验组。

Q7. 下面哪些指标适合作为实验平台的「护栏指标」？

多选题 · mid

A.页面加载延迟率← 正确答案
B.用户差评投诉率← 正确答案
C.人均商品浏览时长← 正确答案
D.实验代码上线耗时

答案：ABC。护栏指标是防止实验损害业务底线的「安全网」，包括性能（延迟率）、体验（投诉率）、黏性（浏览时长）。代码上线耗时是工程效率指标，不是业务护栏指标。

Q8. 关于A/B测试的显著性检验，下列说法正确的有？

多选题 · hard

A.|t|>1.96时，在5%显著性水平下差异显著← 正确答案
B.p值越小说明效果量一定越大
C.显著性水平α是「无差异却误判为有差异」的概率上限← 正确答案
D.样本量足够大时，很小的差异也能检验出显著← 正确答案

答案：ACD。p值衡量证据强度而非效果量大小——样本量很大时，微小的实际差异也能显著。α控制的是第一类错误率。t检验的临界值1.96对应95%置信水平。

Q9. 实验运行中出现样本量比例失衡（SRM），最可能的原因是什么？

单选题 · mid

A.对照组和实验组样本量设计不同
B.分流失真导致样本偏斜← 正确答案
C.实验组转化率远高于对照组
D.数据上报链路全部中断

答案：B。SRM表示实际分流比例偏离预期。常见原因包括：某些设备/平台被过滤后集中进入某组、实验期间有跳转拦截、用户重复进入。转化率高低与SRM无直接关系。

Q10. 一个实验中对照组转化率5%，要测出0.5个百分点的绝对提升，95%置信度、80%功效，需要约多少样本量？

单选题 · hard

A.约500人
B.约5000人
C.约30000人← 正确答案
D.约100000人

答案：C。代入公式 n=(1.96+0.84)²×2×0.0475/0.005²≈29768，约3万。这种「提升越小、样本越大」的规律，常被低估——很多实验跑了一周发现不显著，其实是样本量根本不够。