199IT資料中心微信賬戶：i199IT
一. 一段經歷，一點心得
一直追我部落格的人想必是清楚我之前做互動設計，然後去輪崗過行業運營，然後突然就開始做產品經理了。我也覺得奇怪的是，上次發了一個招聘啟事後，來加我微信的同學們，既有做互動的，也有做產品經理的，甚至還有在IBM做了5年BI資料分析師的……這樣看來，我的部落格逐漸成了一個交叉學科。
簡單來說，也差不多如上圖所示。
當時是一個新業務開拓，僅僅4個月的輪崗（非正式的輪崗，當時就是老大給了各個部門體驗其他團隊工作的機會，但是組織架構可以在輪崗結束後再恢復原崗位），結果成了職業歷程上的分水嶺。為什麼呢？
於是我就“隨波逐流”地成了BI部門的一員——雖然我們並不做具體的資料分析，更多是向分析師提需求。
再後來，供應鏈整體效能的資料統計和分析，是靠分析師們每天出手工報表和報告傳送給各部門管理人員的。發了一段時間後，分析師苦不堪言，接收方也過於被動，當他在郵件裡看到某個資料異常時，無法自己主動地進行探索鑽取，所以自然而然有了將供應鏈報告“產品化”的需求。
要求：短、平、快。
資源：極少。沒有設計師、PD、以及充足的開發人員支援。
原因很正常：大部分人都投入到了業務系統建設中（彼時，供應鏈管理系統、物流管理系統、認證系統、以及前臺都處於開荒建設階段）。
所以，因為我做過互動設計——會畫DEMO；和PD接觸時間長——多少知道PRD怎麼寫；又給分析師提過需求——知道資料大概怎麼回事……
所以，我就“隨波逐流”成了資料產品的產品經理。
插句後話，以後在晉升面試或者轉崗面試時，當面試官問我怎麼就突然從互動設計師轉成資料產品經理時，最早我也是講的隨波逐流的故事……然後被挑戰比較嚴重，後來換個說法：Why not?
有這個機會，大家都信任你，又不給你壓力，又能學習到新領域的知識，和新的人打交道，同時還能繼續沿用互動設計的技能知識，Why not? 然後對方就頷首了，所以講故事的角度是多麼重要。
說點這段故事中，讓我真正堅定起來的兩句話：
一個老大說：“給你機會去試錯，錯了大不了重頭再來。”
另一個老大說：“設計師盯著皮膚看，產品經理要了解整體的經絡組織和骨骼，更重要的是要知道資料作為血液如何在流通。你有機會深入皮膚之下看一下，再回來看皮膚感覺又不一樣了。”
所以我是帶著這個人體經絡圖的即視感忐忐忑忑接下了資料產品經理這個新的崗位的。
不用別人說，我也知道有兩座大山需要翻：1. 資料 2. 產品經理。
二. 本文的目標
不指導就業，不提供資料分析解決方案，不承諾對任何人都必要有效。根據個人僅有的經驗、心得，我只能：
面向對資料分析、資料產品有興趣但是又有點畏懼的互動設計師、產品經理
希望能夠讓你們“減少對於資料世界的恐懼”，使用資料的語言“順暢溝通”。
三. 歡迎進入資料的世界
還記得你學習游泳的經歷嗎？記得我當時就是怎麼都不敢下水。
我的教練告訴我的最有用的一句話是：你會憋氣吧？你試試在淺水區裡什麼都不要做，鬆開欄杆，憋住氣，讓自己沉下去。如果你受不了了，反正你一站就站起來了。
我一想，也對，反正淺水區嘛。於是第一次鬆開了欄杆。
奇怪的事情發生了。我居然不會沉入水底耶~甚至透過泳鏡看別人的腳撲騰撲騰！原來水裡的世界沒有那麼的可怕！
克服了這個對水的恐懼後，才開始慢慢學習各種動作，開始享受水的樂趣。
資料的世界對於不瞭解它的人而言，正如這神祕的水一樣。
那麼我提供的讓你不怕“水”的心得有：兩個詞、一個立方體、一張流程圖
你準備好了嗎？
1. 兩個詞
先複習一下你可能也聽過的兩句話：
如果你無法量化，那就無法很好管理。
無細分，不分析。
第一句話來自管理大師彼得德魯克，第二句話則是分析界的金玉良言了。
這兩句話裡就隱含著我說的這兩個詞。
接下來，再來看一句話：成交10億人民幣！
肯定沒有人單獨說這樣的話，一般情況，這句話前都要加上一些“定語”，比如“今年截至到7月份，全國蔬菜市場”，或“去年9月，女裝市場”，或“過去N年，東三省豬肉市場”……等等。
這些語境裡，也隱含著這兩個詞。
再來看一張圖：
這是剛入門時，為了追求PPT的好看，做的一張概念圖。雖然當時還沒有體會到兩個詞的重要，但是從感覺上，我畫了以上的圖，有位前輩說，維度還不夠。
哦，我後來才知道，中間的圈裡，我大部分呈現的是度量，而下面的幾個圈，我列了重要的一些維度。至於上面的幾個圈裡，應該是呈現的分析專題或功能。
至於你平時有機會接觸到的各種資料視覺化，報表，也基本上脫離不了這兩個詞，比如，若你去客服部門分析客戶來電量（下圖僅供演示，非真實場景資料）
1. 你按時間趨勢來看總體來電量。當你發現某個月或某周來電量波動較大，你就需要新增別的“角度”來進一步細分。
2. 你按熱線來細分來電量，看看來電撥打的什麼熱線。
3. 當你發現某個熱線來電量波動異常後，你又需要進一步細分，看看此熱線的來電是被什麼接起公司承接的……
下面不賣關子了。有些人可能已經猜到了，我要分享的這兩個詞就是：維度+度量。
下圖中，我將重點放到大道至簡幾個字，以及維度+度量上，而維度和度量下面分別放了所在家族的一些其他常用詞彙，我稍後會解釋。
我始終認為在這條路上，我有一個兩詞之師，當我比較迷茫的時候，他就像當時教我游泳的導師一樣，告訴我：你不需要了解那麼多，只要瞭解資料的世界沒有那麼複雜，知道有什麼維度，看什麼度量，然後怎麼呈現出來即可。
對，他沒有時間教我別的，也沒有分享過任何文件給我，只告訴了我這句話，但是讓我受益至今，因為那一刻，就是恍然大悟。所以我現在也分享給你們。
定義：
1. 度量：即Metrics, 指量化的數值。一般都有個名稱，比如網頁瀏覽次數，網頁瀏覽時長，支付寶成交金額等等。平時，我們一般會叫成“指標”，但是在專業語境，你需要知道，指標和度量還是有些差異，比如某些場合，他們會用指標特指一些經過計算的度量結果，比如拿度量A（網站總瀏覽次數），除以度量B（網站總瀏覽人數），得到一個新的指標（網站人均瀏覽次數），用以衡量網站粘性。但是我建議你平時使用兩者可以通用。
2. 維度：即Dimension。指我們平時看事物的角度。比如，同樣是網站瀏覽次數（PV），我們可以從日期角度去看，也可以以流量來源去看（來自直接訪問的、來自微博的、來自搜尋的等），也可以以新老使用者分群來看。更多的場景是同時以兩個維度的組合去看，比如這樣的圖，就是同時結合了時間、來源兩個維度對網站流量進行分析：
兩者你知道如何清楚區分嗎？
雖然從定義上，你可以看出明顯不同，但是現實中，卻還是有人喜歡亂用——把明明屬於維度的東西寫成“我要看什麼指標”，或者喜歡用“我想從收藏人數這個維度去看”，雖然我屬於強迫症，喜歡幫別人的需求糾錯，被冠以扣字眼的“名號”，但是在這件事情，我一定要摳到底。
而且，你摳清楚了，以後你的世界也清晰很多。
區分的一個方法：維度，一定是有成員值的，且成員值是可以列舉出來的——不管它有多少，大不了你多花點時間去列舉，總之是一定可以列舉的，且會維持一定的穩定性。
比如，日期這個維度，幾月幾號一定是有限的，一年也就365天，如果是年這個維度，也是一樣的。城市這個維度更好理解了吧？
其他你需要了解的：
1. 度量：
除了指標這個有著略略差異的俗稱外，有時還會遇到衍生指標這個說法，比如拿指標A和指標B做運算得到的指標C就叫做衍生指標。此外，還要注意可累加以及不可累加的度量說法，比如網站UV（獨立訪問使用者數），這個指標就是典型的不可累加的度量：
除了指標這個有著略略差異的俗稱外，有時還會遇到衍生指標這個說法，比如拿指標A和指標B做運算得到的指標C就叫做衍生指標。此外，還要注意可累加以及不可累加的度量說法，比如網站UV（獨立訪問使用者數），這個指標就是典型的不可累加的度量：
某網站1月1日UV=100個，1月2日UV=200個，但是這兩天的UV不等於300個，因為1月2日的獨立使用者數裡可能包含了1月1日的使用者，所以如果要得到2天的UV，需要重新計算而不能直接相加。而像成交類的金額，不涉及到去重的問題，就叫可累加的度量。
2. 維度：
維度的層次：即Level。有些維度是獨立並列的關係，比如城市維度和時間維度。但是有些維度之間有層次關係，比如省份維度和城市維度，行業維度和類目維度，年級維度和班級維度等。有層次關係的維度，則可用於“鑽取”場景中，先彙總到比較粗的維度，當有需要的時候，可以層層鑽取到更加明細的維度，此時，也會把這些維度叫做某維度型別的不同“粒度”——比如會有一個虛擬的維度型別曰地區維度，而把省份、城市、區叫做地區維的粒度。維度的層次根據不同的需求，可能會鑽取到很細（Details）,那就是通常我們說的”明細資料”了。比如分析成交金額時，從行業維度，細分到一級類目乃至葉子類目，最後，鑽取到某個獨立的商品ID（不能再細了），商品ID就是最細小的層次維度。
這麼說可能會把你繞暈，那麼還是畫個圖吧（我真的適合當唐僧似的老師……o(╯□╰)o）
如上圖所示，左列也即維度，不管是國家、省份、城市，都是維度，但因為他們有層次關係，所以，有時會被描述為地區維度的不同粒度或層次（明白了吧）。而右側就是每個維度的維度成員了，有時也被叫成維度值。在可累加的度量中，每一個維度值相加，應該等於上級維度的某成員值總和。比如若城市A只有三個區，這三個區的人口總數應該等於城市A的。
維度的屬性：用以描述維度的一些屬性，比如上圖中“城市”這個維度吧，它可能會有一些屬性特徵，比如城市型別：省會城市、地級市、縣級市等，那麼有一個分析需求，可能還會按不同城市型別彙總細分。這種情況，維度的屬性會成為分析中的維度。
這時，你可能會明白，平時為什麼那麼多表單要填寫各種欄位，這些欄位，都可能是分析時的維度哦~
碼了這麼多，休息一下，給你們放張圖：
當時小貝和馬雲一碰面，無論在阿里還是網路上，都出現了一個兩難的問題：到底是選誰當老公呢？（能有這個問題的妹子，你真想多了……），其實這裡仔細分析，無非也是涉及到維度和度量兩詞：
維度：人啊。
維度成員：馬雲、小貝
度量：眾位妹子和弟弟們無非就是按自己心目中的演算法給兩位成員計算顏值、財富，以及自己心目中的權重，衡量一個綜合指數了……我可不敢隨便填。
最後，發現兩難的選擇，只能得到一個結論是：左邊的當老公，右邊的當爸爸。
點評：做夢吧您。
總結一下：
兩個詞的應用：無論你聽怎麼複雜的需求，以及無論你有多麼複雜的需求，請有傾向地提煉這兩個詞，因為這是你做資料產品、資料分析或者視覺化設計的基礎的基礎：
翻了自己的電腦半天，終於翻出一個不敏感的文件，供參考，下圖就是移動資料分析中的需求交付模版之一：左側列舉度量，右側標註出此度量需要看的維度，有時還會註明維度之間是否要交叉組合查詢。不展開。
2. 一個立方體
其實本文的精華就在兩個詞之間了。下面您看不看都成。
立方體在資料的世界裡叫做Cube。我想為何有立方體這個概念，應該是它很形象地能夠表達出多維的概念，至少有3維，如上圖所示，成交100億的金額，是一個大立方體的總量。如果按季度、行業、地區三個維度來分析，我們可以清楚地知道第三季度A地區女裝行業有多少——也即我用橙色標註的那一個切塊的量，是嗎？
那如果是我要知道B地區女裝行業四季度的成交總和呢？你怎麼切給我？
空間感好的同學已經知道怎麼切了，你知道嗎？
這只是切塊。我們還可以切片，比如我想要知道B地區所有行業的四個季度的成交總和，怎麼切？我想要知道男裝行業所有地區四個季度的成交總和怎麼切？
具體怎麼切，你們自己意會吧，篇幅有限，不展開。
現實分析場景中，恐怕不只三個維度，比如還要加上銷售部門維度、銷售渠道維度呢~ 那麼立方體可就複雜了，空間感差一些的同學，就想想不出來這個立方體什麼樣子了吧，事實上，資料開發同學會用雪花模型或者星型模型去建設這些立方體。你只要有這個立方體的概念就可以了……資料分析就是像玩魔方一下，撥弄著這些立方體。
在網上找了一個包含了我剛才說的鑽取、彙總的概念的立方體再給你們感受下，想要詳細學習的同學可以搜尋“資料立方體”繼續研究。
我剛才舉的那幾個切塊、切片的案例有毛用啊？
現實生活中，你提需求的時候，不可能讓你畫個立方體吧？是的，我們是以表格的方式去看資料的，比如第一個切塊，是什麼表格呢? 站在行業負責人，尤其是女裝負責人的視角，可能是這樣的一個報表：
當然，如果是某地區銷售經理，有可能是這樣的：
所以就有各種資料透視分析的視角。
總結：
資料分析就是在撥弄各種資料立方體，你可以切片、切塊、鑽取、彙總，你所玩的魔方每一塊，就是一個具體的度量值，是什麼數字，則是多種維度交叉後的結果。
工作實踐中，資料產品經理會考慮做出更加方便易用的“立方體玩法”以供普通使用者使用：
如，在分析客戶來電的自動語音導航服務中，我們就可以按不同的維度去對比看使用者在導航選單裡按鍵量，下圖所示是“按選單對比”的介面，在“對比按”中可以進行切換其他對比視角。
至於左側的兩個篩選，也即指篩選資料集合（切片或切塊了），比如限定某幾個熱線和選單去看。
3. 一張圖片
瞭解了維度、度量兩個詞，又有了立方體之概念，讓我們再來看資料是怎麼產生，怎麼被放到使用者介面上供查詢使用的。
巧婦難為無米之炊。資料不是憑空產生的，當需求方提出想要什麼樣的資料分析的時候，首先要檢視的是，TA需求中涉及到的維度是否確定被採集到？度量的計算成本是否高？比如若一個需求想要分析不同買家分層的留存，買家分層是一個新維度，需求方是按骨灰級、高階、新手等對買家進行分層。且什麼叫骨灰級？系統裡並未對買家進行打標記，且不同類目的骨灰級演算法還不一樣，加上演算法定義本身也在磨合。這種情況下，我們應該和需求方一起推動業務系統完成打標，而不是自己接下這個需求，在資料倉儲ETL環節完成。
瞭解ETL：這個是做資料工作繞不開的術語，E(抽取、清洗)——T（轉換）——L（裝載），抽取是從各個業務系統中抽取所需的資料，然後完成語義層、邏輯層的轉換，比如不同系統中記錄銷售渠道這個維度，有的叫做saleschannel,有的叫做channel,需要轉化為同一個概念。裝載，也可以理解成抽取、清洗、轉換好了，裝載到另外一個空間裡，供多維查詢服務應用呼叫。
當然，則個領域，水很深，我只能簡單描述一下，再深的也擔心大家暈菜了——畢竟本文是寫給非資料人的。（其實作者本人也講不粗來了……哈哈）
四. 應用
我說了，我無法教你具體複雜的資料分析案例。我希望能夠藉助本文和你分享下如何建立起比較專業的資料分析思路——資料產品經理本身也應該可以是優秀的資料分析師。
1. 三部曲——建立分析框架
建立分析框架：瞭解業務、以及業務想要什麼（目標）。
提交資料需求: 根據你的訪談、梳理，得到業務流程、業務願景以及目標，那麼就可以和需求方共同確認“看什麼”以及“怎麼看”。好的資料產品經理或者資料分析師，永遠不是坐等需求方提出他要看什麼度量和維度，而是要引導對方看更合適的東西以回答他關於目標是否達成的問題。
進行資料分析：使用多種維度，進行總體的、細分的、多維的分析，當發現問題時，能夠使用這些維度的組合幫助使用者找到影響原因。
一切都基於你有多瞭解業務：
下圖是幾年前的老圖了，左側是業務流程圖（業務流程圖怎麼畫），右側是概念中的數字體系示意（視覺化是為了更好和需求方溝通）。
PPT裡因為存在具體業務的案例，不便分享，到此為止吧。如果有時間的話，我還是會編脫離具體業務的案例的……這就是寫部落格的苦逼之處，工作中都是工作的案例，為了寫篇部落格，還得自己再編一套有板有眼的故事……
2. 三部曲——提交資料需求
故意放了張你可能看不清楚的圖（o(╯□╰)o），所以別問我要大圖了，謝謝~
左側就是度量分類和度量，從標註了顏色底色開始的就是維度了，標了顏色的也即此指標需要被計算到所需的維度，灰色的表示不需要，黃色和綠色（以及上面的數字1、2），表示優先順序不同，黃色的當然是高優先順序了。比如黃色上我寫的數字應該是1,也即第一優先順序。
實際上，依據不同的場景，當然可以有很多簡化，比如無需標註優先順序之類的。
此外，還需要單獨提供維度和度量的詳細口徑定義說明表格，這時最好和分析師一起，詳細進行確認。
3. 三部曲——進行資料分析
你提的需求不管是做成報表、還是做成具體視覺化的介面，總之如果已經開發出來了，就來玩魔方吧。只是報表有可能你得匯出來在EXCEL裡玩魔方。（即使是視覺化的介面，也依賴於對方設計得是否易用）
最簡單的分析是逐級鑽取，如：，
複雜的則需要多維交叉：
比如，當分析某個APP的Active users, 當我已經鎖定某個省份有問題的時候，我們既可以繼續鑽取到城市去明曉細節，又可以交叉到品牌，看不同省份間品牌偏好的問題。比如是否小城市中安卓品牌的人更加活躍。
五. 留點作業：要記得思考哦
1. Detail頁面的設計師被追責，怎麼應對？
某日，負責搜尋結果頁（LIST）的設計師來找商品詳情頁（Detail），他好容易做了LIST頁面的改版，而且結果也確實喜人，從List頁面到Detailye頁面的轉化率確實提升了（比如原來100萬的人來到List頁面，只有40萬繼續點選到Detail,改版後，變成了50萬）。但是不幸的是，總體從L到訂單的轉化率卻沒有提升，反而下降了。
請問，如果你是Detail的分析師，如何和List的分析師一起想辦法分析什麼原因？
2. 掛羊頭賣狗肉的Banner，怎麼用資料證明其反而有害無益？
五. 最後，嘮叨幾句
最後，分享給各位的心得是：
你現在也知道，資料本身需要經過分析師的定義、資料來源系統的採集、資料開發的開發以及展現設計，任何一個環節，可能會產出錯誤的資料，所以資料本身未必100%靠譜。
此外，資料的解讀，需要保持謹慎批判之心。比如同樣是小明語文得了59分，如果你不瞭解上下文以及歷史趨勢的話，會認為小明沒考好，有的人甚至會得出小明語文不好的結論。而要是瞭解他上個季度每次語文考試都只有30多分，又會得出小明雖然語文不好但是明顯進步了。而要是瞭解到這個班級平均分數只有49分，你又會覺得小明簡直太讚了！所以，單純的一個數字本身沒有任何意義，要窺一斑，更要知全貌。
此外，資料會被有心計的故意利用，而向你呈現部分事實（他不是在彎曲事實，而是隻呈現對他有利的一面），資料本身有那麼多維度以及層次，導致解讀的方式完全可以被利用。
所以，要記得我本文的最後提點：
對於產品經理和分析師來講，最針對的是我們基於對於業務的深入理解而產生的直覺。不要盲目被資料拉著走。只有有較好的直覺，我們才能有更合理的假設，有了這個合理的假設，才能夠更好解讀資料以及提資料的需求。而不是在各種資料的海洋裡玩資料的遊戲而浪費時間。
作者，謝雨巨集，從事過互動設計的資料產品專家，目前就職於阿里巴巴，負責客戶服務領域的相關資料產品規劃及建設。
heidi格物志
摘自：http://heidixie.lofter.com/post/b8226_6e83806