A/B 测试

提供 A/B 测试服务的公司

Splitforce http://splitforce.com/

Optimizely https://www.optimizely.com/

Omniata https://www.omniata.com/

技术文章

Splitforce移动应用A/B测试工具套件升级了

http://www.infoq.com/cn/news/2014/06/splitforce-mobile-ab-testing

Splitforce允许已注册的开发人员定义试验和目标,并为iOS和Android提供原生SDK,统一在他们的应用中嵌入不同的方案。在运行时,SDK连接到Splitforce的Web Service,确定哪种方案展示给用户或者通知Splitforce一个已达成的目标。最终,开发者能激活最成功的变化方案给所有用户,无须将应用重新提交到应用商店。

现在,Splitforce引入了多种新特性改善移动应用的优化过程:

  • 用户定位:变化方案可以基于特定条件来选择,而不是按给定比例随机选择。条件可以分为“预定义条件”,如屏幕大小、语言设定或者操作系统版本,以及“自定义定位条件”,可引用客户的用户数据库中已存在的任何信息。
  • 基于行为数据的测试:可以基于应用的历史使用数据选择变化方案,例如会话持续时间或者上一次应用启动时间。
  • 自动优化:使用自动优化时,越成功的变化方案将自动更频繁地呈现。一旦激活自动优化,学习算法将观察不同变化方案的表现。某个变化方案的表现越好,则越可能推荐给下一个用户。最终,次优方案将被自动淘汰。

plitforce已经构建了对苹果iOS 8和Swift的支持,等到苹果秋季发布iOS 8后将会正式发布。

未拟定假设的A/B测试注定是失败的

http://www.infoq.com/cn/news/2015/02/ab-test-destined-to-fail

如果要进行一次旅行,那么首先应该知道目的地。A/B测试也是如此。

假设是测试执行前的预测,它清楚地描述了下列问题:

  • 什么发生了改变?
  • 预期会产生什么结果?
  • 为什么会有这种预期?

用文档记录研究过程和假设。在团队内发布测试结果时,记得连同关键测试指标一起分享假设。测试假设库在未来的测试中将成为非常有价值的参考。

天猫推荐算法团队的那些事儿

http://www.infoq.com/cn/news/2014/04/tmall-recommendation-team

InfoQ:验证新算法会有AB测试吧?怎么做的?

得福:我们的测试有两种,一种离线测试(线下测试),一种线上测试。一开始我们都做线上AB test,你拿5%或10%的流量供测试,95%或90%的流量作为基准,然后你可以做参数变动或算法调整。这是以前。后来我们考虑到,因为 同时会有很多算法想要做测试 ,一方面流量有限,而且对天猫来说流量是非常值钱的,每个用户可能只有20分钟或者30分钟,所以一个算法如果未经验证就到线上做AB,其实是很浪费流量的,对用户的体验也不好,5%或10%的用户可能会使用一个非常差的版本。

所以渐渐就开发了一套离线评测方法,不需要线上流量就能测试:它用以前的日志去模拟现在的行为,相当于把日志作为模型的输入,看不同版本的算法在日志上跑的结果怎么样,来判断这个东西放到线上后大概的效果。这种系统不会100%准确,离线结果A比B好10%并不表示在线上也是10%,但一般如果离线显示A比B好,那到线上A一般也会比B好,好多少不一定。我们用离线方法就可以淘汰很多不太靠谱的算法——A如果比B明显要差,我们就可以去掉。只有A比B好,我们才拿到线上测,保证流量能够被充分利用。另一个好处是, 离线测试十分快速 ,因为处理日志跑起来是很快的,可能十几分钟就跑完了很大的用户量,而 线上一方面流量少——不可能切换太多过来,同时你需要看很多天,效果才能稳定下来,可能需要一到两周才能看出效果。

所以这两个方法现在我们同时在用,互相补充。

Booking.com的A/B测试实践

http://www.infoq.com/cn/news/2015/11/ab-testing

但要正确地实践A/B测试,需要满足一些前提条件。

每个特性都需要进行完整的测试,但这种 测试必须是原子性的 。如果你不能做到每次测试只针对一项变更,你就无法控制变化因素,从而不可能得到清晰无误的结果。虽然目前市面上已经出现了许多A/B测试工具,但Frisby认为这些工具都不够理想,因为他们都缺少进行 恰当的、完整的测试所必需的上下文与灵活性

应用这一实践的软件组织必须建立一种 数据驱动产品开发的文化,而不是依赖于专家的意见 。所招聘的员工应具备企业家的心态,这样就能够促成一种“刨根问底”的组织文化,从而促使每个人对于他所不了解的内容提出疑问。作为一种终极的促进因素,优秀的A/B测试实践在许多情况下会证明,在当前上下文中,你、你的老板或业界专家的想法其实是错误的。

在开展A/B测试的过程中,软件组织必须注意一些常见的错误。首先, 不要尝试“大范围的A/B测试”,即一次性改动过多的内容。也不要尝试“边缘A/B测试”,即仅仅专注于产品中某个很小的部分,即便它非常重要,例如你的登陆页面。 此外,Frisby还简略地描述了“假定可再现性”这一思想。

#? 为什么不要尝试边缘A/B测试

“假定可再现性”这一思想是指由他人所进行的实验也能够在你自己的环境中再现。但上下文始终是最关键的因素,对于其他人有效的做法未必就适合你。Frisby提出了一种层次型的可信赖数据源(按可信赖度从高到低排列):你自己的实验数据;你个人的观点,因为你最了解你自己的产品;他人的观点;他人的实验数据,因为它会为你造成一种假象,让你错误地确信它的结果。

Frisby并不建议在所有场景中都应用A/B测试,如果你的web应用程序没有达到一定的访问量,那么测试的结果可能也是无意义的。此外,如果你没有定义客观的衡量指标,并通过这些指标根据你的测试结果进行决策,那么也不应当采用A/B测试。最后,软件组织必须要做好准备,因为A/B测试的结果很可能会与组织所确信的恰恰相反,而接受这一点并不像人们想象中那么容易。

#? 没有懂上下文的意思,具体的做法是怎样的,怎么在测试工具中考虑上下文?

面向移动应用程序的Splitforce A/B测试

http://www.infoq.com/cn/news/2013/12/splitforce-mobile-ab-testing

对于手机行业而言, 分析用户行为和优化转化率 仍然是非常新鲜的事物。

目前,Splitforce支持原生iOS应用程序和基于Unity应用程序引擎的游戏。根据官方消息,Splitforce计划在2014年第一季度提供Android支持。

借助于Splitforce的SDK和Web服务,开发人员可以创建影响用户在其移动设备上体验移动应用程序方式的试验。 动态组件 取代了在应用程序代码中硬编码的组件,Splitforce服务器可以通过Web接口对它们进行控制。开发人员可以创建新的以及调整现有的正在运行中的变体,包括用户会体验应用程序一个变体的哪一部分,以及另一个变体的哪一部分。对于这些变体的试验结果可以从三个不同的范畴来分析:

  • “比率(Rates)”:比率用来分析诸如购买或注册的用户数占总用户数的比例多久能够达到特定的目标。
  • “时间(Timing)”:时间目标用于查明用户在应用程序的特定区域花费了多少时间,或者用户在购买一种产品前用了多长时间。
  • “数量(Quantities)”:数量提供关于用户完成一项任务的次数信息,如设法完成一个游戏等级。

试验可以基于文本、数字、颜色、布尔值或自定义主题进行。在注册并定义好试验后,Splitforce会创建代码片段, 应用程序开发人员可以复制它并粘贴到应用程序的源代码中 (>_<)。测试不同的按钮颜色和统计购买次数的试验可以使用下面的代码添加到一个iOS应用程序中:

[[SFManager currentManager] experimentNamed:@"Experiment #1"
applyVariationBlock:^(SFVariation *variation) {
      // 配置‘测试按钮颜色’
      UIColor *testSubject = [SFUtils colorFromHexString:variation.variationData[
          @"Test Button Colors"]];
        // 设置特定按钮颜色
} applyDefaultBlock:^(NSError *error) {
      if (error) NSLog(@"Splitforce Error: %@", error);
        //设置默认按钮颜色
}];

在应用程序代码接下来的部分中,当达到期望的目标时,通知Splitforce服务器:

SFVariation *variation = [SFManager.currentManager variationForExperimentNamed:
@"Experiment #1"];

[variation goalResultNamed:@"Item Purchased"];
[variation variationEnded];

#? 不重新提交应用页可以创建新的变体吗?每个都需要在非 SDK 的源代码里支持?

缺失的移动后台服务

http://www.infoq.com/cn/news/2014/07/mobile-backend-services

Omniata对数据分析和A/B测试提供了丰富的功能支持,但是无法与Wooga已有的工具集成,并且不支持 深度访问数据,如哪些用户收到了应用的特殊配置 ,这都严重阻碍了我们采用该产品。所以,Wooga从早期就研发了自己的工具,用于分析、仪表板和报表等方面。

Twitter的A/B测试实践(一):为什么要测试以及测试的意义

http://www.infoq.com/cn/articles/twitter-ab-test-practise-part01

https://blog.twitter.com/2015/the-what-and-why-of-product-experimentation-at-twitter-0

A/B测试曾在多个领域产生深远的影响,其中包括医药、农业、制造业和广告。 在软件开发中, A/B测试实验提供了一个有价值的方式来评估新特性对客户行为的影响。

# 想起《众病之王》中的 A/B 测试。

本文是该系列的第一篇,主要介绍了为什么进行 A/B 测试和如何避免其中的陷阱。

实验是 Twitter产品开发周期的核心。 这种实验文化可能是因为 Twitter对工具、研究和培训进行了大量的投资,以确保 特性团队能够对他们的想法进行无缝、严格的测试和验证

Twitter实验的规模无论数量还是种类都是庞大的——从细微的 UI/UX变更,到新特性,到机器学习模型的改进。我们喜欢将实验看作是是一个无尽的学习环。

–> Build a hypothesis –> Define Success metrics –> Test hypothesis –> Learn –> Ship –> Build a …

  • 建立假设:提出新特性想法或者为现有特性提出改进建议。
  • 定义成功指标:评估“机会大小(opportunity size)”——受该变更影响的用户数量。正式定义实验成功和失败的指标;考虑可接受的折衷方案。
  • 检验假设:实现拟定的变更,”检测(instrument)“相应的日志,并 执行合理性检查以确保实验正确配置
  • 学习:检查实验中收集的数据,吸取其中的经验教训,并与其他 Twitter团队共享。
  • 发布:收集完数据后,判断实验是否验证了假设,并决定发布或者不发布。
  • 建立另一个假设:结合实验中的新想法,为更多的改进建立更多的假设。

#? 考虑可接受的折衷方案,具体怎么做,折衷方案需要测试吗? #? 合理性检查怎么做?

A/B测试、决策制定和创新

Twitter的”产品检测和实验(Product Instrumentation and Experimentation)”(PIE)团队对实验哲学进行了大量的思考。A/B测试可以带来很多好处,但是它也有 很多众所周知的、容易陷入的陷阱 。它的结果往往是出人意料、违反直觉的。我们如何避免这种陷阱?什么时候我们应该建议进行 A/B测试,从而试验特性或者拟定的变更? 在决策制定过程中我们如何保持敏捷,且在承受重大风险的时候仍能保持严谨?

测试的好处以及增量测试

A/B测试文化重点关注的是它带来的是 小增量收益 ,大部分实验只能带来个位数百分比的改进,或者甚至是分数百分比。因此,有些观点认为,这有什么意义呢?为什么不从事一些更有影响力、更有革命性的事情呢?

这是事实:如果存在实验能够提升指标,那么到目前为止,大多数实验在以最低限度的方式提升着指标;某个实验如果能够为大部分用户将某个核心指标提升数个百分点就被视为一种非凡的成功。

这与 A/B测试的基本原理无关。这是因为一个成熟的产品很难通过大幅度改进指标的方式改变。 很多人认为的全垒打想法根本没有带来一点点的改进 :人类原来极其不善于预测什么可行(更多信息请参阅 “Seven Rules of Thumb for Web Site Experimenters” )。大多数时候,不理想的 A/B测试结果让我们能够及早发现,看上去不错的想法其实可能不怎么样。因此我们更愿意尽可能快的获得坏消息,重新回到绘图板;这就是我们实验的原因。

A/B测试是一种可以确保好想法不会夭折的方法,使好的想法有机会全面充分开发。当我们真正的信任某个想法,而初步实验结果不能满足我们的期望的时候,我们可以对产品做进一步改进, 持续改进直到符合期望可以发布给数百万的人使用 。另一种方法是,构建一些感觉良好的特性并发布,之后开发其它新的想法,一年后有人意识到根本没人在使用这个特性,它就这样静静地陨落了。

在我们从事各种各样原型开发的时候,快速迭代和衡量拟定的变更带来的影响让我们团队能够及早将隐式用户反馈吸收进产品中。我们可以发布一个变更,研究哪些能够产生改进,哪些不能,接着为能够进一步改进产品的变更建立假设,然后发布变更,周而复始直到拥有能够推送给更广泛用户的变更。

有些人可能认为这种增量变更效率太低。当然,发布“大创意”听起来远比小改进好太多了。然而仔细想一下,将许多小变更叠加起来就能产生复合效果。 回避增量变更的产品改进方法很大程度上不是一个好方针。 一个好的金融投资组合要能够平衡尽管回报不那么高但可预测的无风险赌注和高风险、高收益赌注。在这方面 产品组合管理 没有什么不同。

这就是说,有很多东西我们不能,或者不应该测试。 有些变更被设计用于形成网络效应,而这些基于用户分桶的 A/B测试不会捕获 (尽管确实存在其它技术能够量化这种影响)。当只针对一个随机比例的人群时,某些特性可能会失灵。例如,在简单的 A/B测试中, Group DMs就不是一个可使用的特性, 因为可能那些有幸获得此特性的人想要给那些没有获得此特性的人留言,这使得该特性基本无用。 其它特性可能是完全的正交 ——例如推出像 Periscope一样的新应用程序就不是 Twitter应用实验。但是一旦推出,A/B测试就成为一种重要的驱动应用程序内可度量增量和不那么容易度量的增量变更的方法。

还有另一类变更是,主要的新特性在内部构建过程中通过用户研究进行测试,但是考虑市场战略原因,在特定爆炸性时刻发布给所有的用户。作为一个组织,我们在自认为对产品和用户都有利的时候做出这个决定。我们相信尽管增量变更可能带来更好的初始版本,使更多用户尝试和使用,但是我们能够从大版本中获得更多收益。这是产品负责人需要权衡取舍的。那么当这么一个新特性发布后,我们要对其增量变更进行 A/B测试吗?当然啦!随着想法的成熟,我们使用完善的科学原理指导它们的演化——并且实验是该过程的关键部分。