资讯专栏INFORMATION COLUMN

Airlock:Facebook 的移动端 A/B 测试框架

sixleaves / 3364人阅读

摘要:并不是每个测试都可以用到生产中,但即使是失败的测试也能帮助我们理解如何才能更好地改进。当有回应返回后,我们就会更新按钮。浅绿色的条柱是试验用户的数量,黑绿色的条柱是实际被影响的用户数。设备请求用于试验的数据,服务器记录它发出的回应。

译者注:本文来自 Facebook 工程师团队博客

两年前,我们重写了我们移动端(iOS,Android)的应用,使用了原生的开发栈(native development stacks)代替我们以前定制开发的 Web 栈(custom web-stack)。这给了我们在关于项目在那里/怎样下载、缓存、释放等等方面一个更好的控制。它分别深入地和操作系统整合在一起,提供在底层调整修改所有系统的一整套工具。

测试是我们开发的一个重要部分,但在转换到原生的之后,我们没有了 A/B 测试的能力。并不是每个测试都可以用到生产中,但即使是失败的测试也能帮助我们理解如何才能更好地改进。失去的这部分能力变成了一个我们要应对的挑战。

A/B 测试

要把我们的应用移植到 iOS 和 Android 上,需要来自不同团队的人来进行协作,每四周就要产生一个新的修复一些 bug 和带有一些新特性的二进制软件包。在我们发布一些更新之后,对于我们很重要的事情是要去明白:

新特性的使用情况

bug 修复后的运行情况和稳定性

用户界面改进之后用户是怎么使用这个应用及在哪里花的时间多

为了去了解这些事情,我们需要一个移动端进行 A/B 测试的基础组件,这个组件能让我们的用户分别使用不同版本的应用(版本 A 和版本 B),这些版本在除某些特别需要测试的部分外,其他各层面都是一样的。所以我们创造了 Airlock,一个可以让我们比较不同版本应用的度量数据(metric data)和进行各种各样测试的测试框架,这帮助我们决定采用那个版本或者后续如何迭代。

从一点一滴中建成

我们尽可能从最简单的试验开始:使用已有的 Web-Stack A/B 分箱(binning system)系统。我们构造了一个测试:把聊天按钮换成文字"Chat"的试验。当应用启动的的时候,它会发送一个到我们服务器上的网络请求,询问这个试验的参数。当有回应返回后,我们就会更新按钮。一些员工会有按钮,另一些员工会有文字"Chat"。我们期望这仅仅会影响信息发送的数量(看起来不会太多),其他的东西不会受影响。

曝光日志

当这个版本的应用公开发布了,我们等待数据能稳定下来,然后发现看到文字"Chat" 的版本会更热衷于使用这个应用。是不是我们发现了什么秘密,或者诱惑般的魔法?沮丧地说,并不是。我们遇到了很多 bug,其中一个很大的问题是,某个组件并不能正确地缓冲数值。由于这是个大的系统,基础设施(the infrastructure)必须要是 "防弹的",不然收集到的数据就没用了。

从服务器开始的数据管道决定某个人的版本是属于那种变体的。然后,数据就会被打包,接着发送到设备上,设备分析返回的信息然后保存。接着,这个值会被用于重新配置 UI,然后最终在屏幕上显示。问题是我们在依靠服务器对我们数据分析的分类。一个简单的 bug 就导致了一大群用户在使用有别于我们期望的的变种版本。服务器还在坚持:"我告诉了设备去显示字符串!" 但在某处地方这个语句变得有点令人模糊(一个在客户端存贮逻辑上的 bug)。

一个试验的部署图:

上面图表展示了一个试验的部署。浅绿色的条柱是试验用户的数量,黑绿色的条柱是实际被影响的用户数。我们可以看到,服务器和设备的数据区别还是很大的: 在第一天,大多数用户收到这个配置,但大多数用户没有留意到我们试验。

当问题不仅仅是设备收到返回的数据,而需要加上我们的数据分析需要知道什么时候收到信息,然后把它正确地显示在 UI 上时,问题变得更大了。即使信息能正确地到达,在 UI 不正确时也有一个延迟。我们通过
添加双向握手(wo-way handshake)解决了这个问题。设备请求用于试验的数据,服务器记录它发出的回应。因此,即使某用户没有看到我们想让他看到的,我们仍然可以进行正确性分析(但也必须意识到选择性偏差(selection bias)的问题,还有分发时由于某些原因变得不平均)。

可伸缩性

在进行了几个月这样的"课程"之后,我们必须将支持两个试验的系统升级支持整个应用的系统。这个促使 Airlock 发生变革的试验是以前我们原想着进化和简化我们应用内的导航模块而开发的。在经历这几个月之后,我们把这个应用改变了很多,你可以去下载 Facebook for iPhone 来体验一下,这里面很多是测试的功劳。

随后,Airlock 被用于支持更多的试验,其请求的参数,数据的记录、客户端计算等等都快速地变多。Airlock 充分地被用于测试原生的应用,使得我们的应用运行得前所未有的轻快,伴随着测试的自由,再测试,和评估测试结果,我们期望能建造更好的测试和创造更好的用户体验。

原文:Airlock - Facebook"s mobile A/B testing framework
翻译:Segmentfault

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/8684.html

相关文章

  • Facebook贾扬清宣布新机器学习系统Caffe2Go

    摘要:这一新程序被称为,是一个完整的深度学习系统,它的架构已经嵌入手机中。因此,移动设备环境对机器学习系统提出了机遇和挑战。展望下一步,加上这样的研究工具链,是的机器学习产品的核心。 风格迁移一直是机器学习领域内的一项重要任务,很多研究机构和研究者都在努力打造速度更快、计算成本更低的风格迁移机器学习系统,比如《怎么让你的照片带上艺术大师风格?李飞飞团队开源快速神经网络风格迁移代码 》、《谷歌增强型...

    Rango 评论0 收藏0
  • 移动A/B测试5问

    摘要:移动测试就是指把这个试验用来对比优化移动应用。移动端测试应该测试什么对于移动端,几乎所有都可以并应该进行测试。对消极和积极影响的权衡评估会是优秀测试平台的重要组成部分。那么,准备好开始你的第一个移动端测试了吗本文作者吆喝科技 做A/B测试的理由很多,Facebook、Google、BAT、滴滴、美团……大公司都在做。但知道它们为什么做?怎么做?A/B测试有哪些方法论来指导最近实践,让我...

    陆斌 评论0 收藏0
  • 每周清单半年盘点之 React 与 ReactNative 篇

    摘要:前端每周清单半年盘点之与篇前端每周清单专注前端领域内容,以对外文资料的搜集为主,帮助开发者了解一周前端热点分为新闻热点开发教程工程实践深度阅读开源项目巅峰人生等栏目。与求同存异近日,宣布将的构建工具由迁移到,引发了很多开发者的讨论。 前端每周清单半年盘点之 React 与 ReactNative 篇 前端每周清单专注前端领域内容,以对外文资料的搜集为主,帮助开发者了解一周前端热点;分为...

    Barry_Ng 评论0 收藏0
  • 【腾讯Bugly干货分享】React 移动 web 极致优化

    摘要:数据管理及性能优化统一管理数据这一部份算是重头戏吧。重复渲染导致卡顿这套的东西在家校群页面上用得很欢乐,以至于不用怎么写都没遇到过什么性能问题。但放到移动端上,我们在列表页重构的时候就马上遇到卡顿的问题了。列表页目前的处理办法是将值换成。 本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/57908... 最近一个季度...

    suosuopuo 评论0 收藏0
  • 2017 年崛起 JS 项目

    摘要:通过对比各项目过去个月在上新增数量,来评估其在年度的受关注程度,进而选出年度领域崛起的明星项目。也许正因为上述最后一点,在中国拥有大量的拥趸。不仅被中国最大的电商平台阿里巴巴使用,也获得了与这些公司青睐。 共 4741 字,读完需 8 分钟,速读 2 分钟。我有幸参与了该项目的部分中文版翻译、校对工作,感谢 Sacha Grief,Micheal Ramberu 的统计整理,以及 Fr...

    gaara 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<