GrowthHack轶事：Facebook是怎么开发活跃10亿人的经典功能

【编者按】本文作者覃超，前FB工程师，现为FREES技术合伙人。本文是 Growth Hacking 的最后一篇：关于growth hacking 的轶事、趣事、囧事，以及那些 Facebook 曾经踩过的坑。关于Growth Hacking的完整系列，可以进入覃超的雷锋网专栏页面查看。

多谢各位朋友一直对于我之前文章的鼓励和鞭策，让我一直有动力逼着自己在周末抽出时间来写写文字。总共四篇大概跨度4个来月，多谢大家对于我的容忍 。

言归正传，先说一个有意义的点：“从数据反向推导功能迭代”。

数据反向推导功能

有些时候，别人会问我，既然Facebook对于数据这么重视，有没有从数据中洞察出什么有用的东西，然后直接反过来指导产品功能的改变？ 你还真猜对了！的确，在 Facebook 中有那么几个功能是从 data dashboard 里分析出来，然后 growth team 的工程师自己来开发并且最终上线的。这就是说：这几个功能并未通过产品部门来提议，而从data和growth组中直接诞生而来。

最重要的功能，就是 “People you may know”：它出现在Facebook WWW页面的右侧，广告栏的上方：

Friend request 中：

当然，在移动上也有：

LinkedIn上面也有类似的：

当然微博和人人网也有：“你可能感兴趣的人”。

“People you may know” 这个功能的诞生其实大有来头

早在2007-2008，facebook growth team刚刚建立的时候，他们想弄清一个问题：“为什么在平台上一部分用户特别活跃而一部分用户特别不活跃？” 很多人会直接说：“这些人天生的呗。就有一些人喜欢用Facebook，一些人不喜欢！” 其实如果是单个用户的话，上述的观点倒是可以站住脚。但是如果你的用户群在上千万和上亿的规模，则自然人的性格差异可以被大大淡化。

于是，Facebook data的人（还是由中国的一个工程师主导）做了下面的分析：

1. 他们把 highly active 和 inactive 的人找出来，分成两组（highly active VS inactive），每个组大概几千万用户。

2. 列出一些可能影响结果的特征值（比如：在线时长、发的文字状态数、发照片数、etc）

3. 在这两个组中把这些特征值一一进行对比，从中找出差异最大且最可能有影响力的指标。

经过一个团队大概两个多月的分析，他们得出最终也是之后对FB growth产生最大影响的结论 --- Facebook上影响用户活跃度最重要的因素是：

a. The number of friends：用户的好友数；b. The profile info completeness：用户的个人信息的完备程度。

于是，growth组决定lead一个新功能，其目标就是给每个Facebook用户来自动推荐好友，让其好友数增加。于是，就有了 “People you may know”。

Growth组很快就开发了功能原型，算法用的最朴素的算法 --- 根据 mutual friends 来推荐可能的好友。

功能开发好之后做了 灰度发布，开始挑了 5% 的用户做测试，观察他们的表现。试验发现：”小白鼠“用户们平均好友数不断增加，然后活跃度也渐渐提高，其中一部分也开始变成高活跃用户。

很多年过去了，直到今天，“People you may know”也一直是Facebook growth强劲有力的助推器，持续不断地将用户的平均活跃度提到新高，特别是对于新加入平台的用户，帮助作用更加显著。

另一方面，profile info的完整性上，Facebook也针对profile信息不完整的用户来给予提醒，并且给出完整度的打分。这些技巧也被其他公司效仿，用到了今天大部分的产品上，比如微博，人人网，甚至是新生的社交网络脉脉：

（上图：“你的资料完善程度91%，待完善“）

当然，需要强调的一点是：对于现在公司自己的产品，除了模仿上述的”推荐好友“和”完善资料“之外，更加重要的是要学习“渔”，从自己公司具体的数据反向推导出来功能改进点。

可惜现在国内的人和国内的公司很少有这样去做的！ 除了知乎。

之前和知乎的创始团队聊天的时候，了解到一个小故事（他们之前一直和FB的工程师有交流，而他们模仿的quora也一直是FB的嫡系）：

知乎的工程师也类似从数据出发，进行数据推导，发现一个特点：“如果一个知乎用户回答问题数超过三个的时候，他就会对知乎有粘性同时保持一定的活跃性”。于是，虽然他们没有开写程序来推荐可能感兴趣的问题，但是他们以此改变了自己的运营策略，更加积极地叫运营人员去邀请“有货的人”和“已经回答过问题”的人去回答相关的问题；直到让此知乎用户回答超过三个问题（这时他就基本上成为了一个稳定的活跃用户）。由此可知，知乎的用户增长是有原因的。

当然，Facebook也是，很多国内的人对我说，Facebook的产品形态牛逼，里面的人做产品的思维牛逼，之类的。但是我想反复强调的一点是：“Facebook所有的一切增长都是人工调教的结果”。

没有人（比如Zuck）或者没有哪个公司（即使Facebook）可以随随便便地神奇地掌握产品迭代的方向。

用A/B test来戏耍TechCrunch

接下来说一个诙谐幽默的事情。

在我任命FB的四年间，Evan Priestley 一直是我心目中的编程之神。

他在Facebook中贡献了无数的代码，速度之快堪称是FB一哥。另外Evan的代码极其简洁美观，给人的感觉就是“可远观还不可亵玩焉”。

当年还有个笑话就是：“某中国人在看Evan的代码时，觉得写得非常漂亮。但是突然看到中间一小段比较丑，git blame后一看发现不是Evan而是另外一个中国大牛 liuyongyan刘永延写的” --__-- （故事本身权威性不可考，大家笑笑即可。）

Evan 主导开发了FB的很多项目，比如 Task，Code review系统，开源的JS框架 Javelin，还有 Facebook lite 等。他2011年中期离开Facebook，现在一直在维护开源的 phabricator 系统。Phabricator是他多年以来的心血，也几乎是Facebook最高档次的engineering作品。所以，我推荐所有中国的互联网技术公司都来使用下 phabricator。我自己和几个峰瑞资本的同事给phabricator做了一个汉化版，同时总结了之前在FB积累下来的 best practices，准备以后开源出来。

我自己和Evan现实中只打过3-4次交道，请教过他关于CSS override的问题以及Javelin的一些设计。他是一个特别geeky同时风趣的人，这在他的code review中有明显的体现。我加入一年没到，他就离开了Facebook，而我对于他模糊的印象就是：一个加州阳光的午后，他独自抱着一碗Salad，在办公室自己的电脑上边吃边写。

众所周知，之前TechCrunch和Facebook的关系一直不好，原因是TechCrunch一直喜欢乱报Facebook的新闻（很多时候，报道的真实性和准确性都很低）。因此，Facebook的人一直不爽TechCrunch。

一次Hackathon，Evan想起一招：“来！我们回敬一下TechCrunch。” 他的方法很独特也很天才：利用Facebook的灰度发布系统！

Facebook的灰度发布系统code name：gatekeeper，当时支持的针对用户的限制条件：

– Employees only– By country– Age– IP– East coast/West coast

Evan 机智地添加了两个新选项 “– Anyone but TechCrunch” 和 ”techcrunch only“（本质也就是根据 TechCrunch office所在的IP段来判断）。

也就是说将一些功能开放给所有用户，除了TechCrunch，也就是任性地对其做一些简单的封锁；或者将一些搞笑功能只开放给 techcrunch。

后来更绝的事情发生了。Evan在一次Hackathon里开发了一个新功能：Fax photo。也就是对照片可以支持传真到你指定的传真号，不过要付费一美元。考虑到当时是09年，email早已普及，iPhone也推出到第四代，fax已经很少有公司使用，所有fax photo压根不准备推出给用户，只是用来戏耍TechCrunch。

于是 2009年9月10日，Fax photo正式“上线”，gatekeeper对其的设置是：TechCrunch only。没过多久，TechCrunch就开始报道了（因为当天Facebook还发了其他几个功能，TechCrunch看得很紧）。于是，一位编辑马上发了篇文章来谈试用”Fax photo“的感受，还附带了fax成功的照片纸片；再接着大肆抒发对于此功能的鸡肋性的吐槽 ，说这年头还来开发这种过时功能。

有兴趣的可以去看看原文：Facebook Now Lets You Fax Your Photos. I Have No Idea Why Anyone Would Want To Do This

文章出炉之后，用户们陆续在下面回复说没有“Fax photo”的功能，你们是不是搞错了。编辑开始也纳闷，过了一天后，他们的员工在自己家里的电脑上使用Facebook才反应过来。第二天他们反复确认之后发现，的确是只有TechCrunch才能看到这个功能。TechCrunch后续联系了FB的PR部门，解释了半天，换来的只是PR人的不理解和欢快的笑声。于是，TechCrunch后来又补了一篇：Yeah Ok, So Facebook Punk'd Us正式宣布和承认自己被Facebook戏耍。

这件故事本来也只是一个小插曲罢了，但是我却觉得从中可以不经意地察觉到硅谷精神的几个特点

1、即使媒体 TechCrunch，报道功能的时候也比较注重细节，编辑们还会亲自去fax一张来验证这个功能的确可用。这点我觉得不仅是国内的媒体朋友，还包括很多互联网公司的产品经理也应该去多多学习；

2、极客精神的体现。对于TechCrunch的不爽，FB的工程师Evan不是用骂街的方式来解决，而是在Hackathon开发了一个戏耍功能，来用一个程序员似的方式来回击TechCrunch。的确很有创造力，也给Facebook的工程师文化来了一次很好的公众宣传。

3、TechCrunch也非常实事求是。即使出了洋相，也没有把文章撤掉，只是继续在原来文章基础上更新，来还原事情的真相。

上面的这些硅谷公司的“软实力”我觉得一直是国内的公司所缺乏和轻视的，这些也正是我在FB多年过的工作里，经常在不经意间震撼我的地方。

Facebook在Growth Hacking上踩过的坑

最大的坑来自于数据采集、处理和展示的正确性。

总所周知，这个数据采集、处理、还有展示是一个比较枯燥的过程，一般的程序员都不太乐意去做这件事。

技术人员一般分成两类：

A - 喜欢写各种功能，看得见摸得着的功能，然后发布给用户；

B - 玩一些牛逼的后台技术，比如分布式，或者处理大数据高并发，或者实现一套推荐算法。

而一般数据采集的功能、处理和展示的环节一般在国内的技术公司被认为是下等技术人员去做的角色。好在Facebook还不断强调internal tools的重要性，使得我们一直有好的工程师去加入我们的 tools & infrastructure 团队。但是和需要完成的任务比起来，人手依然捉襟见肘。

另外数据采集中的埋点工作也是一个蛋疼的事情。我在开发 Facebook Messenger 的时候，就很不喜欢写完大堆的功能代码后，还要去把逻辑梳理一次，在必要分支上埋上点。情绪上的低落经常会导致bug的发生，尤其是在产品迭代非常快工期很紧的时候。

最搞笑的坑来自于 2011 年的11月， 当时我们在全身心地和Google+打仗。

有一个地方的数据就是不太理想。David Wei（我刚进Facebook的mentor）觉得可能数据处理和展示有问题，不然很难解释我们一个特别好的功能上线为什么相应的数据没有改善。但是那块数据采集展示的代码已经写了2年之久，后来一直没人改过，中间也有人陆陆续续地去检查过，应该没问题。David还是不太放心，叫了一个很老练也很细心的华人工程师又去看一次（他是07年加入的人，做事很踏实，但是不爱说话 --- 这在一个老美文化的企业是不太好混出头的）。他立马花了半周的时间去仔细检查代码，果然数据在sampling的时候有bug。而且事后发现这一部分问题已经有2年多的历史，且两年来，错误的数据和信息一直在错误地指导着产品的迭代和完善工作......（跨度两年）

针对这些坑，我一直以来觉得最好的办法就是不埋点，甚至连整个数据采集和展示的infrastructure都不用自己去做（和去维护）。

这方面的创业公司已经极大丰富而且进步飞快，像国内的友盟和AppAnnie基本上就是标配，同理也有国外被收购的 Crashlytics，能运用现成的企业服务肯定是事半功倍。这里还是强烈推荐 GrowingIO，因为产品好团队强：

《LinkedIn大佬张溪梦的前世今生》；「GrowingIO」介绍一家以技术为核心的创业公司

对于 Simon张溪梦 和 GrowingIO 的报道国内已经越来越多，外加公司背后还有一线牛逼的资本：Reid Hoffman、Graylock、邵亦波和经纬创投，整个公司的momentum非常强劲。正巧前几天，GrowingIO还发布了自己的新产品：干货！GrowingIO产品发布会实录，含车品觉左凌烨演讲推荐有意于有效增长业务的公司都去试用一下他们的产品。

Growth Hack的人员配置和组织架构

这个问题是我在各大公司里进行讲座的时候被问及最多的问题：“Facebook的growth团队大概怎么配比？和产品或者技术部门怎么分工与协作呢？” Facebook的 growth team 架构可以参照这个系列文章的前篇：《关于神秘的Growth Hacking，Facebook都做了什么？（下）》。

这里强调的是整个growth是直接汇报给Zuck的，可见Zuck对于增长和数据的重视程度。这使得整个 data driven 和 growth hack 的思想贯穿于整个Facebook的产品和技术部门。大家在上线一个critical feature和重大改版的时候，都会习惯性地加上 A/B test。我觉得这是 growth hack 能在FB盛行起来的基础。

FB采用的人员配置属于独立型，也就是有专门的 growth hack 团队，然后 growth 里的人会参与产品和技术团队的会议，并且在里面贡献自己的看法。当然，后续的事情还包括给我们工程师来解释一下统计系统的使用，以及给PM们来完善dashboard。

针对初创公司来说，Alex Schultz 明确建议不应该有专门的 growth team，而是整个公司的人都是 growth hackers，也就是整个公司就是 growth team。每个人来把自己的想法快速发布出来（minimum viable feature），然后丢到市场里去接受用户的检验。然后根据数据上的反馈来快速迭代和改进自己的产品。

Growth Hack VS 创业公司

这是本篇的最后一点。借用英语（或者我写托福文章）的常用语句：last but not the least, 这也是对创业公司而言最为重要的一点。

首先要明确的是：growth hack 是加成而不是基石，也就是说是 1到n 的变化，而不是 0到1。

我在平时的演讲和技术分享中还不断地提到growth hack中的有些技巧（比如灰度发布和 A/B test）不仅不适用于初创公司，而且对于这些公司还是有害的。因为灰度发布和 A/B test 增加了开发和维护的成本，而且让产品上线速度变慢。针对这些地方，有必要再次强调一下，虽然 growth hack 现在是一个很火很性感的概念，但是growth hack里面的很多技巧并不适合创业公司（特别是上线还没超过半年，各种功能形态还不稳定的产品）。

系统说来：

首先看 Chamath （Facebook growth 的首位掌门人）在一次演讲中给出上图一样的关于 growth hack 的归纳。

对于初创公司而言：不管是 magic moment（用得很爽的一次体验）还是 Core product value（产品提供的最核心价值）都不是 growth hack 所能提供的。所以最终的本质还是：产品要好，要能满足用户的刚需。

接下来：

“Sean Ellis”提出上面关于公司发展的三步：满足市场需求 --> 转型增长 --> 增长。

也就是说，任何产品和创业在开始的半年或者一年期，都是在一种天马行空或者问卷调查式的摸索当中。产品随时可以根据市场的变化而变化，或者直接推翻重来。所以growth hack的很多手法在最初的产品迭代中显得鸡肋而又浪费资源。历史的事实也证明：Facebook在产品上线4年后才有growth hack的team，Airbnb和Uber的growth也是去年和今年才慢慢组建起来的，所以切记（特别是国内急性子的创业者）：

growth hack对于初创公司是一把双刃剑。

那创业公司该如何拥抱 growth hack ？

先来看硅谷风投的无冕之王 Marc Andreessen 的话：

Marc Andreesen:“…the life of any startup can be divided into two parts — before product/market fit and after product/market fit.” He goes on to write: “When you are BPMF (before product / market fit), focus obsessively on getting to product/market fit. Do whatever is required to get to product/market fit. Including changing out people, rewriting your product, moving into a different market, telling customers no when you don’t want to, telling customers yes when you don’t want to, raising that fourth round of highly dilutive venture capital — whatever is required.” --- from Marc's blog

简单翻译过来，创业公司的产品迭代分成两个环节：产品满足市场需求前（BPMF）和满足之后（APMF）；在 BPMF 阶段，主要精力集中在研究和寻找市场和用户的需求，据此野蛮开发快速迭代。

就算要大改版，要开人，要换市场和方向，要拒绝用户，甚至是为了融资稀释大额股份都在所不辞，直到撑到发现市场需求同时产品迭代得满足市场需求为止。接下来，才到了真正实现产品有效增长的时期。

从创业公司的增长阶段来简要分类

如上图——

第一阶段 “Startup”：主要目标是完成产品的快速开发和迭代，以用来验证产品是否满足用户的核心需求。

这个时期需要花钱吸引用户，甚至还能短暂容忍 CPA > LTV （CPA: cost per acquisition 每个用户的拉新费用；LTV：life time value：用户这辈子在平台上的消费）。在产品决策上以拍脑袋想+收集用户反馈为主；基本上不需要用什么growth hack的技巧（除了收集和展示好数据即可：比如日活、月活、PV、UV）。典型公司：国内做VR创业的公司；或者做新形态社交的app；etc

第二阶段 “Transition”：这一阶段的基本是产品已经能够符合市场的需求，于是开始转型 growth——这里的核心是根据公司的具体业务建立起一套完善的数据指标和dashboard。

然后开始将 growth hack 的方法融入团队的血液中。拍脑袋和野蛮迭代逐渐被 data driven 所取代。用户的留存这时是产品改进的王道。典型公司：国内各种仿magic的公司；仿thumbtack的公司；etc

第三阶段 “Growth”：这一段，产品基本上拥有大量且稳定的活跃用户，并且产品功能已经相对稳定。

由于国内竞争环境的特殊性，经常会有成熟的竞品出现，同质化竞争比较激烈。典型公司：Nice vs In；各类团购或者电商；去哪儿 vs 携程 etc（好在现在国内的同质化竞争对手都在纷纷抱团合并。）

如上所述，处于什么阶段就做什么事情，创业的时候亦如此。

尤其想强调的是在上面的第二个阶段，关键是要提高产品的留存，而决定留存的关键指标还是功能满足需求并且细节打磨得够好。如果留存有保证了，后续的growth hack才能有效地开展拳脚。如果不看留存，只是一味地烧钱去吸引新用户，这只是饮鸩止渴，最后结局会是灾难性的。所以，重复那句话——

growth hack对于初创公司是一把双刃剑：要根据公司所在的具体阶段来分析growth所要采用的具体技巧。

写在后面

啊！终于写好了。我觉得好累呀。我想你们也看累了，辛苦。

这一个 growth hack 的系列就在这里截止。 从8月份开始写，现在已经一晃眼已经12月份了，时光如梭。 New year resolution 还有不少没有完成的，希望能再接再厉。

另外，关于 growth hack，特别是growth hack在FB的实战经验，之前在一些技术会议上和给一些公司（聚美、出门问问、七牛、Evernote、etc）里给过几次讲座。这里附带我最近一版的 slides。

对了，如果你也想邀请我来你们公司做growth hack的讲座，可发邮件联系，最后打一个小广告：最近我在 FreeS 峰瑞资本工作（其实已经干了快4个月了，有好的项目欢迎推荐，有好的创业团队，我也希望认识你们）。期待我有机会了解你们牛逼的想法和惊艳的产品。我的邮箱：qinchao@freesvc.com。