业务侧-到底应该怎么做A/Btest

A/Btest是什么

A/Btest是在产品正式发版之前，设计两个或更多不同的产品方案，将用户和流量分组，保证用户分组的合理性的情况下，让用户看到不同的产品界面，收集用户的真实反馈，帮助产品决策最优方案。

A/Btest的重点和特点

重点：

1. 用户抽样分组的合理性
2. 流量分配的合理性

特点：

1. 结论可信度高：
   A/B测试在正式发版之前，对产品方案进行验证，少量的样本量和实际数据来推广到全部流量，相对于直接正式发版，预测发版结果来说，更具有可信度。

2. 可并行：
   A/B测试是将两个甚至多个方案同时进行检验，保证每个版本所处环境一样的情况下，测试方案的时间也相同。避免了因时间不同产生的周期性差异，也节省了验证时间。

A/Btest怎么做

PS:A/Btest需要有一定的流量基础，否则将流量分配后，每个分组得到的流量过小，不能得到相对准确的结论

实验分组

1. 用户分组
   1）基于设备号或用户ID分组，根据IP地址的奇偶性
   2）可重叠分层分桶方法，根据固定的hash函数对用户唯一标识进行取模、分桶
   将流量分成可重叠的多个层。因为很多类实验从修改的系统参数到观察的产品指标都是不相关的，完全可以将实验分成互相独立的多个层。例如 UI 层、推荐算法层、广告算法层，或者开屏、首页、购物车、结算页等。

   单单分层还不够，在每个层中需要使用不同的随机分桶算法，保证流量在不同层中是正交的。也就是说，一个用户在每个层中应该分到哪个桶里，是独立不相关的。具体来说，在上一层 001 桶的所有用户，理论上应该均匀地随机分布在下一层的 1000 个桶中。

   通过可重叠的分层分桶方法，一份流量通过 N 个层可以同时中 N 个实验，而且实验之间相互不干扰，能显著提升流量利用率。

   从实操上来说，我们通常采取下面的方法：

   首先，确定 Layer，确定请求 Tag。例如从 UserID，DeviceID、CookieID、手机号 中选一个，支持匿名流量的，一般会选用 DeviceID 或者 IMSI 等作为请求 Tag。

   然后，选一个你喜欢的 Hash 函数，尽量选个使用方便、随机性更强的；

   最后，通过 Hash(Layer, Tag) % 1000 确定每层分桶。如果 Hash 函数支持 seed，那么使用 Layer 作为 seed，否则作为 SALT，即将 “Layer+Tag” 作为输入参数

检验

标准：

1. 无偏性：
   假设在1%流量上某功能可以提高10%的点击率，那么在全量上也应该大约提高10%。
2. 低方差：
   方差越小，可靠性越高。

假设检验，建立原假设和备择假设：
H0是要拒绝的假设
H1是我们想要的假设

由于是两个样本显著性检验，数据量较大，一般使用z检验
$z=\frac{{\lambda }_b-{\lambda }_a}{\sqrt[2]{\frac{{\sigma }_b^2}{N}+\frac{{\sigma }_a^2}{N}}}$

都是业务沉淀获得的先验数据，或是先做一次测试，对这些值进行估计。

最后根据显著性水平，做出结论。

如果得不到显著的结论怎么办

原因：

1. 数据量不够，实验时间不足

2. 实验结论就是如此。那就需要具体分析原因，重新优化实验方案。