一、大數據思維
在2011年、2012年大數據概念火了之后，可以說這幾年許多傳統企業也好，互聯網企業也好，都把自己的業務給大數據靠一靠，并且提的比較多的大數據思維。
那么大數據思維是怎么回事?我們來看兩個例子：
案例1：輸入法
首先，我們來看一下輸入法的例子。
我2001年上大學，那時用的輸入法比較多的是智能ABC，還有微軟拼音，還有五筆。那時候的輸入法比現在來說要慢的很多，許多時候輸一個詞都要選好幾次，去選詞還是調整才能把這個字打出來，效率是非常低的。
到了2002年，2003年出了一種新的輸出法——紫光拼音，感覺真的很快，鍵盤沒有按下去字就已經跳出來了。但是，后來很快發現紫光拼音輸入法也有它的問題，比如當時互聯網發展已經比較快了，會經常出現一些新的詞匯，這些詞匯在它的詞庫里沒有的話，就很難敲出來這個詞。
在2006年左右，搜狗輸入法出現了。搜狗輸入法基于搜狗本身是一個搜索，它積累了一些用戶輸入的檢索詞這些數據，用戶用輸入法時候產生的這些詞的信息，將它們進行統計分析，把一些新的詞匯逐步添加到詞庫里去，通過云的方式進行管理。
比如，去年流行一個詞叫“然并卵”，這樣的一個詞如果用傳統的方式，因為它是一個重新構造的詞，在輸入法是沒辦法通過拼音“ran bing luan”直接把它找出來的。然而，在大數據思維下那就不一樣了，換句話說，我們先不知道有這么一個詞匯，但是我們發現有許多人在輸入了這個詞匯，于是，我們可以通過統計發現最近新出現的一個高頻詞匯，把它加到司庫里面并更新給所有人，大家在使用的時候可以直接找到這個詞了。
案例2：地圖
再來看一個地圖的案例，在這種電腦地圖、手機地圖出現之前，我們都是用紙質的地圖。這種地圖差不多就是一年要換一版，因為許多地址可能變了，并且在紙質地圖上肯定是看不出來，從一個地方到另外一個地方怎么走是最好的?中間是不是堵車?這些都是有需要有經驗的各種司機才能判斷出來。
在有了百度地圖這樣的產品就要好很多，比如：它能告訴你這條路當前是不是堵的?或者說能告訴你半個小時之后它是不是堵的?它是不是可以預測路況情況?
此外，你去一個地方它可以給你規劃另一條路線，這些就是因為它采集到許多數據。比如：大家在用百度地圖的時候，有GPS地位信息，基于你這個位置的移動信息，就可以知道路的擁堵情況。另外，他可以收集到很多用戶使用的情況，可以跟交管局或者其他部門來采集一些其他攝像頭、地面的傳感器采集的車輛的數量的數據，就可以做這樣的判斷了。
這里，我們來看一看紙質的地圖跟新的手機地圖之間，智能ABC輸入法跟搜狗輸入法都有什么區別?
這里面最大的差異就是有沒有用上新的數據。這里就引來了一個概念——數據驅動。有了這些數據，基于數據上統計也好，做其他挖掘也好，把一個產品做的更加智能，變得更加好，這個跟它對應的就是之前可能沒有數據的情況，可能是拍腦袋的方式，或者說我們用過去的，我們想清楚為什么然后再去做這個事情。這些相比之下數據驅動這種方式效率就要高很多，并且有許多以前解決不了的問題它就能解決的非常好。
二、數據驅動
對于數據驅動這一點，可能有些人從沒有看數的習慣到了看數的習慣那是一大進步，是不是能看幾個數這就叫數據驅動了呢?這還遠遠不夠，這里來說一下什么是數據驅動?或者現有的創業公司在進行數據驅動這件事情上存在的一些問題。
一種情況大家在公司里面有一個數據工程師，他的工作職責就是跑數據。
不管是市場也好，產品也好，運營也好，老板也好，大家都會有各種各樣的數據需求，但都會提給他。然而，這個資源也是有限的，他的工作時間也是有限的，只能一個一個需求去處理，他本身工作很忙，大家提的需求之后可能并不會馬上就處理，可能需要等待一段時間。即使處理了這個需求，一方面他可能數據準備的不全，他需要去采集一些數據，或做一些升級，他要把數據拿過來。拿過來之后又在這個數據上進行一些分析，這個過程本身可能兩三天時間就過去了，如果加上等待的時間更長。
對于有些人來說，這個等待周期太長，整個時機可能就錯過了。比如，你重要的就是考察一個節日或者一個開學這樣一個時間點，然后想搞一些運營相關的事情，這個時機可能就錯過去了，許多人等不到了，有些同學可能就干脆還是拍腦袋，就不等待這個數據了。這個過程其實就是說效率是非常低的，并不是說拿不到這個數據，而是說效率低的情況下我們錯過了很多機會。
對于還有一些公司來說，之前可能連個數都沒有，現在有了一個儀表盤，有了儀表盤可以看到公司上個季度、昨天總體的這些數據，還是很不錯的。
對老板來說肯定還是比較高興，但是，對于市場、運營這些同學來說可能就還不夠。
比如，我們發現某一天的用戶量跌了20%，這個時候肯定不能放著不管，需要查一查這個問題出在哪。這個時候，只看一個宏觀的數那是遠遠不夠的，我們一般要對這個數據進行切分，按地域、按渠道，按不同的方式去追查，看到底是哪少了，是整體少了，還是某一個特殊的渠道獨特的地方它這個數據少了，這個時候單單靠一個儀表盤是不夠的。
理想狀態的數據驅動應該是怎么樣的?就是一個自助式的數據分析，讓業務人員每一個人都能自己去進行數據分析，掌握這個數據。
前面我講到一個模式，我們源頭是一堆雜亂的數據，中間有一個工程師用來跑這個數據，然后右邊是接各種業務同學提了需求，然后排隊等待被處理，這種方式效率是非常低的。理想狀態來說，我們現象大數據源本身整好，整全整細了，中間提供強大的分析工具，讓每一個業務員都能直接進行操作，大家并發的去做一些業務上的數據需求，這個效率就要高非常多。
三、數據處理的流程
大數據分析這件事用一種非技術的角度來看的話，就可以分成金字塔，自底向上的是三個部分，第一個部分是數據采集，第二個部分是數據建模，第三個部分是數據分析，我們來分別看一下。
數據采集
首先來說一下數據采集，我在百度干了有七年是數據相關的事情。我最大的心得——數據這個事情如果想要更好，最重要的就是數據源，數據源這個整好了之后，后面的事情都很輕松。
用一個好的查詢引擎、一個慢的查詢引擎無非是時間上可能消耗不大一樣，但是數據源如果是差的話，后面用再復雜的算法可能都解決不了這個問題，可能都是很難得到正確的結論。
我覺得好的數據處理流程有兩個基本的原則，一個是全，一個是細。
全：
就是說我們要拿多種數據源，不能說只拿一個客戶端的數據源，服務端的數據源沒有拿，數據庫的數據源沒有拿，做分析的時候沒有這些數據你可能是搞歪了。另外，大數據里面講的是全量，而不是抽樣。不能說只抽了某些省的數據，然后就開始說全國是怎么樣。可能有些省非常特殊，比如新疆、西藏這些地方客戶端跟內地可能有很大差異的。
細：
其實就是強調多維度，在采集數據的時候盡量把每一個的維度、屬性、字段都給它采集過來。比如：像where、who、how這些東西給它替補下來，后面分析的時候就跳不出這些能夠所選的這個維度，而不是說開始的時候也圍著需求。根據這個需求確定了產生某些數據，到了后面真正有一個新的需求來的時候，又要采集新的數據，這個時候整個迭代周期就會慢很多，效率就會差很多，盡量從源頭抓的數據去做好采集。
數據建模
有了數據之后，就要對數據進行加工，不能把原始的數據直接報告給上面的業務分析人員，它可能本身是雜亂的，沒有經過很好的邏輯的。
這里就牽扯到數據建框，首先，提一個概念就是數據模型。許多人可能對數據模型這個詞產生一種畏懼感，覺得模型這個東西是什么高深的東西，很復雜，但其實這個事情非常簡單。
我春節期間在家干過一件事情，我自己家里面家譜在文革的時候被燒了，后來家里的長輩說一定要把家譜這些東西給存檔一下，因為我會電腦，就幫著用電腦去理了一下這些家族的數據這些關系，整個族譜這個信息。
我們現實是一個個的人，家譜里面的人，通過一個樹型的結構，還有它們之間數據關系，就能把現實實體的東西用幾個簡單圖給表示出來，這里就是一個數據模型。
數據模型就是對現實世界的一個抽象化的數據的表示。我們這些創業公司經常是這么一個情況，我們現在這種業務，一般前端做一個請求，然后對請求經過處理，再更新到數據庫里面去，數據庫里面建了一系列的數據表，數據表之間都是很多的依賴關系。
比如，就像我圖片里面展示的這樣，這些表一個業務項發展差不多一年以上它可能就牽扯到幾十張甚至上百張數據表，然后把這個表直接提供給業務分析人員去使用，理解起來難度是非常大的。
這個數據模型是用于滿足你正常的業務運轉，為產品正常的運行而建的一個數據模型。但是，它并不是一個針對分析人員使用的模型。如果，非要把它用于數據分析那就帶來了很多問題。比如：它理解起來非常麻煩。
另外，數據分析很依賴表之間的這種格子，比如：某一天我們為了提升性能，對某一表進行了拆分，或者加了字段、刪了某個字短，這個調整都會影響到你分析的邏輯。
這里，最好要針對分析的需求對數據重新進行解碼，它內容可能是一致的，但是我們的組織方式改變了一下。就拿用戶行為這塊數據來說，就可以對它進行一個抽象，然后重新把它作為一個判斷表。
用戶在產品上進行的一系列的操作，比如瀏覽一個商品，然后誰瀏覽的，什么時間瀏覽的，他用的什么操作系統，用的什么瀏覽器版本，還有他這個操作看了什么商品，這個商品的一些屬性是什么，這個東西都給它進行了一個很好的抽象。這種抽樣的很大的好處很容易理解，看過去一眼就知道這表是什么，對分析來說也更加方便。
在數據分析方，特別是針對用戶行為分析方面，目前比較有效的一個模型就是多維數據模型，在線分析處理這個模型，它里面有這個關鍵的概念，一個是維度，一個是指標。
維度比如城市，然后北京、上海這些一個維度，維度西面一些屬性，然后操作系統，還有IOS、安卓這些就是一些維度，然后維度里面的屬性。
通過維度交叉，就可以看一些指標問題，比如用戶量、銷售額，這些就是指標。比如，通過這個模型就可以看來自北京，使用IOS的，他們的整體銷售額是怎么樣的。
這里只是舉了兩個維度，可能還有很多個維度。總之，通過維度組合就可以看一些指標的數，大家可以回憶一下，大家常用的這些業務的數據分析需求是不是許多都能通過這種簡單的模式給抽樣出來。
四、數據分析方法
接下來看一下互聯網產品采用的數據分析方法。
對于互聯網產品常用的用戶消費分析來說，有四種：
第一種是多維事件的分析，分析維度之間的組合、關系。
第二種是漏斗分析，對于電商、訂單相關的這種行為的產品來說非常重要，要看不同的渠道轉化這些東西。
第三種留存分析，用戶來了之后我們希望他不斷的來，不斷的進行購買，這就是留存。
第四種回訪，回訪是留存的一種特別的形式，可以看他一段時間內訪問的頻次，或者訪問的時間段的情況
方法1：多維事件分析法
首先來看多維事件的分析，這塊常見的運營、產品改進這種效果分析。其實，大部分情況都是能用多維事件分析，然后對它進行一個數據上的統計。
1. 三個關鍵概念
這里面其實就是由三個關鍵的概念，一個就是事件，一個是維度，一個是指標組成。
事件就是說任何一個互聯網產品，都可以把它抽象成一系列事件，比如針對電商產品來說，可抽象到提交、訂單、注冊、收到商品一系列事件用戶行為。
每一個事件里面都包括一系列屬性。比如，他用操作系統版本是否連wifi;比如，訂單相關的運費，訂單總價這些東西，或者用戶的一些職能屬性，這些就是一系列維度。
基于這些維度看一些指標的情況。比如，對于提交訂單來說，可能是他總提交訂單的次數做成一個指標，提交訂單的人數是一個指標，平均的人均次數這也是一個指標;訂單的總和、總價這些也是一個指標，運費這也是一個指標，統計一個數后就能把它抽樣成一個指標。
2. 多維分析的價值
來看一個例子，看看多維分析它的價值。
比如，對于訂單支付這個事件來說，針對整個總的成交額這條曲線，按照時間的曲線會發現它一路在下跌。但下跌的時候，不能眼睜睜的看著它，一定要分析原因。
怎么分析這個原因呢?常用的方式就是對維度進行一個拆解，可以按照某些維度進行拆分，比如我們按照地域，或者按照渠道，或者按照其他一些方式去拆開，按照年齡段、按照性別去拆開，看這些數據到底是不是整體在下跌，還是說某一類數據在下跌。
這是一個假想的例子——按照支付方式進行拆開之后，支付方式有三種，有用支付寶、阿里PAY，或者用微信支付，或者用銀行看內的支付這三種方式。
通過數據可以看到支付寶、銀行支付基本上是一個沉穩的一個狀態。但是，如果看微信支付，會發現從最開始最多，一路下跌到非常少，通過這個分析就知道微信這種支付方式，肯定存在某些問題。
比如：是不是升級了這個接口或者微信本身出了什么問題，導致了它量下降下去了?
方法2：漏斗分析
漏斗分析會看，因為數據，一個用戶從做第一步操作到后面每一步操作，可能是一個雜的過程。
比如，一批用戶先瀏覽了你的首頁，瀏覽首頁之后可能一部分人就直接跑了，還有一部分人可能去點擊到一個商品里面去，點擊到商品可能又有很多人跑了，接下來可能有一部分人就真的購買了，這其實就是一個漏斗。
通過這個漏斗，就能分析一步步的轉化情況，然后每一步都有流失，可以分析不同的渠道其轉化情況如何。比如，打廣告的時候發現來自百度的用戶漏斗轉化效果好，就可能在廣告投放上就在百度上多投一些。
方法3：留存分析
比如，搞一個地推活動，然后來了一批注冊用戶，接下來看它的關鍵行為上面操作的特征，比如當天它有操作，第二天有多少人會關鍵操作，第N天有多少操作，這就是看它留下來這個情況。
方法4：回訪分析
回訪就是看進行某個行為的一些中度特征，如對于購買黃金這個行為來說，在一周之內至少有一天購買黃金的人有多少人，至少有兩天的有多少人，至少有7天的有多少人，或者說購買多少次數這么一個分布，就是回訪回購這方面的分析。
上面說的四種分析結合起來去使用，對一個產品的數據支撐、數據驅動的這種深度就要比只是看一個宏觀的訪問量或者活躍用戶數就要深入很多。
五、運營分析實踐
下面結合個人在運營和分析方面的實踐，給大家分享一下。
案例1：UGC產品
首先，來看UGC產品的數據分析的例子?？赡軙治鏊脑L問量是多少，新增用戶數是多少，獲得用戶數多少，發帖量、減少量。
諸如貼吧、百度知道，還有知乎都屬于這一類的產品。對于這樣一個產品，會有很多數據指標，可以從某一個角度去觀察這個產品的情況。那么，問題就來了——這么多的指標，到底要關注什么?不同的階段應該關注什么指標?這里，就牽扯到一個本身指標的處理，還有關鍵指標的問題。
案例2：百度知道
2007年我加入百度知道之后，開始剛進去就寫東西了。作為RB，我每天也收到一系列報表郵件，這些報表里面有很多統計的一些數據。比如，百度知道的訪問量、減少量、IP數、申請數、提問量、回答量，設置追加答案，答案的數量，這一系列指標。當時，看的其實感覺很反感。
我在思考：這么多的指標，不能說這也提高，那也提高吧?每個階段肯定要思考哪個事最關鍵的，重點要提高哪些指標。開始的時候其實是沒有任何區分的，不知道什么是重要、什么是不重要。
后來，慢慢有一些感觸和認識，就發現其實對于訪問量、減少量這些相關的。因為百度知道需要流量都是來自于大搜索，把它展現做一下調整或者引導，對量的影響非常大。雖然，跟百度知道本身做的好壞也有直接關系，但是它很受渠道的影響——大搜索這個渠道的影響。
提問量開始的時候，我認為非常重要，怎么提升提問量，那么整個百度知道平臺的這個問題就多了。提升回答量，讓這些問題得到回答，高質量的內容就非常多了，又提升提問量，而后再提升回答量——其實等于是兩類人了。而怎么把它做上去，我當時有一些困惑，有一些矛盾，到底什么東西是最關鍵的。
有一次產品會，每一個季度都有一個產品會。那個時候，整個部門的產品負責人是孫云豐，可能在百度待過的或者說對百度產品體系有了解的都會知道這么一個人，非常厲害的一個產品經理。我當時就問了他這個問題，我對提問量、回答量都要提升這個困惑。
他就說了一點，其實提問量不是一個關鍵的問題，為什么?我們可以通過大搜索去找，如果一個用戶在大搜索里面進行搜索，發現這個搜索沒有一個好的答案，那就可以引導他進行一個提問，這樣其實這個提問量就可以迅速提升上去。
我一聽一下就解決了這個困惑，最關鍵的就是一個回答量，我所做的事情其實怎么去提升回答量就可以了。
這里面把百度知道這個產品抽樣成了最關鍵的一個提升——那就是如何提升回答量，在這個問題上當時做了一個事情就是進行問題推薦。
百度知道有一批活躍用戶，這些用戶就喜歡回答問題。于是，我們思考：能不能把一些他們可以回答問題推薦給他們，讓他們回答各種各樣的問題——這個怎么去做呢?
這個思路也很簡單，現在個性化推薦都是比較正常的，大家默認知道這么一回事。但是，2008年做推薦這個事情其實還是比較領先的，從我了解的情況來看，國內的是2010年個性化推薦引擎這塊技術火了，但后來有些公司做這方面后來都倒掉了。
實現策略是非常簡單的，我們就看一個用戶歷史的回答記錄，看他回答的這些問題開頭是什么、內容是什么。
由于百度很擅長做自然語言的處理，基于這些，通過這里面的抽取用戶的興趣詞，感興趣的話題，然后把待解的問題，與該問題相關話題的相關用戶進行一個匹配，匹配上了就把這個問題推薦給這個用戶。
當時，我們做的一個事情就是：把推薦幾個月有過回答量比較高的用戶進行一個抽取，對他們訓練一個模式——就是對每個用戶有一系列的話題興趣點，然后每個點都有一個程度，這就是一個用戶的模型項量，就是一個興趣項量，當時抽了35萬個用戶。
這個效果是這樣的，現在我已經找了我們當年做的圖片，整個樣式其實這是我前一段時間截的圖，大體類似。比如，我對數據分析相關的問題回答了不少，它就會給我推薦數據分析相關的問題。
我們這個功能差不多做了有三個月，把它推上線我們其實是滿懷期待的，結果效果如何呢?
上線之后很悲劇，我們發現總的回答量沒有變化。于是，我們又進一步分析了一下原因。當時，最開始這些核心用戶在回答問題的時候都是找分類頁。比如：電腦這個分類，然后看電腦相關的問題，有興趣的就回答。
后來，我們做了一個體驗：在個人中心里面加了一個猜他喜歡的那個問題，然后推給他，結果用戶從分類頁回答這個問題轉到了個人中心。但是，平均一個人回答量并沒有變化，當時做的這些統計，這些核心用戶就回答六個問題，超過六個他就沒動力回答了。
我們事后分析原因，有一個原因他可能本身的回答量就是這么一條線，誰能天天在哪里源源不斷的回復問題。還有一個同事就分析當時讓他一個痛苦的地方，因為我們是源源不斷地推薦，然后他就發現回答幾個之后還有幾個，回答了幾次就感覺要崩潰了，就不想再這么回答下去了。
其實，年前時知乎在問題推薦上也做了不少功夫，做了許多測試。年前有一段時間，它天天給我推一些新的問題，然后我去回答。后來，發現推的太多了，就沒回答的動力了。
針對這些核心用戶會發現從他們上面榨取不了新的價值了。于是，我們調轉了矛頭，從另一個角度——能不能去廣撒網，吸引更多的用戶來回答問題，這個做的就是一個庫里推薦。
訪問百度的時候，百度不管用戶是否登錄，會在用戶的庫里面去設置一個用戶標識。通過這個標識能夠對這個用戶進行一個跟蹤，雖然不知道用戶是誰，但是，起碼能把同一個用戶這個行為給它檢起來。這樣，就可以基于他歷史的檢索，各種搜索詞，還有他流量的各種頁面的記錄，然后去提取一些證據，然后給這些庫題建一個模型。
這樣有一個好處，能夠覆蓋的用戶量非常大，前面講的核心用戶推薦只覆蓋了只有35萬的核心用戶，但是通過這種方式可以覆蓋幾億百度用戶，每一次用戶登錄之后或者訪問百度知道之后我們就基于他本身興趣然后走一次檢索，在解決問題里面檢索一下跟他匹配的就給他推薦出來。
比如前一段，我自己在沒有登錄的時候，其實我是會看馬爾克斯。我比較喜歡馬爾克斯的作品，我當時搜了馬爾克斯的一些相關的內容。它就抽取出來我對馬爾克斯什么感興趣，就給我推薦了馬爾克斯相關的問題，可能我知道我不可能就會點進去回答。
這個功能上了之后效果還是很不錯的，讓整體的回答量提升了7.5%。要知道，百度知道產品從2005年開始做，做到2007年、2008年的時間這個產品已經很成熟了。在一些關鍵指標進行大的提升還是非常有挑戰的，這種情況下我們通過這種方式提升了7.5%的回答量，感覺還是比較有成就感，我當時也因為這個事情得了季度之星。
案例3：流失用戶召回
這種形式可能對其他產品就很有效，但是對我們這個產品來說，因為我們這是一個相對來說目標比較明確并且比較小眾一點的差別，所以這個投放的效果可能就沒那么明顯。
在今年元旦的時候，因為之前申請試用我們那個產品已經有很多人，但是這里面有一萬人我們給他發了帳號他也并沒有回來，我們過年給大家拜拜年，然后去匯報一下進展看能不能把他們撈過來一部分。
這是元旦的時候我們產品的整體用戶情況，到了元旦為止，9月25號發布差不多兩三個月時間，那個時候差不多有1490個人申請試用了我們這個產品。但是，真正試用的有724個，差不多有一半，另外一半就跑了，就流失了。
我們就想把這部分人抽出來給他們進行一個招回活動，這里面流失用戶我們就可以把列表導出來，這是我們自己的產品就有這樣的功能。有人可能疑惑我們怎么拿到用戶的這些信息呢?
這些不至于添加，因為我們申請試用的時候就讓他填一下姓名、聯系方式，還有他的公司這些信息。對于填郵箱的我們就給發郵件的，對于發手機號的我們就給他發短信，我們分析這兩種渠道帶來的效果。
先說總體，總體我們發了716個人，這里面比前面少了一點，我把一些不靠譜的這些信息人工給它干掉了。接下來，看看真正有35個人去體驗了這個產品，然后35個人里面有4個人申請接入數據。
因為我們在產品上面做了一個小的改進，在測試環境上面，對于那些測試環境本身是一些數據他玩一玩，玩了可能感興趣之后就會試一下自己的真實數據。這個時候，我們上來有一個鏈接引導他們去申請接入自己的數據，走到這一步之后就更可能轉化成我們的正式客戶。
這兩種方式轉化效果我們其實也很關心，招回的效果怎么樣，我們看下面用紅框表示出來，郵件發了394封。最終有32個人真正過來試用了，電話手機號322封，跟郵件差不多，但只有3個過來，也就是說兩種效果差了8倍。
這其實也提醒大家，短信這種方式可能許多人看短信的比較少。當然，另一方面跟我們自己產品特征有關系，我們這個產品是一個PC上用起來更方便的一個產品。許多人可能在手機上看到這個鏈接也不方便點開，點開之后輸入帳號也麻煩一點。所以，導致這個效果比較差。
原文 http://www.woshipm.com/pd/297018.html
京公網安備 11010502049343號