关于神秘的GrowthHacking,Facebook都做了什么?(下)

2015-11-28 22:54 稿源:雷锋网  0条评论

后来Facebook经过一次大的UI改变:

最大的变化就是九宫格改为了左侧抽屉式的导航栏,左上角出现著名的”Hanburger”按钮。

于是来到2013年,Facebook app准备进行新一轮的大改版,由左侧抽屉式改为 Tab bar 格式:

这一版的改动,在意义上主要是让用户可以更加方便切换到news feed以外的其他功能区;可是却引发了另外一个问题:到底下面的tab bar放几个按钮?每一个位置上应该放什么?

此时已经是2013年,前一年在Facebook在WWW首页的改版失败依然影响着公司的engineering team,于是在iOS app决定更偏好保守和务实。Airlock在这次的改版上起到巨大的作用。Facebook iOS core team的人写好了tab bar的代码后,并没有马上发布给所有用户,而是开始了长达4个月的灰度发布和A/B testing。

测试了下面 tab bar 各种可能的情况:比如 5个tab项 或者 4个? 第二个放 Requests or Messages? Notifications 或者 Groups 暴露在外面? 同时对于右上角的按钮的功能和样式也进行了测试,比如是放 通讯录 还是 Messages? 是放一个图标还是直接写字?等等。

一度因为出现新的测试组合,以及对于好几个组合的测试结果在数据上的比较模棱两可而把发布时间一拖再拖。整个iOS app界面重组的项目由 Mick Johnson 主导,他是我见过执行力最强的Facebook的几个PM之一。他认真审视了各种组合的数据后,结合Facebook当时要大力推行Messenger的大背景,最后确定上图的组合顺序。这个组合在各种测试中数据的综合表现最好,能够有效地让用户查看news feed,增加用户的好友数(好友数是从Facebook data组里试验出来的一个非常重要的指标,这在文章最后可以和大家介绍),方便地收发消息,以及查看新消息,但是 groups,events,还有其他一些辅助功能被藏入了 “more” 之中。

案例二:Voice message 的发布过程

下面拿我之前负责的 voice message(语音消息)功能在Facebook messenger中的发布来分解一下整个Facebook 灰度发布和 A/B testing 的过程:

同理,在 iOS messenger 中,用户一登录后(以及以后的每一个小时),iOS messenger client都会和server通信一次,拿到所有 gatekeeper(控制属性)的值,然后缓存在本地。Messenger上重要的新功能在发布之前都要放在一个GK(gatekeeper)后面,根据Server端的设置来控制每个功能在网页、iOS和Android端的打开或者关闭,然后通过控制GK开启的范围(用户的百分比)来实现功能逐步开放给所有的用户。

整个功能的发布过程分解如下:

1. 准备阶段:写好之后代码都已经在App里,且提交给app store审核通过,但是GK为关闭状态。等到上线后,先看拥有版本X的代码的App在关闭情况下的表现;这时程序的这块功能逻辑应该和上一个版本保持一致,并且没严重的不稳定性。

2. 员工测试阶段:先将其GK开启到Employee 20%~50% (对于普通用户仍然关闭),看在员工群体里新功能的表现情况。一般这个过程是几天,甚至是几周。我们把功能开启的员工群叫做实验组,功能仍然关闭的叫做参照组。

对比两组群体的核心数据表现,比如Facebook App的话一般是看用户的session length(App使用时长),news feed engagement(like或者comment数量),广告显示时长和收入指标 等;而Messenger则是看 平均发消息数,消息收发的耗时;另外对于性能方面相关的功能还会看:App启动时间,核心功能打开时间和App耗电量等数值。一般说来,对于重要功能,会在发布前就会对这些数据的变化进行一个预测,对于不符合预期的变化会重点排查。

3. 小范围发布阶段:等到在员工群体里,新功能被证明是有效,稳定,无害的时候,Facebook会将GK开启到1%~5%的用户范围。这里主要是两点考虑:

a) 对系统进行压力测试,对于一些新的后台功能(比如:语音消息,VoIP电话,视频聊天,或者 转账功能),看服务器是否能承受地住这么大的用户流量。一般来说:5%,10%,30%,50% 是常见的几个压力测试坎,过了50%基本上没有问题;

b) 看用户和媒体对于这个功能的评价。一般来说,PM会收集TechCrunch,VentureBeat,Wired上面的媒体评测,发到内部群里给大家分享;也有在Twitter上面搜索用户对此功能的讨论。

4. 全部发布阶段:等到服务器确认能抗住所有流量,这时会将GK开到95~98%的用户,同时依然保留2%的参照组作为对比用。这个阶段最重要的是看 data dashboard 上的各种监控数据,看是否和其他预期的一样,至少一些关键的指标不能出现下滑。

5. 收尾阶段:技术人员开始修改程序代码,把相应的GK和旧功能代码删除,这样下一个或者下下个新版本将拥有纯粹的新功能X代码。这一步,一般会经常1个月或者几个月的时间,而且最终纯粹的X代码发布会很谨慎,因为一旦上线给用户,功能X的出现会不受Facebook server的控制;假设突然出现App端的恶性bug,Facebook除了马上发布一个新版App,等待App Store审核,同时拜托用户马上升级之外没有任何办法。

有好的文章希望站长之家帮助分享推广,猛戳这里我要投稿

相关文章

相关热点

查看更多

关闭