探究灰度测试（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，友盟，百度统计等工具）