A/B测试中最容易导致结果无效的三个错误

很多刚刚进行A/B测试的企业常常会把所有精力都放在假设的提出、试验的设计上,却完全忽略了A/B测试实施过程本身。试验本身的设计确实非常非常重要,我们需要提出可靠的假设并且设计出合理的各个版本。但是如果我们认为试验一旦启动之后就不再需要操心任何事情的话就大错特错了。进行AB测试的方法和分析结果的手段同样是非常重要的事情。下面就一起分享三个在这方面我们经常会遇见的错误。 错误1:我们的试验设计了过多的版本 有些人会觉得,如果我们设计的版本越多,就越能从中获取足够的信息,但真的是这样的么?其实并不是,设计过多的版本会让试验需要的流量变得更多,更重要的是,这样的设计会在两方面影响我们的结果。 首先,过多的版本会需要大量的流量,而这常常会使得试验的测试周期变长,甚至会超过一个月。过长的测试周期会带来一个问题,用户删除cookie的可能性增加了,删除了cookie的用户在系统看来就像是一个新的访客,但是实际上并不是,这对转换率会产生影响,使得结果不再可靠。 第二问题是,随着版本数的增加,测试结果的可靠性会下降。每一个版本都存在不可靠的可能性,随着版本数增加,整个结果的可靠性会呈指数增长。如果我们把单个版本的统计显著性要求设定在95%,那么两个优化版本的统计显著性就只能保证在91%了,五个优化版本就只有80%不到了。 在多个版本存在的A/B测试中,还有一种情况会使我们选择错误的胜出版本。在查看结果的时候,我们可能会直接选择转换率提升最多的版本,即便他们的统计显著性实际上是一致的。这样的做法是不对的,因为同样的统计显著性说明在下一次测试中,另一个版本可能就会胜出了。所以在选择胜出版本的时候,我们不仅仅需要比较各个优化版本的转换率,会需要比较他们的统计显著性。 错误2:在试验正在进行的时候修改试验配置 一旦我们开始了试验,就不能够再做任何改动了,必须确保试验至始至终地毫无变化地完成。千万不要想着去修改设置、目标、版本的变化等等。也不要去修改个版本之间的流量分配。 在试验正在进行的时候修改流量分配会导致试验数据的完整性受到破坏,这就是辛普森悖论。这个统计学上的悖论指的是,当我们观察几组数据时都能得到某个特征,然后我们合并这些数据集再去观察时,就再也看不到原先的特征了。下表给出了一个例子。 第一天流量[99%|1%] 第二天流量[50%|50%] 总计 原始版本 2000/99000 = 2.02% 500/50000 = 1.00% 2500/149000 = 1.68% 优化版本 23/1000 = 2.30% 600/50000 = 1.20% 623/51000 = 1.20% 从表中可以看到,我们在第一天试验之后我们调整了流量分配,同时第一天因为不确定因素(节日、天气等等)具有较好的转换。如果我们分别去观察每天的结果就会认为优化版本是有提升的。但是如果把结果合并再去观察,却发现转换率下降了,试验失败了。实际上,优化版本很可能就是提升了的。问题就在于我们调整了流量分配,使得数据权重发生了变化。只要我们不要在试验进行的过程中修改流量,就不会出现这样的问题了。 需要指出的是,虽然我们不能修改各个版本之间的流量分配,但是在试验级别上的流量分配的修改是没有问题的。利用试验级别的流量控制,我们可以在试验刚刚开始的时候只投入少量的流量,之后再逐渐增加流量来减少风险。 同样的道理,我们不能够修改目标、版本的修改。如果有多个目标,我们也不能够去修改主目标。 错误3:错误的结束时间和分段分析 有时候,我们一观察到统计显著性达到要求之后就结束了试验,这是不对的。统计显著性不应该被用来决定停止试验的时机。它只是告诉了我们优化版本和原始版本之间的差异性。所以我们不应该等待统计显著性达到要求,正确的做法应该是去计算需要的样本数量,当样本数量达到要求时我们就可以停止试验了。 在拿到试验结果之后,我们有的时候会对结果进行分段处理,分析不同的人群的数据,为个性化或者带受众的试验提供基础。分段分析的常常会出现两个问题。第一个问题是样本数量不足或者不对称,因为分段只会使用一部分数据。第二个问题类似多版本比较的问题,过多的分段也会带来统计显著性下降的问题,这会导致更多的数据需求。我们有很多办法来避免这两个问题,但是最容易也最正确的做法是创建一个带受众的试验。

A/B测试

A/B测试入门指南

什么是A/B测试? A/B测试(A/B Testing), 有时称为拆分测试 (Split Testing),就是比较两个版本的网页,以查看哪个更好。在同一时间向类似的访客显示一个页面的两个版本(A和B),转换率高的版本获胜! 网络上所有的网站都有共同的目的 – 这也是它们存在的原因: 电子商务网站希望访客购买产品 SaaS网络应用程序希望访客注册并转换为付费用户 新闻和媒体网站希望读者点击广告或注册付费订阅 每个商业网站都希望访客能够转化为目标客户,这个比率就是“转换率”。衡量版本(A或B)的优劣就是根据它们将访客转化为目标客户的比率。 为什么要进行A/B测试? A/B测试能够挖掘现有流量的最大价值。尽管获得流量的成本可能非常巨大,但增加转化的成本却很小。比如云眼A/B测试工具的小型企业SaaS版每月的起价仅为68元,这仅相当5到10个百度点击的费用。A/B测试的投资回报(ROI)是巨大的,因为着陆页或网站上的微小变化可能导致潜在客户生成,销售和收入大幅增加。   A/B测试能测什么? 几乎任何影响访客行为的网站都可以进行A/B测试。 标题 小标题 段落文本 认证 行为召唤(CTA, Call to Action)文字 行为召唤(CTA, Call to Action)按钮 链接 图片 折叠说明 社交评价 媒体报道 奖章和徽章  高级测试可以包括定价结构,销售促销,免费试用期,导航和UX体验,免费或付费交付等。     A/B测试和SEO 云眼在“AB测试影响SEO和搜索排名”吗博客文章中说明了A/B测试对SEO影响。在SEO方面,A/B测试需要注意: 不要欺骗搜索引擎 欺骗是指,向人类显示一组内容,想搜索机器人显示另外的内容。无论是否进行测试,请确保不是基于用户代理(user-agent)决定是否提供测试,或要投放哪个内容变体。一个不允许的例子是,当用户代理是“Googlebot”时,向其显示原始内容,如果这样做,网站可能被搜索引擎降级或从搜索结果中移除! 使用302,而不是301。 如果您正在执行A/B测试,将用户从原始网址重定向到变体URL,请使用302(临时)重定向,而不是301(永久)重定向。这告诉搜索引擎这个重定向是暂时的,搜索引擎应该将原始URL保留在索引中,而不是用重定向页面的RUL来替换。 试验尽快结束,版本尽快更新 A/B测试得到可靠性结论所需的时间周期,依赖于转化率以及网站流量大小; 一个好的AB测试工具能告诉你什么时候已经收集足够数据来得出可靠的结论。完成测试后,应该使用选取的版本更新网站,并尽快删除测试的所有元素,例如备用网址或测试脚本和标记。   A/B测试过程 运行A/B测试验的正确方法是遵循科学过程。它包括以下步骤: 分析网站数据:使用云眼统计分析功能分析网站,并在转化渠道中找到问题。例如,识别跳出率最高的页面,如主页的跳出率是否非常高。 观察用户行为:利用访客行为分析功能,查找阻止访客转换的页面或环节。例如,“CTA按钮在主页上不突出”。 构建假设:根据访客行为分析的结果,构建旨在提高转化率的假设。例如,“增加CTA按钮的大小将使其更加突出,并将增加转化。” 测试假设:根据假设创建一个新的页面版本,并且对比原始页面进行A/B测试。例如,“用具有较大CTA按钮的版本对比原始主页进行A/B测试”。根据每月访客数量、当前转化率和预期转换率变化,计算测试可能持续的时间。(可以用云眼A/B测试样本计算器计算) 分析测试结果:分析A/B测试结果,并查看哪个版本提供了最高的转化。如果版本中有明确的胜出者,请继续执行第6步。如果测试结果不确定,请返回到第3步,重新设计假设。 向所有相关方报告结果:让营销、IT和UI / UX中的其他人了解测试结果和结论建议。   第一次A/B测试 使用云眼A/B测试启动转化优化非常简单。基本上,只要四个简单步骤。 1.在网站中添加云眼JS代码段 嵌入云眼JS代码段后就可以运行在网站上创建的A/B测试案例。 2.使用所见即所得的可视化编辑器创建优化版本 在可视化编辑器中加载网站,并简单点击界面对页面进行修改。高级用户甚至可以使CSS和JS代码更改。 3.选择目标 所有A/B测试都要设置一个或多个想要提高的转化率目标。这些目标可以直接设置(如点击链接,访问页面),也可以通过代码设置高级自定义事件。 4.开始跟踪测试 A/B测试试验已经准备好了。您可以在访客到达测试现场后查看报告。   A/B测试成功案例 30天免费试用 注册即可获得30天免费试用,体验云眼A/B测试强大功能。开始您的A/B测试之旅吧!

A/B测试,从一个优秀员工的炼成说起

一个优秀员工的工作成果一定是让客户、同事和领导满意的,但您是否注意到优秀员工工作时有什么特点吗?优秀员工在工作的时候,通常为解决一个问题会考虑多套方案甚至全部可能的方案,然后从中选出最优的方案。相反,表现差的员工,他们往往想到一个方案就认为可以了,不去再思考会不会有更好的方案。就是因为这点习惯上的不同,一个优秀员工就炼成了。 因此,解决问题时,不断的问自己有没有B方案、C方案,是一个人在某个行业变得优秀的一个很有效的方法。 我们将此再推广到项目和产品上。项目的商业模式,有没有B方案、C方案?产品的定位,有没有B方案、C方案?功能特性有没有B方案、C方案?业务流程有没有B方案、C方案?界面设计有没有B方案、C方案? 有了多套方案,如果还能够根据客户反馈正确的判断出最优方案,这就是A/B测试了。如果一个项目或产品能够做A/B测试,就有可能很快在行业里脱颖而出! 一个做A/B测试的产品与一个不做A/B测试的产品相比,就如同一个优秀员工与一个平庸员工的对比一样鲜明!

A/B测试

实施A/B测试的阻力在哪里?

A/B测试是个好东西,如果没有技术障碍并且成本很低,谁不想实施呢?试想一下,给美国的总统候选人分别分配5%的人们群众,试用他们三个月,让他们真刀真枪的治理国家,然后通过实际效果决定谁获胜,这是不是比通过四处演讲+互相攻击选出的总统会更靠谱些?但是,很遗憾,这在现实的物理空间基本上是行不通的。在互联网的虚拟空间,却为A/B测试的实施提供了技术可行性。所以,我们看到欧美的互联网公司普遍在应用A/B测试技术。但是,国内互联网行业A/B测试的应用落后于欧美,原因在哪里?或者说,助力在哪里呢? 有人说国内实施A/B测试的阻力在企业文化和观念上。但是,在商业利益面前,有多少理念都被颠覆,更何况接受一个小小的A/B测试理念,只要A/B测试真的有效果,那点误解和不同看法应该是不足为虑的。 有人说国内目前还没有太多A/B测试经验。这可能低估了互联网运营者和产品经理们的智商和能力,我们很清楚互联网运营者和产品经理是怎样一个群体,他们很多已经窥觑A/B测试很久,了解的门儿清,只差找到合适的机会用一用了。 那么实施A/B测试的助力到底在哪里呢?在工程实施上,具体说是工程实施的成本上。ROI(Return On Investment)是个永远也绕不过的问题。有人说A/B测试的系统和工具很简单,没有技术壁垒,这可能受到某些A/B测试服务商做法的影响。试想一下,做几个API,然后就让人家修改App的代码调用你的API来做A/B测试,这可不是太简单了。但是,这只是对A/B测试服务商来说是简单,但对App开发运营者能叫简单吗,能够接受吗?A/B测试要试验和比较的方案一般都难定高下,否则就不用测试了,面对这样的不确定性,如果要修改代码而且还要QA,日后还要维护,投入和产出到底会是怎样的关系?这是人们在A/B测试面前犹豫不决的主要原因。因此,A/B测试要解决的关键问题是工程实施问题,只有很好的解决实施效率和实施难度问题,A/B测试才能在国内普及。 国内的A/B测试服务商中,合力云通的“云眼”产品,一直关注于可视化编辑和无埋点技术,致力于降低A/B测试实施的技术难度和成本,提高A/B测试的实施效率和实际效果,希望云眼的努力能够真正推动国内A/B测试实施。    

为什么网站和App都开始做A/B测试?

A/B测试在欧美互联网企业里已经普遍应用,国内的网站和App也开始实施A/B测试。 在国内的互联网行业里,大家对A/B测试并不陌生,大型互联网公司已经在尝试实施,A/B测试框架方案大致有两种: 两套代码:顾名思义,是把control(基准代码)和treatment(实验代码)分别部署在不同的机器,通过统一的router分发流量。百度和google使用的是这套架构的好处是对业务侵入性小,灰度发布和正式上线都非常方便。但要求就是开发流程是分支开发模式且代码部署需要和分流路由可用统一配置和联动。 一套代码:业务逻辑中把control和treatment的分支都写好,通过在业务服务器里面嵌入AB测试框架的client,判断流量是该走control还是treatment。这种思路的好处是对外部系统依赖小,全部逻辑都在业务服务器完成,适合主干开发的模式,但是对业务侵入大,灰度发布不方便,代码维护还有整洁度下降。微软和amazon是使用这套架构。 我们可以看到,上面两个方案无论哪种,技术复杂度和工作量都是很大的,没有足够的资源和成熟的管理规范,将很难实施。 再有,即使在大型公司,用上面的方案做一次受控A/B测试(比如,测一个按钮绿色和橙色的不同效果),也会有高射炮打蚊子的感觉。 因此,我们说缺乏高效的A/B测试工具,是国内互联网行业过去未能广泛开展A/B测试的主要原因。 那么,国内目前有没有高效的A/B测试工具呢?有! “云眼”就是最近推出的能高效实施A/B测试的工具。 通过”云眼”Web控制台,A/B测试的所有环节都可以轻松搞定: 首先,无需Router也不需要改后台系统,流量分配是在编辑器上设置完成的。 其次,A/B版本的制作通过编辑器以所见即所得的傻瓜方式完成。 最后,衡量不同版本优劣的指标,也是通过编辑器以“无埋点”方式设置。无需在Web和App应用中增加或修改代码。 如果你想做一次受控A/B测试,那是再容易不过了,分分钟搞定! 你的各种假设,都可以轻易的用A/B试验获得验证,而不再为传统A/B测试方案的繁琐而苦恼。 “云眼”的发布,极大提高了A/B测试的效率,推动着A/B测试在国内互联网领域的实施和普及! 文章来源:为什么很多网站和App都在做AB测试?

A/B测试原理

A/B测试真的有用吗?理论依据在哪里?

前一阵,八达岭野生动物园老虎伤人事件被炒的沸沸扬扬。很快有动物学家指出,背影,背影激起了猛兽的攻击欲望,就像公牛看到红布就要攻击一样。下图中,如果小孩一直面对老虎,老虎也一直趴在那里,而一旦小孩背对老虎,老虎就扑了过来。 人的基因里保存着无始以来相同的习惯积累而成的共同的本能。当人受到特定的信息刺激时,多数人就本能的做出同样的行为。 当人看到某些标志、听到某些特定的语言,或身处某种特定环境时,一些人的购物本能,就可能会被激发。 除了固化的基因,还有后天习惯。一个地方或一个时代的人群,受到当地和当时环境的影响,形成了一些共同的习惯,当他们面对特定的标志、语言、环境时,一些人也会由于惯性,做出相同的事情。 如果商家知道如何激发多数人的购物本能或购物习惯和倾向,他的客户多、买卖好也就不奇怪了。 在一个竞争激烈的市场中,一个商家如果能够吸引和留住更多一些的客户,其他商家的客户就要少一些,差距是双倍的。我们会看到,能够吸引和留住更多客户的商家很快就脱颖而出。 怎样能够激发更多客户的购物本能或习惯呢?A/B测试!它能让你通过不断的试验,找到激发更多客户购买你的商品的秘密。 所以,赶紧做A/B测试吧!“云眼”是国内最好的A/B测试工具,快去免费试用吧!   原文:AB测试真的有用吗?理论依据在哪里?

A/B测试过程

合力云通“云眼”向低效A/B测试说:NO!

A/B测试已经获得广泛接受,但是为了比较两个不同的界面或两个不同的流程,程序猿真的愿意在程序里到处插入那些调用AB测试API的代码吗? 即使程序猿愿意,QA呢?面对两套界面或两套流程,QA的工作量就翻倍。 QA还有一部分工作是验证AB测试是否正常工作,如果产品上线后发现忘记了采集某些指标数据,很可能一切都白忙活了! 为了试验尚不确定到底有多大差别的两个界面或流程(很多时候是没有多大差别的),值得费这么大劲吗? 面对这种低效、低ROI(return on investment)的A/B测试做法,“云眼”说NO! 让我们看一下“云眼”是怎样做A/B测试的? “云眼”做A/B测试的实现不是在开发阶段,而是在App和Web上线后。 “云眼”通过可视化编辑器制作A/B测试版本,设置采集指标,即时发布AB测试版本。这种做法有以下优点: 无需重新发布App和Web的新版本,即可增加/修改A/B测试场景,而且AB测试的场景数量几乎可以是无限的; 可以灵活而且高效的制作A/B测试场景,节省了程序猿和QA大量工作; “云眼”作为国内最好用的A/B测试工具,名副其实,当之无愧! 用“云眼”进行A/B测试的步骤如下图所示。 “云眼”在线可视化编辑器可以修改App和Web界面,包括: 总体布局 文字内容 字体类型、大小、颜色 按钮大小、位置 更换图片 图片大小、位置 “云眼”在线可视化编辑器可制作多个界面版本,分配随机访问流量,还可设置评估指标。 “云眼”通过对测试版本业务数据和用户行为数据的数理统计统分析和比较,找到最优版本。 通过详细分析每一个测试版本的业务数据和用户行为数据,确保没有奇异数据影响最后的数理统计结果。 北京合力云通科技有限公司成立于2015年,专注于用户体验优化服务。公司的“云眼”产品,是国内领先的用户体验优化系统,完美支持A/B测试的各个环节。基于A/B测试,公司还提供旨在提高转化率的咨询服务。 原文:合力云通“云眼”向低效A/B测试说:NO! 相关阅读:什么是A/B测试?  

云眼A/B测试特性

合力云通“云眼”让用户体验优化看得见

合力云通发布“云眼AB测试”系统,让App和Web以低成本、高效率的方式进行A/B测试,建立闭环改进机制,数据驱动、持续不断的优化用户体验,提高转化率和留存率。 中国互联网的发展已经到达一个拐点,一方面网站和App的数量在快速增加,而另一方面网民数量的增加在减缓,网民人口红利在消失。因此,对于网站和App的推广,虽然渠道很多,但流量变得越来越贵。在这种背景下,如果网站和App的转化率不高,将导致推广成本居高不下。 转化率低的一个重要原因是网站和App的用户体验不够好。用户体验不好,不但降低转化,浪费推广投入,还可能带来负面影响,降低企业的品牌形象和声誉。再有,网站和App用户体验不好,难以留住老客户,很容易引起客户的流失。“云眼”的发布,对消除转化率低这个痛点将会发挥巨大作用。 A/B测试是将网站和App的某些界面设计成两个或多个版本,同时随机的让一定比例抽样客户访问,然后比较各个版本的实际效果(转化率),最后选择效果最好的版本正式发布给全部客户。 “云眼”系统全面覆盖A/B测试的各个环节,并具有以下特色: 简单易用。即使是没有网页技术背景的人,也可以通过可视化编辑器完成优化版本的制作和目标设定。 高效便捷。通过使用云眼,业务人员能够快速的实施A/B测试。数据收集和结果分析自动完成。 功能强大。对于复杂的优化版本制作和特殊定制的数据指标采集,可以通过“云眼”API来完成。调用“云眼”API,不需要修改客户的网页和App代码。 跨平台支持。同时支持Web,Android App和iOS App等客户端类型。 多业务模式。同时支持 SaaS和私有部署两种业务模式。 除了提供“云眼”产品服务以外,北京合力云通科技有限公司还提供用户体验优化方面的咨询服务,覆盖A/B测试的全部环节,切实解决客户转化率低的痛点。 北京合力云通科技有限公司成立于2015年,专注于用户体验优化服务。公司的“云眼”产品,是国内领先的用户体验优化系统,完美支持AB测试的各个环节。基于A/B测试,公司还提供旨在提高转化率的咨询服务。       原文:合力云通“云眼”让用户体验优化看得见