神策数据创始人桑文锋：AARRR模型如何应用到产品各个阶段

1. 数据优化产品与用户研究优化产品的结果哪种会更好？

答：这两者并不是互相取代的关系，是互补的关系。对于产品原型阶段，我觉得主要还是要靠用户研究，找种子用户反复验证。而对于产品推出后，我们可以通过数据来驱动产品改进、运营分析、商业决策。同样，我们还可以通过系统化的收集用户行为数据，来便于做用户研究。

2. AARRR模型如何应用到产品的各个阶段？增长黑客的AARRR模型如何应用到产品的各个阶？

答：首先，我们来谈谈什么是增长黑客（Growth Hacking），从我的理解Growth Hacking强调用技术的手段，相比于传统电视、纸质媒体，通过较低的成本获取更多的用户。常用的方法是社会化媒体和病毒式传播。

对于一个互联网产品来说，最重要的可能就三件事情：拉新、留存、营收。

拉新

我们做好了一个产品，得有用户用吧，就是如何把用户吸引过来使用。这里又有三点：首先是获取用户（Acquistion），比如通过发软文、做广告，吸引用户跳转到你的产品。然后就是要把用户变成一个有效的用户，比如注册了帐号，这就是激活（Activation）。单靠这两个A，我们可能速度还不够快，还可以引入一个引荐机制（Referral），让这些已有用户邀请更多的新用户进来。

存留

有了用户，如果来了就跑掉，那就是猴子掰玉米，到头来还是瞎忙活。这就是留存（Retention）问题，促使老用户不断重复关键行为，比如购买商品。这里一个关键点就是改善产品体验，让用户满意。传统的一些电视广告之类的，用户被吸引过来，发现产品和宣传的差很多，那对用户是一种欺骗，后果就是留存率非常低。提升留存的根本还是要让产品真正给用户带来价值。总之是先有好的产品，再有好的留存，再有拉新。

营收

第三件事就是营收（Revenue）问题，有了好的产品，并有大量的用户，如果赚不了钱，那也是无法持续的。这里的基本原则是在保证增长的同时增加营收，如果客单价上去了，但客户大批量的流失，这就得不偿失了。

产品所处的阶段我觉得分成三个：原型阶段、产品完善阶段、大规模推广阶段。

原型阶段

对于原型阶段，是要借助mvp（minimium viable product）的理念，找一些种子用户，不断验证想法的可行性，去做一个真正能带来价值的产品。这个阶段我觉得Growth Hacking的理念发挥的作用不大。

产品完善阶段

对于产品完善阶段。我觉得首先要保证的是产品是高质量的，这里我是指如果有的功能，就是好用的功能，要么就宁肯不提供给用户。这个时候提升留存要高过拉新。如果已有的种子用户口碑非常好，那就可以引入拉新机制了。

大规模推广阶段

对于大规模推广阶段，那就是使用强力拉新。甚至有时候是以烧钱为手段的，快速垄断市场。

早期的数据团队如何构建，如何分工 

这里的早期要看多早。如果还处于原型阶段，这个时候不需要专门的数据团队，只需要有个工程师兼职出数据就好。最好借助已有的免费工具，如GA、百度统计、友盟这些，还有通过脚本的方式，去验证数据。产品正式对外发布，就需要有专门的数据负责人了，对数据需求负责。对于B-C轮的创业公司，就需要有专门的数据团队了，我建议还是要借助第三方工具，不是要从零构建整个数据平台。一方面是人难招，人少了不顶用，起码5个以上，另外要做上一年左右，才能有明显的效果，这个投入是比较大的。对于独角兽之后，有了钱，那就构建自己的数据团队，适合快速发展。

3. 数据分析的核心要素是什么？

答：数据分析的核心要素我觉得是三点：数据采集、数据建模、数据分析应用。

一、数据采集

首先来说一下数据采集，我在百度干了有七年是数据相关的事情。我最大的心得——数据这个事情如果想要做好，最重要的就是数据源。数据源这个整好了之后，后面的事情都很轻松。

用一个好的查询引擎、一个慢的查询引擎无非是时间上可能消耗不大一样，但是数据源如果是差的话，后面用再复杂的算法可能都解决不了这个问题，可能都是很难得到正确的结论。

好的数据源我觉得就是两个基本的原则，一个是全，一个是细。

全即多种数据源

就是说我们要拿多种数据源，不能说只拿一个客户端的数据源，服务端的数据源没有拿，数据库的数据源没有拿，做分析的时候没有这些数据你可能是搞不了的。

另外，大数据里面讲的是全量，而不是抽样。不能说只抽了某些省的数据，然后就开始说全国是怎么样。可能有些省非常特殊，比如新疆、西藏这些地方它客户端跟内地可能有很大差异的。

细即多维度

细其实就是强调多维度，在采集数据的时候尽量把每一个的维度、属性、字段都给它采集过来。比如：像where、who、how这些东西给它采集下来，后面分析的时候就跳不出这些能够所选的这个维度，而不是说开始的时候也围着需求。

根据这个需求确定了产生某些数据，到了后面真正有一个新的需求来的时候，又要采集新的数据，这个时候整个迭代周期就会慢很多，效率就会差很多，尽量从源头抓的数据去做好采集。

二、数据建模

有了数据之后，就要对数据进行加工，不能把原始的数据直接暴露给上面的业务分析人员，它可能本身是杂乱的，没有经过很好的逻辑抽象的。这里就牵扯到数据建模。

首先，提一个概念就是数据模型。

许多人可能对数据模型这个词产生一种畏惧感，觉得模型这个东西是什么高深的东西，很复杂，但其实这个事情非常简单。数据模型就是对现实世界的一个抽象化的数据的表示。

这个数据模型是用于满足你正常的业务运转，为产品正常的运行而建的一个数据模型。

但是，它并不是一个针对分析人员使用的模型。如果，非要把它用于数据分析那就带来了很多问题。比如：它理解起来非常麻烦。另外，数据分析很依赖表之间的这种格式。

在数据分析领域领域领域，特别是针对用户行为分析方面，目前比较有效的一个模型就是多维数据模型，“在线分析处理”这个模型。它里面有这个关键的概念，一个是维度，一个是指标。

维度比如城市，然后北京、上海这些一个维度，维度西面一些属性，然后操作系统，还有IOS、安卓这些就是一些维度，然后维度里面的属性。通过维度交叉，就可以看一些指标问题，比如用户量、销售额，这些就是指标

三、数据分析应用

有了前面的基础，再做分析就比较容易了。只要把想要的一些东西进行组合分析就可以了。像互联网领域常见的分析方法有多维事件分析、漏斗转化、用户留存等。至于写好分析报告，我觉得一方面要把总体情况给描述出来，特别是核心指标，另一方面要分析对核心指标影响的关键因素的情况。最好能够再提出建设性的意见。

4. 通过大数据分析来做预测，是怎么看待”时间维度”这一因素的?

答：大数据分析做预测，是用了凡事都有规律可循，如果只是一个随机的东西，那就很难预测了，现实并非如此。比如我们自己的官网，工作日和周末具有明显不同的数据特征，如果不进行特别的运营活动的话，根据历史增长率，上周同日，上周昨日，昨日的数据，就能对未来一天的数据做出判断。

时间段选取的标准是历史数据是否能够和未来的特征有类似的规律，如果是不能甚至相反的，就不能用，用了反而起副作用。

还有一点考虑就是计算代价，有时候确实是历史数据越多越好，但计算开销太大了。如果我们只选择最近一个月的数据，就能达到90%的效果，就没有必要用一年的数据获取91%的效果，性价比的问题。

5. 从业者们自己是如何理解“大数据分析”的？

答：首先，我来谈谈我对大数据的理解，分为大数据概念和大数据思维。

我把大数据的概念总结为四个字：大、全、细、时。

我们先来看一组数据：

 百度每天采集的用户行为数据有1.5PB以上

 全国各地级市今天的苹果价格数据有2MB

 1998年Google抓取的互联网页面共有47GB（压缩后）

 一台风力发电机每天产生的振动数据有50GB

百度每天的行为数据1.5个PB够大吧？我们毫无怀疑这是大数据。但全国各个地级市今天的苹果价格只有2MB大小，是典型的小数据吧？但如果我们基于这个数据，做一个苹果分销的智能调度系统，这就是个牛逼的大数据应用了。Google在刚成立的时候，佩奇和布林下载了整个互联网的页面，在压缩后也就47GB大小，现在一个U盘都能装的下，但Google搜索显然是个大数据的应用。如果再来看一台风机每天的振动数据可能都有50GB，但这个数据只是针对这一台风机的，并不能从覆盖面上，起到多大的作用，这我认为不能叫大数据。

这里就是在强调大，是Big不是Large，我们强调的是抽象意义的大。

我们再来看关于美国大选的三次事件：

1936年《文学文摘》收集了240万份调查问卷，预测错误

新闻学教授盖洛普只收集了5万人的意见，预测罗斯福连任正确

2012年Nate Silver通过互联网采集社交、新闻数据，预测大选结果

《文学文摘》所收集的问卷有240万，绝对是够大的，但为什么预测错误了呢？当时《文学文摘》是通过电话调查的，能够装电话的就是一类富人，这类人本身就有不同的政治倾向，调查的结果本身就是偏的。而盖洛普只收集了5万人的意见，但是他采用按照社会人群按照比例抽样，然后汇集总体结果，反而预测正确了。因为这次预测，盖洛普一炮而红，现在成了一个著名的调研公司。当然，后来盖洛普也有预测失败的时候。到了2012年，一个名不见经传的人物Nate Silver通过采集网上的社交、新闻数据，这是他预测的情况和真实的情况：

两者是惊人的接近的。

从这点我是想强调要全量而不是抽样，大数据时代有了更好的数据采集手段，让获取全量数据成为可能。

在2013年9月，百度知道发布了一份《中国十大吃货省市排行榜》，在关于“××能吃吗？”的问题中，宁夏网友最关心“螃蟹能吃吗？”内蒙古、新疆和西藏的人最关心“蘑菇能吃吗？”浙江、广东、福建、四川等地网友问得最多的是“××虫能吃吗？”而江苏以及上海、北京等地则最爱问“××的皮能不能吃？”。下图是全国各地关心的食物：

用户在问什么能吃吗的时候，并不会说“我来自宁夏，我想知道螃蟹能吃吗”，而是会问“螃蟹能吃吗”，但是服务器采集到了用户的IP地址，而通过IP地址就能知道他所在的省份。这就是数据多维度的威力，如果没有IP这个维度，这个分析就不好办了。而现有的采集手段，能够让我们从多个维度获取数据，再进行后续分析的时候，就能对这些维度加以利用，就是“细”。

我们现在对CPI已经不再陌生，是居民消费价格指数（consumer price index）的简称。我们努力工作，起码要跑过CPI。

那你有了解过CPI是怎么统计的吗？这里包括两个阶段，一个是收集商品价格数据，一个是分析并发布数据。我从百度百科上了解到，中国CPI采样500多个市县，采价调查点6.3万个，近4000名采价员，次月中旬发布报告。我还曾找国家统计局的朋友确认了这个事情。

而在美国有一家创业公司叫PremiseData。它通过众包方式，25000个采价员（学生、收银员、司机等），使用手机APP采集数据，每条6~40美分，比美国政府数据提前4~6周发布。

这就是“时”，强调实时收集数据和实时分析数据。当然，在CPI的例子中，我们可以让价格上报更智能一些，不需要人工的方式。

从上面的大、全、细、时四个字，我们就可以对大数据的概念有个较为清晰的认识。这四点主要强调的数据的获取和规模上，和以往传统数据时代的差异。有了这个基础，我们还要看怎么对大数据加以利用。这里就要看看大数据思维。我们也来看两个例子。

85前应该都用过智能ABC，一种古老的输入法，打起来特别慢。到了2002年左右，出了一个叫紫光的输入法，当时我就震惊了。真的输入很快，仿佛你的按键还没按下去，字就已经跳出来了。但渐渐的发现紫光拼音有个问题是许多新的词汇它没有。后来有了搜狗输入法，直接基于搜索的用户搜索记录，去抽取新的词库，准实时的更新用户本地的词库数据，因为有了大量的输入数据，就能直接识别出最可能的组合。

我们以前都用纸质的地图，每年还要买新的，旧的地址可能会过时，看着地图你绝对不知道哪里堵车。但有了百度地图就不一样了，我们上面搜索的地址都是及时更新的，虽然偶尔也会有被带到沟里的情况，但毕竟是少数。可以实时的看到路面堵车情况，并且可以规划防拥堵路线。

我们想想这种做事方式和以前有和不同？

我们发现不是在拍脑袋做决定了，不是通过因果关系或者规则来决定该怎么办了，而是直接通过数据要答案。我们获取的数据越全面，越能消除更多的不确定性。也就是用数据说话，数据驱动。

在百度文化的29条中，我第二认可的一条就是“用数据说话”，数据有时候也会欺骗人，但大部分时候它还是客观冷静的，不带有感情色彩。据说在硅谷用数据说话都是一种很自然的工作习惯，但你放眼望去你周围，你会发现许多没有数据的例子，拍脑袋的，拼嗓门的，拼关系的，拼职位的，这一点都不科学。

那我们再来看看互联网领域的数据驱动。许多公司的情况是这样的：

不管是运营、产品、市场、老板，都通过数据工程师老王获取数据，老王忙的痛不欲生。但数据需求方都对数据获取的速度很不满意，有的等不及，还是决定拍脑袋了。这样极大的阻碍的迭代的速度。

还有的公司情况是这样的：

对老板来说，有个仪表盘还不错，终于知道公司的总体运营情况了，可以基于总体情况做决策了。但如果发现某天的销售额下跌了20%，肯定是要安排下面的人追查的。对于实际干活的运营、产品同学来说，光看一个宏观的指标是不够的，解决不了问题，还要想办法对数据进行多维度的分析，细粒度的下钻，这是仪表盘解决不了的。

那么理想的数据驱动应该是什么样子的？应该是人人都能够自助式（Self-Service）的数据分析，每个业务人员和数据之间，有一个强大的工具，而不是苦逼的老王。或者只是能看到数据的冰山一角。在数据源头上，又可以获取到全面的数据。

我们接下来看看现有的解决方案上，离真正的数据驱动还有多远的距离。

常见的方案有三种：

我们先来看看第三方统计服务，目前国内用的比较多的有三家，友盟、百度统计和TalkingData，他们都类似Google Analytics（简称GA，谷歌分析）。

这些工具的优势是使用简单，并且免费。

劣势是有以下几点：

数据源：只能覆盖前端JS/APPSDK记录的数据，无法覆盖服务端和业务数据库的数据；                  

分析能力：只能覆盖宏观通用分析，使用后还需要数据团队满足运营/产品的各类定制化的需求；

安全：规模稍大一点的公司，不想把核心数据放在第三方平台。

第二种是使用数据库写SQL，这种在创业公司用的比较多：

我们直接在业务数据库中写SQL进行查询，然后导出为中间数据，再放到Excel或者其他报表工具上进行绘图分析。这种方式的好处是可以直接分析业务数据库的数据，但最大的不足在数据记录的历史状态被覆盖了。我们用下面的一张图来描述：

业务数据库是设计用来处理高并发、小批量的用户请求的，而数据仓库强调的是少量查询，但是大批量的。用人类进化的图来说，业务数据库只会存放当前的状态，而数据仓库会存放从猿猴到人的整个过程，原则上说，数据仓库能够恢复到数据库的任一时刻的横切面。

这样你就明白让业务数据库去做数据仓库，是有很多的问题的，这里就不细说了。

第三种方式是基于日志写统计脚本，这种在BAT这样的大公司用的比较普遍，我在百度处理的数据方式主要是这一种。

这种方式是和业务数据库解耦的，各干各的事。不足是开发效率比较低，准确性也无法保证（没有人去做Code Review、数据Diff）。并且，这是一件很有技术门槛的事，一是打好日志很难，二是数据流的管理很难。

差不多在2012年，在我干了三四年的数据的事情之后，渐渐的认识到数据处理其实就是一条流，并且在以后的实践中不断的坚信这一点。按照数据的流向，可以把数据处理分成5个阶段：

时间关系，我只说一下数据采集、建模两个环节。

在百度做了这么多年的大数据，最大的心得就是数据这个事情如果想做好，最重要的就是数据源。数据源想做好，一是要全，一是要细。也就是我在前面讲解大数据概念时提到的其中两点。

数据模型很重要，我们用一个形象的例子：

如果按照地心说，需要有40个大圆套小圆，才能演绎九大行星的运行轨迹。但是通过日心说，只要9个椭圆就能搞定了。

对于业务数据表，为了达到线上服务的需求，一般会设计成这个样子：

但如果把这个数据模型暴露给业务人员，光理解它都需要几个月，并且中间还在不断变化，变化了相关的SQL任务都要修改。

这里就要引出数据立方体：

我们可以把数据抽象为维度和指标，像图中的城市和操作系统就是两个维度，而成单量、销售额等就是指标，通过维度的组合，我们可以看这一切片下的数据情况。这只是一个例子，真实的维度可能有几十个，指标可能也有很多。

通过这种模型，会比较有效的处理用户数据分析的需求。具体来说，我们可以把用户行为抽象为三个部分：

Event Type + Properties + UserID

Event Type表示行为类型，比如提交订单。Properties表示这个行为的相关属性，比如操作系统版本，屏幕宽度，运费，商品ID等。UserID是表示用户。通过UserID，我们又能讲其和用户属性关联起来，包括用户出生日期、性别等。

这里我们看一下一个数据分析平台的总体架构：

中间部分是上面所说的五个环节。其它还有三个子系统，监控子系统保证整个系统的稳定运行，元数据就像人的心脏，记录了数据的格式、就绪状态。而调度器就像人的大脑，用来管理任务的依赖关系。时间有限，我这里就不详细讲解了。

如果做到了上面这些，就实现了一套不错的大数据分析平台。这里要说的是，起码需要4~5个有经验的数据工程师，做上半年以上，能做一个60分的产品。

点“阅读原文”，看更多干货