給30個PM拉了一年的sql，我學到了這些

01-30

--題記--

《最後的武士》

場景：Nathan(克魯斯)被 Katsumoto（渡邊謙）將軍剛綁入山村，在寺廟中的對話

Nathan:「Why we have this conversation?」

Katsumoto:"We are both students of war"

我們都是數據戰場的學生，基於此，無敵無友，只是恰巧走在同一條路，把經驗教訓作為一份禮物送給未來的自己和同行。

--正文--

一年前，懷著見證數據落地來推動產品迭代的想法，從某乙方諮詢公司進入某OTA機票前台產品部門。一個數據人說的是自己；產品團隊PM記為30人（從年初20人擴充到年底40人），下面就是我和30個PM（PM=product manager產品經理）的互動過程。

【面臨問題】

入職第一天，我被告知整個產品部門只有我一個數據，從一位android開發GG手中交接到hive資料庫許可權的賬號後，我發現自己面對的是一個看不到盡頭的坑。

部門面臨的問題

PM獲取數據周期非常長，即使是一個join的sql取數都需要一周排期，這對於「項目上線後第二天就要看到數據「領導貫徹的思想嚴重背馳
PM拿到數據後不敢用，因為bi獲取周期長，PM會利用私人關係從二線運營拿數據臨時應急，但發現同樣的維度不同部門拿到的結果不一致，大家用的數據表也不完全相同，pm在中間成為夾心餅乾，用也不是不用也不是，後來寧願拍腦袋下決定。

基於上述的問題，當時的七級領導商量著要在前台放一個數據，同時要貼近業務能解決問題的人進來，於是機緣巧合，我在尋找靠譜甲方，覺得平台不錯領導挺好，就上了船了。

進來之後領導語重心長對我表示了希望：能不能將數據獲取時間縮短，比如說三小時，百度和google的數據時間我記得沒那麼長（領導之前是從google和百度出身）。雖然我也有自己的想法，但拿個數據都要等一個周，那別的就玩不下去了，於是爽快答應。但之後發現這個遠比想像的要難。

自己遇到的問題

組織架構問題：我以產品經理的身份進入，帶我的mentor也是一位資深的產品GG，交接給我資料庫賬號的GG是android開發，於是我驚奇地發現，整個部門（包括mentor）都是向我提需求的人！而我和bi部門是跨部門溝通！本來產品部門的需求就很多，他們已經做不過來，現在又來一個啥也不懂的"PM"問東問西，換做是我也不會給出好臉色。
數據問題：這裡具體解釋一下我將當時的處境看作是黑洞的原因。當時二線運營是sqlserver庫(可以創建臨時表)，bi主要用hive庫，而且bi每個人用的hive庫也不盡相同，有時候同樣一個訂單表，不同的人用的表不一樣，不同表的欄位什麼意思，欄位的編碼維表是什麼，怎麼使用，這些錯綜複雜的關係至少是N的平方的複雜度。
資料庫語言的問題：這是目前為止最容易解決的問題，因為可以自己百度解決。上一家公司主要是sqlserver，在此因為許可權的問題最後統一選擇hive在作為第一選擇（因為可以申請創建臨時表的許可權），這裡面夾雜著hive/mysql/presto/sqlserver的語言轉換。

【解決問題】

現在來看已經基本解決當時的問題，而且建立了一種動態平衡且多贏的局面。但這並不是在一開始就想好如何去做，而是心中有個信念，在合適的時間做合適的事情。就像夜晚開車從上海到北京的高速路上，車燈只能看到前方50m，但是只要開好這眼前的50m，最後一定能到目的地。而我當時的第一個50m當務之急是我要迅速建立大家對於數據的信任。

建立信任

雖然每個人都急迫想要數據，但內心並沒有消除對數據的不信任，這是一種很複雜的感情。以我現在的情況，不可能兩者同時滿足，而且經得起驗證的數據的基礎上，快速響應才有意義，所以我穩紮穩打，先求質量。數據流為產品端=>我=>數據，建立PM對於我的信任，然後信任再慢慢轉移到數據上。

交叉驗證：對於所有經過我手的數據，只要是第一次跑數，都會找我熟悉的數據源交叉驗證，這樣我可以保證經過我手的數據經得起考驗，在歷次大規模數據核查中，我沒有失手過，即使是和友商的數據全盤對比。同時練就出在和其他部門的數據交換中，如果遇到不一致的情況，通過sql就可以看出卻別在哪裡，誰的篩選條件更貼近真實。
量變到質變：內心的信念體現在每天sql的一遍一遍地重複地訓練。當時pm採用二線運營的sql，我會把需求拿過來重跑，再換成hive重跑，有語法問題就百度，欄位問題和使用哪些表，實在不會的就記下來，（關於公司級元數據字典，機票hive只有一張訂單主表是有解釋的，其他的都沒有注釋，只是用來看錶結構和查找欄位名），當天下午五點鐘統一找bi的pm詢問。（必須有具體的欄位或者表問題才好提問，而且bi童鞋時間寶貴，磨合很久好容易說每天下午5點開始留個時間來問問題）。
大概一個月的時間對很多欄位掌握以後，之後都是靠自己多跑sql來多驗證，3個月後差不多對新接的需求問題就比較少，再通過3個月的磨練，按照5個team平均每天2個sql來算，半年的時間 5team*2sql*180*5/7(工作日)>=1200，至少1200個sql的訓練，基本上可以出山。
8020法則：在訓練過程中，我一直相信所有的需求無非是訂單和行為，肯定是有幾張主表，80%的需求都會跟這幾張主表有關，於是前期針對這些表死磕，欄位、格式、使用場景、埋點方式等，後來經過實症，確實如預期，對於快速上手和建立自信有很大的幫助。

固化報表

在最初既不懂業務有不明白數據結構的時候，有一次去bi同事請教問題，TA問了一句」你在產品做的是什麼？乾脆來bi好了。「這個問題其實從我剛開始進入公司就一直問自己，當我越來越擅長理解需求，資料庫拉取sql的時候，我愈加清楚，不能活在舒適圈，提醒自己」你不只是來拉sql的「。

但是PM能夠及時獲取數據的時候，當初對數據的好奇以及使用的方便性（我就坐在產品團隊的中間位置，七級總監的旁邊，拉個sql喊一聲就能聽見），他們對於數據的需求也被集中釋放，我被越來越多的需求所堆積，很多人也開始建議我可以招實習生或者正式員工，但是我想到自己還沒有把這條路走通前帶其他人進來是對別人的不負責任，而且我依然相信可以把事情搞定。

固化需求，建立業務報表：在常規報表存在的基礎上，眾多業務型很強維度很細的需求無法滿足，他們的數據散落在各個角落，需要在常規報表的維度上再加一層計算會比較方便易懂，我針對5個team不同的業務屬性，向bi申請建報表的許可權，自己搗鼓出100多張報表，戲稱為」小米+步槍「的游擊隊，是對正規軍的有效補充，更加平易近人。其中一個新team還沒有體系的報表，我們一起琢磨構建了一套，幫助他們有效地節約前期獲取數據的時間，備受好評。
沒有條件自己創造，自行搭建mysql中間庫：為保證查詢效率，公司的報表大多是sqlserver庫存儲中間表，但我們人微言輕申請不到資源（需要CTO審批購買刀片伺服器），於是自己找一台廢舊台式機，在上面搭建mysql伺服器（感謝android開發GG），存放中間表數據，通過zeus平台建立調度任務ETL（在一次資源審核上我驚奇地發現我的調度任務數已經可以在公司排進前十），將hive數據聚合後存放到mysql，報表平台再讀mysql。經過這樣搗鼓，平均每天的工作量可以降低50%以上。

培訓PM玩轉數據

上半年基本上滿足七級領導當初交給我的任務，用了三個月的時間來給出準確的數據，又用了三個月的時間來提升效率。半年多一直都是在被動地接受PM提出的需求，而此時我騰出時間，同時對產品和數據都建立初步的理解，我開始主動觀察前台PM對數據的使用情況。

發現對於數據這個激光槍，他們竟然還在當燒火棍在用。通俗點說，從對互聯網數據指標的理解、基礎報表的正確使用、ABtest的報表的解讀、如何用數據實現對產品的迭代等等，都還沒有具備一個清晰的認識。雖然我不知道對上述問題的解答有沒有達到專業水準，但是應用領域無權威，說上就上。

於是在2016年9月份，正值開學季，在每周二晚上7點-9點，對於內容分為四個主題，分四次講解，由淺入深，組織《開學啦》系列分享。反響強烈，四份ppt不僅是pm也可以做bi新入職員工的前台數據培訓教材。

第一次分享目的是激發PM對於數據的興趣和基本認識。重點把不同場景下的基礎數據指標說清楚，從哪裡來->埋點，在哪裡用->UIP報表，如何用->case by case。對於基礎報表UIP部分，因為項目數據分散、基礎數據與我無關等的原因被多數PM所棄用，但其實基礎報表最重要的作用是告訴你什麼是正常！當你知道主流程的正常數據，才會知道什麼樣的數據是不正常的。當其他數據於此衝突的時候以基礎報表為準，當看自己的項目數據與主流程的數據做交叉驗證的時候，看到自己where we are。

第二次分享目的是解決PM如何用好Abtest來迭代產品，重點是把如何利用abtest的報表數據來定位問題、實現產品的快速迭代，因為abtest不是說新項目表現不好而砍掉，而是新項目上線後如何不斷改善優於舊版本，以提升kpi，所以大概率情況下會遇到定位問題的場景。其實這個分析主要是一個公式反覆在用，用好TA基本上可以幫助解決80%的問題（剩下20%就需要專業的數據人員來介入）。同時對abtest的數據收集流程和常用名詞作說明。（比如正交測試、AA驗證）

第三次分享的目的是讓pm有能力通過sql來驗證腦中的idea。本次是對之前的進階，講了更多detail的內容，包括頁面/點擊/trace->行為表，訂單/航段->訂單表的主要欄位說明，行為和訂單關聯的方法，sql的運行平台hive/presto/sqlserver/mysql，sql基礎語法以及最重要的是每篇配上簡單可直接運行的sql，pm們可以線下自己來嘗試。
經過之後一兩個月的邊做邊學，每個團隊平均有兩個pm可以實現2個join以內的hive運行，對於簡單的訂單和行為關聯，諸如「起飛前兩小時內訪問首頁的人數是多少？」可以獨立完成。

第四次分享的目的是PM可以根據現有sql來製作報表。每個PM關注的項目數據各不相同，這些數據需要彙報給後台及業務部門，有些是每天都需要手工整理，重複勞動而且非常耗時。經過調研發現，這些數據可能也就是2-3個join的sql。經過簡單培訓，有心的PM自助來做其實也是非常簡單。
經過培訓及之後的項目歷練，大部分pm的類似小需求都可以自助日報。而我會在報表出現問題的時候出現，而BI可以專註於成套體系的複雜報表。PM對自己的項目數據非常急迫，有一種經過簡單培訓便可以獲取數據，不需要排期，他們是非常歡迎的；bi也被釋放工作量，可以專註於複雜報表的設計製作和維護。本次講解內容包括zeus調度hive源數據->mysql中間表->ART報表平台展現。

【見證產品迭代】

一年已過，真正看懂我的四張PPT的PM童鞋在產品端的數據分析可以非常有自信地拿出手來證明自己的kpi，可以和bi侃侃而談sql取數邏輯是否符合需求，同時對於後台的業務部門的報表每天默默有序地自動發送，提升了效率，自信了人生。

那對於我來說，我當初加入的初衷，數據到底能對產品迭代產生多大作用？前台產品中數據人存在的意義在哪裡？深夜回顧如下。

我司前台產品講求快速迭代，即快速上線快速試錯快速優化，如此往複以至於最終的kpi目的。這裡面數據就像一個潤滑油，保證飛速的車輪在飛速馳騁，在換軌道的時候保持方向清晰。這就要求數據首先要准、及時以及能用數據定位問題。而這三方面往往需要一個資深的數據人來把關。下面的說明可能與上面重疊，但為了證明價值進行復用，也說明思維的一致性。

數據準確性

盡信不如不信，對數據的信心是建立在充分懷疑的基礎上的，而且非常清楚其使用場景。一個優秀的數據人不僅是自己而且可以讓PM能夠通過基礎報表建立基本sense，同時了解sql輔助交叉驗證。最後造成的轉變是，從原來懷疑數據不敢用，到相信數據，再到帶著懷疑的態度驗證數據再用，產生質的轉變。

數據及時性

在快速迭代中，今天上午覺得在某個新上的項目中某個指標維度可用，下午用sql驗證一下，然後馬上上報表，第二天作為新項目指標監測的一部分來輔助決策。這樣的效率，如果數據人和產品分屬兩個不同部門，因為kpi的原因很難產生這樣的協同效果。

大部分情況下，bi部門提供報表但是不提供分析，個人很難有成就感，而且很難激發主觀能動性；而分析需要結合業務場景，有心的bi人員會多了解一些業務場景對報表和之後的分析提出建議，但更多的是在做一份工作，報表就變成一堆枯燥的數據。

一種方案是，簡單的報表通過前台數據人提供一段sql交給PM自助建立報表，臨時性複雜（語法在3個join以上或使用非常用表）的報表由前台數據人員建立報表支持，長期的複雜性的報表由bi部門建立報表並維護。前台數據是及時性支持，重時效輕維護，當數據穩定後，相關數據可下線或併入bi的基礎報表中；bi部門是，常規系統的報表由bi設計並維護。

定位問題

定位問題也是不斷試錯的過程，需要在了解業務場景的情況下，不斷提出假設、用數據驗證、再提出假設的過程，直至整個項目符合預期目標。

提出假設是最考驗數據人功力的一環，結合業務場景去思考問題點，然後挑出最有可能的幾種來分別驗證。對業務最能直接產生價值的是定位問題，數據有效和及時都只能說是基本功，而快速精準定位問題，並能用數據說服其他人這就是問題所在並能提出方案，這是綜合能力的直接體現。因為這包含對數據的理解，對業務場景的理解，對人心的把握，當然如果對初級人員每次都是窮舉法所有的可能性的點，勤能補拙，不斷總結，會找到自己的分析style。

比如之前的嬰童流程改造項目，首頁點擊嬰童的icon之後，進入嬰童的新流程。新流程上線後，整體嬰童訂單量佔比上升同時新流程的轉化率低於舊版轉化率，但在整體嬰童訂單中從新流程下單的比例較低，於是決定把首頁嬰童icon的大小和顏色更加醒目，讓目標人群注意到新流程，上線後嬰童訂單量進一步上升。在持續改進的過程中發現用於在填寫頁之後的轉化率明顯較低，經過定位發現用戶在填寫頁回退上操作異常，單頁面上所有點擊數據波動不明顯。這時候我們面對的問題是用戶在填寫頁這附近遇到困惑，但現有數據無法定位出用戶的困惑，於是申請資源請用戶研究部門進行電話回訪，發現很多有價值的信息，比如價格問題排序問題等，針對性改進後轉化率有明顯提升。

--結尾--

將這些經驗分享出來有兩個目的，一個是2016年事兒上練心的記錄，一個是給大家展示可以達到的效果及方法，如果你覺得有效，可以自己嘗試，自助者天助。

更多關於數據分析的思路分享，請follow公眾號：數據自由之路/dataFreeLife