标签归档:数据分析

关于A/B Test的外传

abtestA/B测试的作用大家都知道,就不多说了,在这里写写我在平时工作中应用心得。

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

之前做【AE卖家后台首页改版】的时候有两种方案做A/B测试,第一种:直接切20%的流量体验新版后台(根据帐号数随机切20%的用户登录就跳转到新版),不提供【返回旧版】入口,另一种切50%的流量让用户体验新版后台,但是要提供【返回旧版】的入口。

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

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

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

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

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

流量对比图

 

 

 

 

 

 

 

总的来说新版上线后,用户随着一个时间段的体验和适应,新旧版的的存留上是五五开。

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

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

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

ABTEST RESULT

当然每个产品情况不同不一定是看类似的指标数据,但在做A/B前梳理清楚上线后通过哪些数据来衡量是非常重要的,衡量哪些指标,我们UED也最好能主动和PD一起去讨论,毕竟有些指标数据能指导、影响我们的方案和看问题视角。

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

A/B测试和PD

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

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

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