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