探究灰度测试（A/B Testing）

一段小插曲

前段时间产品改版，产品经理为了改进用户体验，就决定改版用户的注册流程页面，但又怕身份证注册验证接口不稳定（第三方的身份证校验）。

于是产品经理就让我通过随机概率去控制注册流程，让一部分用户使用身份证注册，让一部分用户使用手机号注册。当时我听这种需求确实有点懵，总感觉不好做，产品经理就说了句，先用灰

度测试一下，听完我就学到了这个“灰度测试”术语，网上研究了一下这个术语，顺便把这个需求实现。

概念

什么是灰度测试（发布）

测试同一个产品发布，随机让一部分用户会使用新版，一部分用户仍然使用旧版。比如：A组用户使用新版，B组用户使用旧版。

什么是A/B Testing

测试同一个产品页面，不同的组件设计风格。（颜色，大小，形状）比如：A组用户看到购买按钮是红色的，B组用户看到购买按钮是橙色的。

什么是Split Test

测试同一个产品页面，不同的布局设计风格。（左右布局，上下布局）比如：A组用户会在首页顶部菜单看到注册按钮，B组用户会在首页banner位看到注册按钮。

PS：灰度测试是国内IT行业的说法，国外并没有这么一说。某些业界人员认为灰度测试与A/B Testing是不同的概念，认为灰度测试是从技术上看产品质量问题，A/B Testing与Split Test是从市场上看用户体验问题。A/B Testing与Split Test本质是相似的，在我看来，灰度测试与A/B Testing实施方案是一样的，所以没必要去区分灰度测试、A/B Testing、Split Test。

灰度测试≈A/B Testing（两项测试）≈A/B/N Testing（多项测试）≈Multivariate Testing（多项测试）≈Split Test（分类测试）

目的

为什么要进行灰度测试（A/B Testing）

1.从用户体验角度来讲，可以分析用户数据，改进用户体验。

2.从产品质量角度来讲，可以保证产品顺利迭代，控制产品影响范围。

实施

如何进行AB Testing

第一步：制定A/B Testing的用例。

考虑用户界面技术实现。

考虑预期用户界面体验效果。

第二步：确定A/B Testing的用户。

1.没有用户ID关联的

根据用户的IP区域信息来测试。

根据用户的设备信息来测试。

通过消息推送/提示窗口通知用户测试。

2.有用户ID关联的

根据用户的活跃度来测试。

通过邮件/短信通知用户来测试。

第三步：控制A/B Testing 周期。

周期最好控制在一个月内，周期越长，A/B Testing的结果就容易受到污染。（原因请看后面）

第四步：收集数据并分析。

不要片面分析结果，进行产品技术分析，数据分析，互动分析（比如社交群反馈）。

PS：互动分析由为重要，能直接反馈用户对产品的看法，请不要忽视社交群反馈意见。

问题

A/B Testing结果是否准确？

不准确，A/B Testing结果会存在一定的误差，A/B Testing结果误差产生有以下几个主要原因。

1.随机访问。

随机访问意味着任何用户访问该网站都有相同的概率被选择进入新版（另一个用户界面），从而看到网站的A/B Testing的变化。从技术的角度来讲，无论是前端，还是后端控制概率A/B，往往都是基于cookie去控制这个A/B测试的变化。假设用户更换电脑，更换浏览器，清除cookie，那A/B Testing的结果就不准确。

2.用户样本过少。

用户样本过少意味着产品测试覆盖率低，不容易发现产品问题。从技术的角度来讲，可能抽样的用户测试新功能都没有问题，结果全面推送给所有用户使用新功能就有可能出现一些产品问题（Bug），那A/B Testing的结果就不准确。

3. 网站营销活动。

网站营销活动意味着会提高网站的访问量，无论网站A/B Testing的变化如何，A 组用户界面与B 组用户界面的转化率都有较大的提升。从用户体验的角度来讲，看不出哪一组的用户界面转化率高，那A/B Testing的结果就不准确。

4.人为不可控的活动。

人为不可控的活动因素有很多，比如抽样的用户没时间去使用新功能或者不喜欢使用新功能，又或者同一台电脑或者浏览器给多人使用等不可控因素，那A/B Testing的结果就不准确。

总结

A/B Testing结果可以反馈产品质量问题，但不能准确反馈用户体验问题。（如果需要收集更多数据分析网站转化率，请配合第三方分析工具进行数据分析，比如Google Tag Manager，友盟，百度统计等工具）