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分的產品。

點“閱讀原文”，看更多干貨

總結

以上是生活随笔為你收集整理的神策数据创始人桑文锋：AARRR模型如何应用到产品各个阶段的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。