對于市場、運營這些同學(xué)來說，基本的數(shù)據(jù)運營是要會的。

比如，我們發(fā)現(xiàn)某一天的用戶量跌了20%，這個時候肯定不能放著不管，也不能僅僅憑借拍腦袋去做決策，而是要查一查這個問題出在哪。

這個時候，只看一個宏觀的數(shù)那是遠遠不夠的，我們還要對這個數(shù)據(jù)進行切分，按地域、按渠道，按不同的方式去追查，看到底是哪少了，是整體少了，還是某一個特殊的渠道獨特的地方它這個數(shù)據(jù)少了。

分析了原因，才能針對性地找到解決辦法?，F(xiàn)在越來越多的公司都選擇用數(shù)據(jù)驅(qū)動來輔助制定決策。

數(shù)據(jù)分析沒有那么難，可以分成一個一個數(shù)據(jù)金字塔，自底向上的是三個部分：第一個部分是數(shù)據(jù)采集，第二個部分是數(shù)據(jù)建模，第三個部分是數(shù)據(jù)分析，我們來分別看一下。

1，數(shù)據(jù)采集

首先來說一下數(shù)據(jù)采集，我在百度干了有七年是數(shù)據(jù)相關(guān)的事情。我最大的心得——數(shù)據(jù)這個事情如果想要做好，最重要的就是數(shù)據(jù)源。

數(shù)據(jù)源這個整好了之后，后面的事情都很輕松。

好的數(shù)據(jù)源我覺得就是兩個基本的原則，一個是全，一個是細(xì)。

全：就是說我們要拿多種數(shù)據(jù)源，不能說只拿一個客戶端的數(shù)據(jù)源，服務(wù)端的數(shù)據(jù)源沒有拿，數(shù)據(jù)庫的數(shù)據(jù)源沒有拿，做分析的時候沒有這些數(shù)據(jù)你可能是搞不了的。另外，大數(shù)據(jù)里面講的是全量，而不是抽樣。不能說只抽了某些省的數(shù)據(jù)，然后就開始說全國是怎么樣?？赡苡行┦》浅Ｌ厥?，比如新疆、西藏這些地方它客戶端跟內(nèi)陸可能有很大差異的。

細(xì)：其實就是強調(diào)多維度，在采集數(shù)據(jù)的時候盡量把每一個的維度、屬性、字段都給它采集過來。比如：像where、who、how這些東西給它采集下來，后面分析的時候就跳不出這些能夠所選的這個維度，而不是說開始的時候也圍著需求。根據(jù)這個需求確定了產(chǎn)生某些數(shù)據(jù)，到了后面真正有一個新的需求來的時候，又要采集新的數(shù)據(jù)，這個時候整個迭代周期就會慢很多，效率就會差很多，盡量從源頭抓的數(shù)據(jù)去做好采集。

2，數(shù)據(jù)建模

有了數(shù)據(jù)之后，就要對數(shù)據(jù)進行加工，不能把原始的數(shù)據(jù)直接暴露給上面的業(yè)務(wù)分析人員，它可能本身是雜亂的，沒有經(jīng)過很好的邏輯抽象的。

這里就牽扯到數(shù)據(jù)建模。首先，提一個概念就是數(shù)據(jù)模型。

許多人可能對數(shù)據(jù)模型這個詞產(chǎn)生一種畏懼感，覺得模型這個東西是什么高深的東西，很復(fù)雜，但其實這個事情非常簡單。

在數(shù)據(jù)分析領(lǐng)域領(lǐng)域領(lǐng)域，特別是針對用戶行為分析方面，目前比較有效的一個模型就是多維數(shù)據(jù)模型，“在線分析處理”這個模型。它里面有這個關(guān)鍵的概念，一個是維度，一個是指標(biāo)。

維度比如城市，然后北京、上海這些一個維度，維度西面一些屬性，然后操作系統(tǒng)，還有iOS、安卓這些就是一些維度，然后維度里面的屬性。

通過維度交叉，就可以看一些指標(biāo)問題，比如用戶量、銷售額，這些就是指標(biāo)。比如，通過這個模型就可以看來自北京，使用iOS的，他們的整體銷售額是怎么樣的。

這里只是舉了兩個維度，可能還有很多個維度。總之，通過維度組合就可以看一些指標(biāo)的數(shù)，大家可以回憶一下，大家常用的這些業(yè)務(wù)的數(shù)據(jù)分析需求是不是許多都能通過這種簡單的模式給抽樣出來。

接下來看一下互聯(lián)網(wǎng)產(chǎn)品采用的數(shù)據(jù)分析方法。

對于互聯(lián)網(wǎng)產(chǎn)品常用的用戶行為分析來說，有這么四種：

【方法1：多維事件分析法】

首先來看多維事件的分析，這塊常見的運營、產(chǎn)品改進這種效果分析。其實，大部分情況都是能用多維事件分析，然后對它進行一個數(shù)據(jù)上的統(tǒng)計。

1. 【三個關(guān)鍵概念】

這里面其實就是由三個關(guān)鍵的概念，一個就是事件，一個是維度，一個是指標(biāo)。

事件就是說任何一個互聯(lián)網(wǎng)產(chǎn)品，都可以把它抽象成一系列事件，比如針對電商產(chǎn)品來說，可抽象到提交、訂單、注冊、收到商品一系列事件用戶行為。

每一個事件里面都包括一系列屬性。比如，他用操作系統(tǒng)版本是否連wifi；比如，訂單相關(guān)的運費，訂單總價這些東西，或者用戶的一些職能屬性，這些就是一系列維度。

基于這些維度看一些指標(biāo)的情況。比如，對于提交訂單來說，可能是他總提交訂單的次數(shù)做成一個指標(biāo)，提交訂單的人數(shù)是一個指標(biāo)，平均的人均次數(shù)這也是一個指標(biāo)；訂單的總和、總價這些也是一個指標(biāo)，運費這也是一個指標(biāo)，統(tǒng)計一個數(shù)后就能把它抽樣成一個指標(biāo)。

2. 【多維分析的價值】

來看一個例子，看看多維分析它的價值。

比如，對于訂單支付這個事件來說，針對整個總的成交額這條曲線，按照時間的曲線會發(fā)現(xiàn)它一路在下跌。但下跌的時候，不能眼睜睜的看著它，一定要分析原因。

怎么分析這個原因呢？常用的方式就是對維度進行一個拆解，可以按照某些維度進行拆分，比如我們按照地域，或者按照渠道，或者按照其他一些方式去拆開，按照年齡段、按照性別去拆開，看這些數(shù)據(jù)到底是不是整體在下跌，還是說某一類數(shù)據(jù)在下跌。

這是一個假想的例子——按照支付方式進行拆開之后，支付方式有三種，有用支付寶alipay，或者用微信支付，或者用銀行看內(nèi)的支付這三種方式。

通過數(shù)據(jù)可以看到支付寶、銀行支付基本上是一個沉穩(wěn)的一個狀態(tài)。但是，如果看微信支付，會發(fā)現(xiàn)從最開始最多，一路下跌到非常少，通過這個分析就知道微信這種支付方式，肯定存在某些問題。

比如：是不是升級了這個接口或者微信本身出了什么問題，導(dǎo)致了它量下降下去了？

【方法2：漏斗分析】

漏斗分析是用數(shù)據(jù)來看一個用戶從做第一步操作到后面每一步操作，實際的轉(zhuǎn)化過程。

比如，一批用戶先瀏覽了你的首頁，瀏覽首頁之后可能一部分人就直接跑了，還有一部分人可能去點擊到一個商品里面去，點擊到商品可能又有很多人跑了，接下來可能有一部分人就真的購買了，這其實就是一個漏斗。

通過這個漏斗，就能分析一步步的轉(zhuǎn)化情況，然后每一步都有流失，可以分析不同的渠道其轉(zhuǎn)化情況如何。比如，打廣告的時候發(fā)現(xiàn)來自百度的用戶漏斗轉(zhuǎn)化效果好，就可能在廣告投放上就在百度上多投一些。

【方法3：留存分析】

比如，搞一個地推活動，然后來了一批注冊用戶，接下來看它的關(guān)鍵行為上面操作的特征，比如當(dāng)天它有操作，第二天有多少人會關(guān)鍵操作，第N天有多少操作，這就是看它留下來這個情況。

【方法4：回訪分析】

回訪就是看進行某個行為的一些頻度特征，如對于購買黃金這個行為來說，在一周之內(nèi)至少有一天購買黃金的人有多少人，至少有兩天的有多少人，至少有7天的有多少人，或者說購買多少次數(shù)這么一個分布，就是回訪回購這方面的分析。

上面說的四種分析結(jié)合起來去使用，對一個產(chǎn)品的數(shù)據(jù)支撐、數(shù)據(jù)驅(qū)動的這種深度就要比只是看一個宏觀的訪問量或者活躍用戶數(shù)就要深入很多。

接下來講第四部分，個人在運營和分析方面的實踐，給大家分享一下。

【案例1：UGC產(chǎn)品是如何提高回答量的？】

首先，來看UGC產(chǎn)品的數(shù)據(jù)分析的例子?？赡軙治鏊脑L問量是多少，新增用戶數(shù)是多少，獲得用戶數(shù)多少，發(fā)帖量、檢索量。

例如貼吧、百度知道，還有知乎都屬于這一類的產(chǎn)品。對于這樣一個產(chǎn)品，會有很多數(shù)據(jù)指標(biāo)，可以從某一個角度去觀察這個產(chǎn)品的情況。那么，問題就來了——這么多的指標(biāo)，到底要關(guān)注什么？不同的階段應(yīng)該關(guān)注什么指標(biāo)？這里，就牽扯到一個指標(biāo)的梳理，還有關(guān)鍵指標(biāo)的問題。

2007年我加入百度知道之后，剛開始做后端研發(fā)。作為RD，我每天也收到一系列報表郵件，這些報表里面有很多統(tǒng)計的一些數(shù)據(jù)。比如，百度知道的訪問量、檢索量、IP數(shù)、Session數(shù)、提問量、回答量，設(shè)置追加答案的數(shù)量，這一系列指標(biāo)。當(dāng)時，看的其實感覺很模糊。

我在思考：這么多的指標(biāo)，不能說這也提高，那也提高吧？每個階段肯定要思考哪個事最關(guān)鍵的，重點要提高哪些指標(biāo)。開始的時候其實是沒有任何區(qū)分的，不知道什么是重要、什么是不重要。

后來，慢慢有一些感觸和認(rèn)識，就發(fā)現(xiàn)其實對于訪問量、檢索量這些相關(guān)的。因為百度知道大部分流量都是來自于大搜索，把它的展現(xiàn)做一下調(diào)整或者引導(dǎo)，對量的影響非常大。雖然，跟百度知道本身做的好壞也有直接關(guān)系，但是它很受渠道的影響——大搜索這個渠道的影響。

提問量開始的時候，我認(rèn)為非常重要，怎么提升提問量，那么整個百度知道平臺的這個問題就多了。提升回答量，讓這些問題得到回答，高質(zhì)量的內(nèi)容就非常多了，又提升提問量，而后再提升回答量——其實等于是兩類人了。而怎么把它做上去，我當(dāng)時有一些困惑，有一些矛盾，到底什么東西是最關(guān)鍵的。

有一次產(chǎn)品會，每一個季度都有一個產(chǎn)品會。那個時候，整個部門的產(chǎn)品負(fù)責(zé)人是孫云豐，可能在百度待過的或者說對百度產(chǎn)品體系有了解的都會知道這么一個人，非常厲害的一個產(chǎn)品經(jīng)理。我當(dāng)時就問了他這個問題，我對提問量、回答量都要提升這個困惑。

他就說了一點，其實提問量不是一個關(guān)鍵的問題，為什么？我們可以通過大搜索去找，如果一個用戶在大搜索里面進行搜索，發(fā)現(xiàn)這個搜索沒有一個好的答案，那就可以引導(dǎo)他進行一個提問，這樣其實這個提問量就可以迅速提升上去。

我一聽一下就解決了這個困惑，最關(guān)鍵的就是一個回答量，我所做的事情其實怎么去提升回答量就可以了。

這里面把百度知道這個產(chǎn)品抽象成了最關(guān)鍵的一個提升——那就是如何提升回答量，在這個問題上當(dāng)時做了一個事情就是進行問題推薦。

百度知道有一批活躍用戶，這些用戶就喜歡回答問題。于是，我們思考：能不能把一些他們可以回答的問題推薦給他們，讓他們回答各種各樣的問題——這個怎么去做呢？

這個思路也很簡單，現(xiàn)在個性化推薦都是比較正常的，大家一般都知道這么一回事。但是，2008年做推薦這個事情其實還是比較領(lǐng)先的，從我了解的情況來看，國內(nèi)的是2010年個性化推薦引擎這塊技術(shù)火了，但后來有些公司做這方面后來都倒掉了。

實現(xiàn)策略是非常簡單的，我們就看一個用戶歷史的回答記錄，看他回答的這些問題title是什么、內(nèi)容是什么。

由于百度很擅長做自然語言的處理，基于這些，通過這里面的抽取用戶的興趣詞，感興趣的話題，然后把待解的問題，與該問題的相關(guān)用戶進行一個匹配，匹配上了就把這個問題推薦給這個用戶。

當(dāng)時，我們做的一個事情就是：把過去幾個月回答量比較高的用戶進行一個抽取，對他們訓(xùn)練一個模型——就是對每個用戶有一系列的話題興趣點，然后每個點都有一個程度，這就是一個用戶的模型向量，就是一個興趣項量，當(dāng)時抽了35萬個用戶。

這個效果是這樣的，現(xiàn)在我已經(jīng)找不到我們當(dāng)年做的圖片，這是我前一段時間截的圖，大體類似。比如，我對數(shù)據(jù)分析相關(guān)的問題回答了不少，它就會給我推薦數(shù)據(jù)分析相關(guān)的問題。

我們這個功能差不多做了有三個月，把它推上線我們其實是滿懷期待的，結(jié)果效果如何呢？

上線之后很悲劇，我們發(fā)現(xiàn)總的回答量沒有變化。于是，我們又進一步分析了一下原因。當(dāng)時，最開始這些核心用戶在回答問題的時候都是找分類頁。比如：電腦這個分類，然后看電腦相關(guān)的問題，有興趣的就回答。

后來，我們做了一個推薦：在個人中心里面加了一個猜他喜歡的tab，然后推給他，結(jié)果用戶從分類頁回答這個問題轉(zhuǎn)到了個人中心。但是，平均一個人回答量并沒有變化，當(dāng)時做的統(tǒng)計，這些核心用戶就每天回答六個問題，超過六個他就沒動力回答了。

我們事后分析原因，有一個原因他可能本身的回答量就是這么一條線，誰能天天在哪里源源不斷的回答問題。還有一個同事就分析當(dāng)時讓他一個痛苦的地方，因為我們是源源不斷地推薦，然后他就發(fā)現(xiàn)回答幾個之后還有幾個，回答了幾次就感覺要崩潰了，就不想再這么回答下去了。

其實，年前時知乎在問題推薦上也做了不少功夫，做了許多測試。年前有一段時間，它天天給我推一些新的問題，然后我去回答。后來，發(fā)現(xiàn)推的太多了，就沒回答的動力了。

針對這些核心用戶會發(fā)現(xiàn)從他們上面榨取不了新的價值了。于是，我們調(diào)轉(zhuǎn)了矛頭，從另一個角度——能不能去廣撒網(wǎng)，吸引更多的用戶來回答問題，這個做的就是一個Cookie推薦。

訪問百度的時候，百度不管用戶是否登錄，會在用戶Cookie里面去設(shè)置一個用戶標(biāo)識。通過這個標(biāo)識能夠?qū)@個用戶進行一個跟蹤，雖然不知道用戶是誰，但是，起碼能把同一個用戶這個行為給它串起來。這樣，就可以基于他歷史的檢索，各種搜索詞，還有他瀏覽的各種頁面的記錄，然后去提取一些興趣，然后給這些Cookie建一個模型。

這樣有一個好處，能夠覆蓋的用戶量非常大，前面講的核心用戶推薦只覆蓋了只有35萬的核心用戶，但是通過這種方式可以覆蓋幾億百度用戶，每一次用戶登錄之后或者訪問百度知道之后我們就基于他本身興趣然后走一次檢索，在解決問題里面檢索一下跟他匹配的就給他推薦出來。

比如前一段，我自己在沒有登錄的時候，其實我是會看馬爾克斯。我比較喜歡馬爾克斯的作品，我當(dāng)時搜了馬爾克斯的一些相關(guān)的內(nèi)容。它就抽取出來我對馬爾克斯什么感興趣，就給我推薦了馬爾克斯相關(guān)的問題，可能我知道我不可能就會點進去回答。

這個功能上了之后效果還是很不錯的，讓整體的回答量提升了7.5%。要知道，百度知道產(chǎn)品從2005年開始做，做到2007年、2008年的時間這個產(chǎn)品已經(jīng)很成熟了。在一些關(guān)鍵指標(biāo)進行大的提升還是非常有挑戰(zhàn)的，這種情況下我們通過這種方式提升了7.5%的回答量，感覺還是比較有成就感，我當(dāng)時也因為這個事情得了季度之星。

【案例2：產(chǎn)品發(fā)布時，通過36kr，微信群，朋友圈推廣的轉(zhuǎn)化分析】

講了百度知道之后，我們接下來講一下SAAS運營分析實踐。

因為我自己目前創(chuàng)業(yè)做的這個產(chǎn)品就是針對于互聯(lián)網(wǎng)創(chuàng)業(yè)公司做用戶相關(guān)分析這塊，我們對產(chǎn)品在去年9月25號的時候正式對外發(fā)布，發(fā)布本身我們其實進行了一些數(shù)據(jù)的分析。后來，又嘗試了一些廣告渠道也做了一些數(shù)據(jù)分析。之后，又針對流失的一些用戶我們也搞了一些周圍活動，我把整個真實的經(jīng)歷給大家分享一下。

5，寫在最后的話：數(shù)據(jù)驅(qū)動的時代來了

對于數(shù)據(jù)驅(qū)動這一點，可能有些人從沒有看數(shù)的習(xí)慣到了看數(shù)的習(xí)慣那是一大進步，是不是能看幾個數(shù)這就叫數(shù)據(jù)驅(qū)動了呢？這還遠遠不夠，這里來說一下什么是數(shù)據(jù)驅(qū)動？或者現(xiàn)有的創(chuàng)業(yè)公司在進行數(shù)據(jù)驅(qū)動這件事情上存在的一些問題。

一種情況大家在公司里面有一個數(shù)據(jù)工程師，他的工作職責(zé)就是跑數(shù)據(jù)。

不管是市場也好，產(chǎn)品也好，運營也好，老板也好，大家都會有各種各樣的數(shù)據(jù)需求，但都會提給數(shù)據(jù)工程師老王。然而，這個資源也是有限的，他的工作時間也是有限的，只能一個一個需求去處理，他本身工作很忙，大家提的需求之后可能并不會馬上就處理，可能需要等待一段時間。即使處理了這個需求，一方面他可能數(shù)據(jù)準(zhǔn)備的不全，他需要去采集一些數(shù)據(jù)，或做一些升級，他要把數(shù)據(jù)拿過來。拿過來之后又在這個數(shù)據(jù)上進行一些分析，這個過程本身可能兩三天時間就過去了，如果加上等待的時間更長。

對于有些人來說，這個等待周期太長，整個時機可能就錯過了。比如，你重要的就是考察一個節(jié)日或者一個開學(xué)這樣一個時間點，然后想搞一些運營相關(guān)的事情，這個時機可能就錯過去了，許多人等不到了。有些同學(xué)可能就干脆還是拍腦袋，就不等待這個數(shù)據(jù)了。這個過程其實就是說效率是非常低的，并不是說拿不到這個數(shù)據(jù)，而是說效率低的情況下我們錯過了很多機會。

對于還有一些公司來說，之前可能連個數(shù)都沒有，現(xiàn)在有了一個儀表盤，有了儀表盤可以看到公司上個季度、昨天總體的這些數(shù)據(jù)，還是很不錯的。

理想狀態(tài)的數(shù)據(jù)驅(qū)動應(yīng)該是怎么樣的？就是一個自助式的數(shù)據(jù)分析，讓業(yè)務(wù)人員每一個人都能自己去進行數(shù)據(jù)分析，掌握這個數(shù)據(jù)。

前面我講到一個模式，我們源頭是一堆雜亂的數(shù)據(jù)，中間有一個工程師用來跑這個數(shù)據(jù)，然后右邊是接各種業(yè)務(wù)同學(xué)提了需求，然后排隊等待被處理，這種方式效率是非常低的。理想狀態(tài)來說，我們先將大數(shù)據(jù)源本身整好，整全整細(xì)了，中間提供強大的分析工具，讓每一個業(yè)務(wù)員都能直接進行操作，大家并發(fā)的去做一些業(yè)務(wù)上的數(shù)據(jù)需求，這個效率就要高非常多。

未來的數(shù)據(jù)運營就是這樣子的。