建站
咨詢
售后
建站咨詢
新聞中心
面臨問題
入職第一天，我被告知整個產(chǎn)品部門只有我一個數(shù)據(jù)，從一位android開發(fā)GG手中交接到hive數(shù)據(jù)庫權(quán)限的賬號后，我發(fā)現(xiàn)自己面對的是一個看不到盡頭的坑。
部門面臨的問題
- PM獲取數(shù)據(jù)周期非常長，即使是一個join的sql取數(shù)都需要一周排期，這對于“項目上線后第二天就要看到數(shù)據(jù)“領(lǐng)導(dǎo)貫徹的思想嚴重背馳
- PM拿到數(shù)據(jù)后不敢用，因為bi獲取周期長，PM會利用私人關(guān)系從二線運營拿數(shù)據(jù)臨時應(yīng)急，但發(fā)現(xiàn)同樣的維度不同部門拿到的結(jié)果不一致，大家用的數(shù)據(jù)表也不完全相同，pm在中間成為夾心餅干，用也不是不用也不是，后來寧愿拍腦袋下決定。
基于上述的問題，當時的七級領(lǐng)導(dǎo)商量著要在前臺放一個數(shù)據(jù)，同時要貼近業(yè)務(wù)能解決問題的人進來，于是機緣巧合，我在尋找靠譜甲方，覺得平臺不錯領(lǐng)導(dǎo)挺好，就上了船了。
進來之后領(lǐng)導(dǎo)語重心長對我表示了希望：能不能將數(shù)據(jù)獲取時間縮短，比如說三小時，百度和google的數(shù)據(jù)時間我記得沒那么長(領(lǐng)導(dǎo)之前是從google和百度出身)。雖然我也有自己的想法，但拿個數(shù)據(jù)都要等一個周，那別的就玩不下去了，于是爽快答應(yīng)。但之后發(fā)現(xiàn)這個遠比想象的要難。
自己遇到的問題
- 組織架構(gòu)問題：我以產(chǎn)品經(jīng)理的身份進入，帶我的mentor也是一位資深的產(chǎn)品GG，交接給我數(shù)據(jù)庫賬號的GG是android開發(fā)，于是我驚奇地發(fā)現(xiàn)，整個部門(包括mentor)都是向我提需求的人!而我和bi部門是跨部門溝通!本來產(chǎn)品部門的需求就很多，他們已經(jīng)做不過來，現(xiàn)在又來一個啥也不懂的"PM"問東問西，換做是我也不會給出好臉色。
- 數(shù)據(jù)問題：這里具體解釋一下我將當時的處境看作是黑洞的原因。當時二線運營是sqlserver庫(可以創(chuàng)建臨時表)，bi主要用hive庫，而且bi每個人用的hive庫也不盡相同，有時候同樣一個訂單表，不同的人用的表不一樣，不同表的字段什么意思，字段的編碼維表是什么，怎么使用，這些錯綜復(fù)雜的關(guān)系至少是N的平方的復(fù)雜度。
- 數(shù)據(jù)庫語言的問題：這是目前為止最容易解決的問題，因為可以自己百度解決。上一家公司主要是sqlserver，在此因為權(quán)限的問題最后統(tǒng)一選擇hive在作為第一選擇(因為可以申請創(chuàng)建臨時表的權(quán)限)，這里面夾雜著hive/mysql/presto/sqlserver的語言轉(zhuǎn)換。
解決問題
現(xiàn)在來看已經(jīng)基本解決當時的問題，而且建立了一種動態(tài)平衡且多贏的局面。但這并不是在一開始就想好如何去做，而是心中有個信念，在合適的時間做合適的事情。就像夜晚開車從上海到北京的高速路上，車燈只能看到前方50m，但是只要開好這眼前的50m，最后一定能到目的地。而我當時的第一個50m當務(wù)之急是我要迅速建立大家對于數(shù)據(jù)的信任。
建立信任
雖然每個人都急迫想要數(shù)據(jù)，但內(nèi)心并沒有消除對數(shù)據(jù)的不信任，這是一種很復(fù)雜的感情。以我現(xiàn)在的情況，不可能兩者同時滿足，而且經(jīng)得起驗證的數(shù)據(jù)的基礎(chǔ)上，快速響應(yīng)才有意義，所以我穩(wěn)扎穩(wěn)打，先求質(zhì)量。數(shù)據(jù)流為產(chǎn)品端=>我=>數(shù)據(jù)，建立PM對于我的信任，然后信任再慢慢轉(zhuǎn)移到數(shù)據(jù)上。
- 交叉驗證：對于所有經(jīng)過我手的數(shù)據(jù)，只要是第一次跑數(shù)，都會找我熟悉的數(shù)據(jù)源交叉驗證，這樣我可以保證經(jīng)過我手的數(shù)據(jù)經(jīng)得起考驗，在歷次大規(guī)模數(shù)據(jù)核查中，我沒有失手過，即使是和友商的數(shù)據(jù)全盤對比。同時練就出在和其他部門的數(shù)據(jù)交換中，如果遇到不一致的情況，通過sql就可以看出卻別在哪里，誰的篩選條件更貼近真實。
- 量變到質(zhì)變：內(nèi)心的信念體現(xiàn)在每天sql的一遍一遍地重復(fù)地訓(xùn)練。當時pm采用二線運營的sql，我會把需求拿過來重跑，再換成hive重跑，有語法問題就百度，字段問題和使用哪些表，實在不會的就記下來，(關(guān)于公司級元數(shù)據(jù)字典，機票hive只有一張訂單主表是有解釋的，其他的都沒有注釋，只是用來看表結(jié)構(gòu)和查找字段名)，當天下午五點鐘統(tǒng)一找bi的pm詢問。(必須有具體的字段或者表問題才好提問，而且bi童鞋時間寶貴，磨合很久好容易說每天下午5點開始留個時間來問問題)。
大概一個月的時間對很多字段掌握以后，之后都是靠自己多跑sql來多驗證，3個月后差不多對新接的需求問題就比較少，再通過3個月的磨練，按照5個team平均每天2個sql來算，半年的時間 5team*2sql*180*5/7(工作日)>=1200，至少1200個sql的訓(xùn)練，基本上可以出山。
- 8020法則：在訓(xùn)練過程中，我一直相信所有的需求無非是訂單和行為，肯定是有幾張主表，80%的需求都會跟這幾張主表有關(guān)，于是前期針對這些表死磕，字段、格式、使用場景、埋點方式等，后來經(jīng)過實癥，確實如預(yù)期，對于快速上手和建立自信有很大的幫助。
固化報表
在最初既不懂業(yè)務(wù)有不明白數(shù)據(jù)結(jié)構(gòu)的時候，有一次去bi同事請教問題，TA問了一句”你在產(chǎn)品做的是什么?干脆來bi好了。“這個問題其實從我剛開始進入公司就一直問自己，當我越來越擅長理解需求，數(shù)據(jù)庫拉取sql的時候，我愈加清楚，不能活在舒適圈，提醒自己”你不只是來拉sql的“。
但是PM能夠及時獲取數(shù)據(jù)的時候，當初對數(shù)據(jù)的好奇以及使用的方便性(我就坐在產(chǎn)品團隊的中間位置，七級總監(jiān)的旁邊，拉個sql喊一聲就能聽見)，他們對于數(shù)據(jù)的需求也被集中釋放，我被越來越多的需求所堆積，很多人也開始建議我可以招實習(xí)生或者正式員工，但是我想到自己還沒有把這條路走通前帶其他人進來是對別人的不負責(zé)任，而且我依然相信可以把事情搞定。
- 固化需求，建立業(yè)務(wù)報表：在常規(guī)報表存在的基礎(chǔ)上，眾多業(yè)務(wù)型很強維度很細的需求無法滿足，他們的數(shù)據(jù)散落在各個角落，需要在常規(guī)報表的維度上再加一層計算會比較方便易懂，我針對5個team不同的業(yè)務(wù)屬性，向bi申請建報表的權(quán)限，自己搗鼓出100多張報表，戲稱為”小米+步槍“的游擊隊，是對正規(guī)軍的有效補充，更加平易近人。其中一個新team還沒有體系的報表，我們一起琢磨構(gòu)建了一套，幫助他們有效地節(jié)約前期獲取數(shù)據(jù)的時間，備受好評。
- 沒有條件自己創(chuàng)造，自行搭建mysql中間庫：為保證查詢效率，公司的報表大多是sqlserver庫存儲中間表，但我們?nèi)宋⒀暂p申請不到資源(需要CTO審批購買刀片服務(wù)器)，于是自己找一臺廢舊臺式機，在上面搭建mysql服務(wù)器(感謝android開發(fā)GG)，存放中間表數(shù)據(jù)，通過zeus平臺建立調(diào)度任務(wù)ETL(在一次資源審核上我驚奇地發(fā)現(xiàn)我的調(diào)度任務(wù)數(shù)已經(jīng)可以在公司排進前十 )，將hive數(shù)據(jù)聚合后存放到mysql，報表平臺再讀mysql。經(jīng)過這樣搗鼓，平均每天的工作量可以降低50%以上。
培訓(xùn)PM玩轉(zhuǎn)數(shù)據(jù)
上半年基本上滿足七級領(lǐng)導(dǎo)當初交給我的任務(wù)，用了三個月的時間來給出準確的數(shù)據(jù)，又用了三個月的時間來提升效率。半年多一直都是在被動地接受PM提出的需求，而此時我騰出時間，同時對產(chǎn)品和數(shù)據(jù)都建立初步的理解，我開始主動觀察前臺PM對數(shù)據(jù)的使用情況。
發(fā)現(xiàn)對于數(shù)據(jù)這個激光槍，他們竟然還在當燒火棍在用。通俗點說，從對互聯(lián)網(wǎng)數(shù)據(jù)指標的理解、基礎(chǔ)報表的正確使用、ABtest的報表的解讀、如何用數(shù)據(jù)實現(xiàn)對產(chǎn)品的迭代等等，都還沒有具備一個清晰的認識。雖然我不知道對上述問題的解答有沒有達到專業(yè)水準，但是應(yīng)用領(lǐng)域無權(quán)威，說上就上。
于是在2016年9月份，正值開學(xué)季，在每周二晚上7點-9點，對于內(nèi)容分為四個主題，分四次講解，由淺入深，組織《開學(xué)啦》系列分享。反響強烈，四份ppt不僅是pm也可以做bi新入職員工的前臺數(shù)據(jù)培訓(xùn)教材。
第一次分享目的是激發(fā)PM對于數(shù)據(jù)的興趣和基本認識。重點把不同場景下的基礎(chǔ)數(shù)據(jù)指標說清楚，從哪里來->埋點，在哪里用->UIP報表，如何用->case by case。對于基礎(chǔ)報表UIP部分，因為項目數(shù)據(jù)分散、基礎(chǔ)數(shù)據(jù)與我無關(guān)等的原因被多數(shù)PM所棄用，但其實基礎(chǔ)報表最重要的作用是告訴你什么是正常!當你知道主流程的正常數(shù)據(jù)，才會知道什么樣的數(shù)據(jù)是不正常的。當其他數(shù)據(jù)于此沖突的時候以基礎(chǔ)報表為準，當看自己的項目數(shù)據(jù)與主流程的數(shù)據(jù)做交叉驗證的時候，看到自己where we are。
第二次分享目的是解決PM如何用好Abtest來迭代產(chǎn)品，重點是把如何利用abtest的報表數(shù)據(jù)來定位問題、實現(xiàn)產(chǎn)品的快速迭代，因為abtest不是說新項目表現(xiàn)不好而砍掉，而是新項目上線后如何不斷改善優(yōu)于舊版本，以提升kpi，所以大概率情況下會遇到定位問題的場景。其實這個分析主要是一個公式反復(fù)在用，用好TA基本上可以幫助解決80%的問題(剩下20%就需要專業(yè)的數(shù)據(jù)人員來介入)。同時對abtest的數(shù)據(jù)收集流程和常用名詞作說明。(比如正交測試、AA驗證)
第三次分享的目的是讓pm有能力通過sql來驗證腦中的idea。本次是對之前的進階，講了更多detail的內(nèi)容，包括頁面/點擊/trace->行為表，訂單/航段->訂單表的主要字段說明，行為和訂單關(guān)聯(lián)的方法，sql的運行平臺hive/presto/sqlserver/mysql，sql基礎(chǔ)語法以及最重要的是每篇配上簡單可直接運行的sql，pm們可以線下自己來嘗試。
經(jīng)過之后一兩個月的邊做邊學(xué)，每個團隊平均有兩個pm可以實現(xiàn)2個join以內(nèi)的hive運行，對于簡單的訂單和行為關(guān)聯(lián)，諸如“起飛前兩小時內(nèi)訪問首頁的人數(shù)是多少?”可以獨立完成。
第四次分享的目的是PM可以根據(jù)現(xiàn)有sql來制作報表。每個PM關(guān)注的項目數(shù)據(jù)各不相同，這些數(shù)據(jù)需要匯報給后臺及業(yè)務(wù)部門，有些是每天都需要手工整理，重復(fù)勞動而且非常耗時。經(jīng)過調(diào)研發(fā)現(xiàn)，這些數(shù)據(jù)可能也就是2-3個join的sql。經(jīng)過簡單培訓(xùn)，有心的PM自助來做其實也是非常簡單。
經(jīng)過培訓(xùn)及之后的項目歷練，大部分pm的類似小需求都可以自助日報。而我會在報表出現(xiàn)問題的時候出現(xiàn)，而BI可以專注于成套體系的復(fù)雜報表。PM對自己的項目數(shù)據(jù)非常急迫，有一種經(jīng)過簡單培訓(xùn)便可以獲取數(shù)據(jù)，不需要排期，他們是非常歡迎的;bi也被釋放工作量，可以專注于復(fù)雜報表的設(shè)計制作和維護。本次講解內(nèi)容包括zeus調(diào)度hive源數(shù)據(jù)->mysql中間表->ART報表平臺展現(xiàn)。
見證產(chǎn)品迭代
一年已過，真正看懂我的四張PPT的PM童鞋在產(chǎn)品端的數(shù)據(jù)分析可以非常有自信地拿出手來證明自己的kpi，可以和bi侃侃而談sql取數(shù)邏輯是否符合需求，同時對于后臺的業(yè)務(wù)部門的報表每天默默有序地自動發(fā)送，提升了效率，自信了人生。
那對于我來說，我當初加入的初衷，數(shù)據(jù)到底能對產(chǎn)品迭代產(chǎn)生多大作用?前臺產(chǎn)品中數(shù)據(jù)人存在的意義在哪里?深夜回顧如下。
我司前臺產(chǎn)品講求快速迭代，即快速上線快速試錯快速優(yōu)化，如此往復(fù)以至于最終的kpi目的。這里面數(shù)據(jù)就像一個潤滑油，保證飛速的車輪在飛速馳騁，在換軌道的時候保持方向清晰。這就要求數(shù)據(jù)首先要準、及時以及能用數(shù)據(jù)定位問題。而這三方面往往需要一個資深的數(shù)據(jù)人來把關(guān)。下面的說明可能與上面重疊，但為了證明價值進行復(fù)用，也說明思維的一致性。
數(shù)據(jù)準確性
盡信不如不信，對數(shù)據(jù)的信心是建立在充分懷疑的基礎(chǔ)上的，而且非常清楚其使用場景。一個優(yōu)秀的數(shù)據(jù)人不僅是自己而且可以讓PM能夠通過基礎(chǔ)報表建立基本sense，同時了解sql輔助交叉驗證。最后造成的轉(zhuǎn)變是，從原來懷疑數(shù)據(jù)不敢用，到相信數(shù)據(jù)，再到帶著懷疑的態(tài)度驗證數(shù)據(jù)再用，產(chǎn)生質(zhì)的轉(zhuǎn)變。
數(shù)據(jù)及時性
在快速迭代中，今天上午覺得在某個新上的項目中某個指標維度可用，下午用sql驗證一下，然后馬上上報表，第二天作為新項目指標監(jiān)測的一部分來輔助決策。這樣的效率，如果數(shù)據(jù)人和產(chǎn)品分屬兩個不同部門，因為kpi的原因很難產(chǎn)生這樣的協(xié)同效果。
大部分情況下，bi部門提供報表但是不提供分析，個人很難有成就感，而且很難激發(fā)主觀能動性;而分析需要結(jié)合業(yè)務(wù)場景，有心的bi人員會多了解一些業(yè)務(wù)場景對報表和之后的分析提出建議，但更多的是在做一份工作，報表就變成一堆枯燥的數(shù)據(jù)。
一種方案是，簡單的報表通過前臺數(shù)據(jù)人提供一段sql交給PM自助建立報表，臨時性復(fù)雜(語法在3個join以上或使用非常用表)的報表由前臺數(shù)據(jù)人員建立報表支持，長期的復(fù)雜性的報表由bi部門建立報表并維護。前臺數(shù)據(jù)是及時性支持，重時效輕維護，當數(shù)據(jù)穩(wěn)定后，相關(guān)數(shù)據(jù)可下線或并入bi的基礎(chǔ)報表中;bi部門是，常規(guī)系統(tǒng)的報表由bi設(shè)計并維護。
定位問題
定位問題也是不斷試錯的過程，需要在了解業(yè)務(wù)場景的情況下，不斷提出假設(shè)、用數(shù)據(jù)驗證、再提出假設(shè)的過程，直至整個項目符合預(yù)期目標。
提出假設(shè)是最考驗數(shù)據(jù)人功力的一環(huán)，結(jié)合業(yè)務(wù)場景去思考問題點，然后挑出最有可能的幾種來分別驗證。對業(yè)務(wù)最能直接產(chǎn)生價值的是定位問題，數(shù)據(jù)有效和及時都只能說是基本功，而快速精準定位問題，并能用數(shù)據(jù)說服其他人這就是問題所在并能提出方案，這是綜合能力的直接體現(xiàn)。因為這包含對數(shù)據(jù)的理解，對業(yè)務(wù)場景的理解，對人心的把握，當然如果對初級人員每次都是窮舉法所有的可能性的點，勤能補拙，不斷總結(jié)，會找到自己的分析style。
比如之前的嬰童流程改造項目，首頁點擊嬰童的icon之后，進入嬰童的新流程。新流程上線后，整體嬰童訂單量占比上升同時新流程的轉(zhuǎn)化率低于舊版轉(zhuǎn)化率，但在整體嬰童訂單中從新流程下單的比例較低，于是決定把首頁嬰童icon的大小和顏色更加醒目，讓目標人群注意到新流程，上線后嬰童訂單量進一步上升。在持續(xù)改進的過程中發(fā)現(xiàn)用于在填寫頁之后的轉(zhuǎn)化率明顯較低，經(jīng)過定位發(fā)現(xiàn)用戶在填寫頁回退上操作異常，單頁面上所有點擊數(shù)據(jù)波動不明顯。這時候我們面對的問題是用戶在填寫頁這附近遇到困惑，但現(xiàn)有數(shù)據(jù)無法定位出用戶的困惑，于是申請資源請用戶研究部門進行電話回訪，發(fā)現(xiàn)很多有價值的信息，比如價格問題排序問題等，針對性改進后轉(zhuǎn)化率有明顯提升。
結(jié)尾
將這些經(jīng)驗分享出來有兩個目的，一個是2016年事兒上練心的記錄，一個是給大家展示可以達到的效果及方法，如果你覺得有效，可以自己嘗試，自助者天助。
如果有覺得頻率相同的人，可以一起加微信，倒不是找同聊，而是建立朋友圈(和而不同)。
【本文為專欄作者“李寧”的原創(chuàng)稿件，轉(zhuǎn)載請通過聯(lián)系作者獲取授權(quán)】
當前題目：給30個PM拉了一年的sql，我學(xué)到了這些
文章起源：http://m.fisionsoft.com.cn/article/dpjsiid.html
