[[188161]]

面臨問題

入職第一天，我被告知整個產品部門只有我一個數據，從一位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新入職員工的前臺數據培訓教材。

[[188162]]

第一次分享目的是激發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年事兒上練心的記錄，一個是給大家展示可以達到的效果及方法，如果你覺得有效，可以自己嘗試，自助者天助。

如果有覺得頻率相同的人，可以一起加微信，倒不是找同聊，而是建立朋友圈(和而不同)。

 【本文為51CTO專欄作者“李寧”的原創稿件，轉載請通過51CTO聯系作者獲取授權】