在我的业务线平时应用A/B的场景：A大多是已经在线的一个产品，而B是一个我们将要上线的另一版本的产品(有可能是改进也有可能是推倒重来的)，因为直接通过B去替换A可能用户一下子接收不了，所以我们会切部分用户出来用B版本，上线一段时间后，收集用户的反馈，再去调整，逐步去替换使用A的用户，这样做能让用户更平滑的接收。别小看这个过程，其实有很多策略可讲究了。说说我的真实经历。

第一种方案相对比较保守或者说慎重，因为用户不能回到原来熟悉的页面中去使用，特别是在后台(执行任务为主)一旦用户有比较紧急和重要的任务要做(比如编辑产品、发货、回复询盘)，会非常影响他的效率，从而直接带来一些不理性的反馈。好处：如果产品的改版是方向性的(就是商业决策上一定要这样去改了)，那通过这种方案一步步切流量，整个过程还需要和用户沟通解释，就能有个较平滑的过渡，比如网站首页的改版、SKU项目。

第二种方案就比较开放，因为用户有【返回旧版】的入口，用的不爽可以回去，而且被测试的用户基数较大，这样得到的反馈相对来说更有定量的价值，容易发现同类度比较多的问题，相对来说反馈内容也比较理性充实，我在群里、网上、上门跟用户聊的时候他们大多都说出对于不爽的很多细节。

当然这两种方案都基于一个很重要的前提，改版前做好功课：解决的问题和用户期望匹配度要高，准，而且第二种尤其。写到这里大家应该能看出我最终选择了哪种方案做了【AE卖家后台首页改版】。

对了，第二种方案还能给我们一个很重要的结果指标，就是用户在A/B版本的存留人数，再来看个当时【AE卖家后台首页改版】review数据图。

此次使用A/Btest的进行测试，新旧版各50%的用户，在新旧版头部布有切换按钮，用户在下次登录ME时会自动进入上次退出地的ME版本中。

新版由于链接数上有所简化，所以PV对比上会略低，而新版Session在近一周有所超越旧版的迹象。

通过存留比能很好的反映用户最终的接受度，同时也是作为判断产品是达到足够替换旧版的一个重要指标之一。

这里再提一下对于改版类的A/B测试还有一大利器就是热点分布图，基本能很直观的表现出用户的焦点功能能否在一屏内看到，操作到，尽量少的需要滚动。

当然A/B测试还有很多种用法和分步实施方案，测试出的结果也会有很多有意思的解读，项目做的多了，思考的多，遇到的问题多了，都能感受的到，以上只是举了个简单的例子。

　　A/B测试和PD

写到这个标题，是我想到了很多时候UED在PD沟通方案出现分歧时，最终会提出做A/B测试，这本身没错。但我在和PD们聊过这个问题时，他们有时候会有一种较负面的感觉：这么小的一个需求还要做A/B哪有资源和时间，感觉这成了阻碍他们项目进度的一个绊脚石。可能我们只是想证明自己更对，并没有那种意思，但如果对方有了这种感受其实很不利于以后的合作的。

我的一点点看法就是，如果项目是很重要和关键的改动，我们尽早提出该项目需要做A/B测试(PD也会比较慎重的，最好你还能提出如何去做A/B测试的建议方案更nice)，规划到项目整体资源中去，而不是在项目KICKOFF后，大家都完成了评估开始执行了再来提。如果是些小改动影响不大，方案一直纠结不下，哪我建议我们大度点让让TA们吧，最后真的他们错了，补救的成本也不会太高的。这点是我们需要注意下的。

以上只是个人心得，虽不能适用大家的工作场景，但举一反三，希望带给大家一点点思考，就算没浪费大家读到这里了。