有效數(shù)據(jù)治理的6大原則

北極星
3 評論 11124 瀏覽 25 收藏 12 分鐘
🔗 产品经理专业技能指的是:需求分析、数据分析、竞品分析、商业分析、行业分析、产品设计、版本管理、用户调研等。

如果你常常對數(shù)據(jù)準(zhǔn)確性而煩惱,大部分時間都用于處理數(shù)據(jù)而不是對業(yè)務(wù)進(jìn)行思考分析的話,那么你需要好好對數(shù)據(jù)進(jìn)行治理了。

一、為什么要進(jìn)行數(shù)據(jù)治理

不知道你是否有這樣的感受,看到數(shù)據(jù)后,一臉懵逼,不知道各個表和字段代表什么意思,再看看別的同事寫的SQL,一條SQL語句有幾百行,各種表關(guān)聯(lián),然后問了其中一個同事,他說“別提了,數(shù)據(jù)都不準(zhǔn),我快被數(shù)據(jù)折磨死了!”,此時你是不是“想死”!欲哭無淚……

究其背后的原因,是因為負(fù)責(zé)的人只是問題使然,哪有問題哪里去補(bǔ),沒有整體的統(tǒng)籌規(guī)劃,一步錯,步步錯,數(shù)據(jù)最后是越來越重,查詢越來越復(fù)雜,數(shù)據(jù)準(zhǔn)確性還沒有人敢打保票,同時修復(fù)的難度也大大增加。

二、如何進(jìn)行數(shù)據(jù)治理

如果要想將數(shù)據(jù)治理好的話,需要遵循以下六大原則、合理制定數(shù)據(jù)中間表模型以及埋點(diǎn)采集到應(yīng)用全流程的把控。

1. 六大原則

原則1:關(guān)鍵概念多方共識

關(guān)鍵概念若涉及多方,比如成交客戶的定義,要確保公司內(nèi)部和客戶相關(guān)的所有業(yè)務(wù)人員理解一致。

你或許會說,成交客戶還不好理解么,就是購買了我公司產(chǎn)品且簽署合同的用戶就是一個成交客戶,但是實際情況遠(yuǎn)非如此,筆者當(dāng)時處理該塊的業(yè)務(wù)時,問不同的業(yè)務(wù)人員得到的結(jié)果都不一樣,這樣就造成了數(shù)據(jù)指標(biāo)統(tǒng)計的歧義甚至數(shù)據(jù)的不準(zhǔn)確。

  1. 當(dāng)一個合同主體變換名稱(含工商注冊名稱變更、更換簽約公司等),那么這個客戶算一個成交客戶嗎?
  2. 同一個 集團(tuán)/公司 下,不同的 子公司/業(yè)務(wù)線/部門 用同一個名字簽署多個不同合同,屬于單個成交客戶還是多個成交客戶?
  3. 當(dāng)合同還在「待確認(rèn)」或未拿到合同編號時,如果客戶運(yùn)營人員已經(jīng)開始服務(wù)客戶,那么這個客戶算一個成交客戶嗎?……

原則2:某個類型的值經(jīng)常發(fā)生變動,則需要冗余一個通用字段冗余值

筆者是深受其害,以前每個月底都需要找開發(fā)、業(yè)務(wù)人員對一遍數(shù)據(jù),舉個例子:

查詢原始指標(biāo):soure_type為A,B的任務(wù)產(chǎn)出的金幣數(shù)額為消費(fèi)指標(biāo),SQL已針對該指標(biāo)做了類型篩選。某一天業(yè)務(wù)運(yùn)營人 員上線新的任務(wù),C類型的任務(wù)會貢獻(xiàn)金幣流水,但是開發(fā)未告知數(shù)據(jù)人員,導(dǎo)致原來的關(guān)鍵指標(biāo)數(shù)值出現(xiàn)差錯。

處理過數(shù)據(jù)的同學(xué)都知道,某個指標(biāo)的實現(xiàn)可能和其它幾個關(guān)鍵指標(biāo)相關(guān),那么該指標(biāo)的異常排查就需要逐個檢查是哪個相關(guān)指標(biāo)出問題了,查找到原因可能2,3天的時間就沒了,但如果事先開發(fā)人員冗余了一個通用字段代表該類消費(fèi)指標(biāo),那么后續(xù)不管業(yè)務(wù)人員上線多少個消費(fèi)類型的任務(wù),都不會對原來的指標(biāo)產(chǎn)生影響。

原則3:每個實體都有唯一、不變的ID,最好沒有實際意義

一是為了實體的唯一性,二是為了表關(guān)聯(lián)或更新時不受業(yè)務(wù)的影響。

原則4:涉及協(xié)作的數(shù)據(jù),發(fā)現(xiàn)問題要從修改源頭做起,保證下一次拿到正確的數(shù)據(jù)

協(xié)作的數(shù)據(jù)可以說是一個串聯(lián)的過程,源頭的數(shù)據(jù)會逐層影響下層的數(shù)據(jù),不要為了一時方便,只修改目前發(fā)現(xiàn)問題的地方,要從修改源頭做起,方便他人即方便自己。

原則5:編寫操作清單,操作前請三思

數(shù)據(jù)間存在關(guān)聯(lián),把數(shù)據(jù)間的關(guān)聯(lián)關(guān)系陳列清楚、注意事項標(biāo)注清楚,操作前一一核對,小數(shù)據(jù)量驗證無錯后,大數(shù)據(jù)量執(zhí)行。

原則6:系統(tǒng)工程的方法管理數(shù)據(jù),盡可能使用系統(tǒng),監(jiān)控數(shù)據(jù)錯誤并及時修復(fù)。

將使用數(shù)據(jù)的相關(guān)方都畫在一張系統(tǒng)循環(huán)圖中,觀察數(shù)據(jù)錯誤產(chǎn)生于系統(tǒng)哪個環(huán)節(jié),如何影響后續(xù)各個環(huán)節(jié),避免惡性循環(huán)的產(chǎn)生。

2. 合理制定數(shù)據(jù)中間表模型

一款產(chǎn)品的存在是為了解決某類用戶群體的需求痛點(diǎn),并在此基礎(chǔ)上進(jìn)行盈利;數(shù)據(jù)分析的存在也是為了輔助挖掘和發(fā)現(xiàn)潛在用戶需求并進(jìn)行優(yōu)化和運(yùn)營。

而數(shù)據(jù)的準(zhǔn)確性和數(shù)據(jù)查取的效率依賴于底層的數(shù)據(jù)采集和中間層的數(shù)據(jù)中間表的構(gòu)建。

關(guān)于底層的數(shù)據(jù)采集方法詳見:產(chǎn)品經(jīng)理給開發(fā)提埋點(diǎn)需求的正確姿勢

用戶的需求隱藏在用戶行為中,從聚合用戶行為的角度構(gòu)建數(shù)據(jù)中間表方便數(shù)據(jù)查詢和分析。

用戶行為分析模型

以用戶觀看短視頻這個用戶行為來說

  • WHO:即觀看視頻的人是誰,可以唯一標(biāo)識用戶身份,如設(shè)備ID,注冊后的用戶ID。如果和第三方合作的話,可以對一個用戶生成一個唯一標(biāo)識ID,用戶串聯(lián)設(shè)備ID和注冊后的用戶ID。
  • WHEN:觀看視頻發(fā)生的實際時間,一般會記錄客戶端時間和服務(wù)端時間。
  • WHAT:即用戶觀看視頻這個行為。
  • HOW:記錄用戶觀看視頻的方式,如所在頻道、觀看時長、視頻類型等等
  • WHERE:記錄用戶在哪個省份、城市、IP下觀看視頻的,同時還會記錄網(wǎng)絡(luò)類型、應(yīng)用版本、操作系統(tǒng)等其它環(huán)境信息。

構(gòu)建包含完整用戶行為的數(shù)據(jù)中間表

構(gòu)建好的業(yè)務(wù)指標(biāo)體系的高效計算和快速有條理展現(xiàn)依賴于數(shù)據(jù)倉庫中間表的建設(shè),若中間表設(shè)計不合理,就會導(dǎo)致滿足基本業(yè)務(wù)分析需求時一步不能計算出來且邏輯關(guān)聯(lián)多導(dǎo)致實時計算等待時間過長,這樣就增加了數(shù)據(jù)分析的等待成本以及業(yè)務(wù)人員查詢的成本。

所以一張數(shù)據(jù)中間表應(yīng)該包含用戶完整的行為信息和動態(tài)屬性信息,而要描述用戶的完整行為就需要按照用戶行為模型記錄上述信息,但實際情況是,我們所記錄的表數(shù)據(jù)是分割的。

比如,觀看視頻這個表一般只會記錄和視頻相關(guān)的信息,用戶的How、WHERE信息會分部在其它表中,這樣就增加了表關(guān)聯(lián)的復(fù)雜度,邏輯復(fù)雜不利于分析,所以我們需要構(gòu)建一個用戶行為中間表,里面包含了上述5個方面的詳細(xì)信息。

同時通過事件名稱冗余某一類的埋點(diǎn)行為數(shù)據(jù),如可將金融相關(guān)的埋點(diǎn),作為值傳給事件名稱,這樣查和金融相關(guān)的埋點(diǎn)數(shù)據(jù)時只查這一張中間表即可。

除了用戶行為類的中間表外,還有一張存儲用戶基本信息的,因為除了和用戶行為相關(guān)的動態(tài)信息外,還有專屬于該用戶的靜態(tài)信息,如年齡、性別、注冊時間、注冊地等。

3. 埋點(diǎn)采集到應(yīng)用全流程框架

數(shù)據(jù)中間表的數(shù)據(jù)底層來源于基礎(chǔ)埋點(diǎn)數(shù)據(jù),基礎(chǔ)埋點(diǎn)數(shù)據(jù)的準(zhǔn)確性是基礎(chǔ)中的基礎(chǔ),而埋點(diǎn)數(shù)據(jù)的采集往往會涉及產(chǎn)品方、數(shù)據(jù)方、業(yè)務(wù)方、技術(shù)方,四方配合不好的話,就會影響數(shù)據(jù)的準(zhǔn)確性,到需要用數(shù)據(jù)時發(fā)現(xiàn)數(shù)據(jù)采集錯誤,只能等待下次發(fā)版修改,效率低下,延誤時機(jī)。

故需要梳理一套埋點(diǎn)流程規(guī)范,以提高整個配合過程的效率、數(shù)據(jù)準(zhǔn)確性、業(yè)務(wù)支持的及時性。

若有數(shù)據(jù)產(chǎn)品角色,第二部分主要由數(shù)據(jù)產(chǎn)品負(fù)責(zé),數(shù)據(jù)分析師要密切配合數(shù)據(jù)產(chǎn)品,因為最終需要分析數(shù)據(jù)的是數(shù)據(jù)分析師。

三、數(shù)據(jù)治理后的數(shù)據(jù)狀態(tài)是怎樣的?

我想,數(shù)據(jù)治理好后,起碼可以省50%的數(shù)據(jù)修改反復(fù)的時間,將更多的精力用在業(yè)務(wù)分析上,同時數(shù)據(jù)是準(zhǔn)確的,可以正確引導(dǎo)業(yè)務(wù)決策。

另外降低了SQL復(fù)雜度,產(chǎn)品運(yùn)營等業(yè)務(wù)人員可以通過簡單的SQL查詢所要看到的指標(biāo)。常用指標(biāo)有:次數(shù)、人數(shù)、人均次數(shù)、總金額等數(shù)值指標(biāo),再結(jié)合數(shù)據(jù)中間表中構(gòu)建的各種維度,就能實現(xiàn)多維交叉分析。

最后舉個SQL實現(xiàn)例子:

select ymd,cc,count(*) ,count(distinct uid) from table_name where ymd between ‘20190701’ and ‘20190712’ and event_type=’clicktask’ group by ymd,cc order by ymd desc;

 

作者:北極星,神策數(shù)據(jù)分析師,知乎專欄:數(shù)據(jù)分析方法與實踐,致力于通過數(shù)據(jù)分析實現(xiàn)產(chǎn)品優(yōu)化和精細(xì)化運(yùn)營。

本文由?@北極星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自 Unsplash ,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 一看截圖配色就知道是作者神策出來的了

    回復(fù)
  2. 讓運(yùn)營或者業(yè)務(wù)區(qū)寫sql查數(shù)據(jù),基本這種情況非常少
    一般都是把關(guān)鍵數(shù)據(jù)指標(biāo)做成可視化圖形界面,然后一些非常規(guī)的數(shù)據(jù)通過給數(shù)據(jù)部門提需求,讓他們手動差,然后反饋。
    還有重要的一點(diǎn)就是前期技術(shù)架構(gòu)搭建的是否合理,這個直接導(dǎo)致后期數(shù)據(jù)統(tǒng)計工作的復(fù)雜程度。

    來自江蘇 回復(fù)
    1. 嗯嗯,數(shù)據(jù)可視化后,剩余的部分需求或臨時需求,業(yè)務(wù)運(yùn)營人員可以通過簡單SQL自助查詢,等排期的話有時候會等好久……另外數(shù)據(jù)可視化的易用性也依賴于底層數(shù)據(jù)中間表的建設(shè)

      回復(fù)
专题
19995人已学习13篇文章
本专题的文章分享了TO G产品的入门指南,包括什么是G端产品、产品的特点...
专题
14691人已学习15篇文章
智能硬件产品经理需要做什么工作内容呢?与互联网产品经理有什么区别呢?本专题为刚入行的智能硬件产品经理分享了入门指南。
专题
12508人已学习15篇文章
互联网医疗是医疗行业与互联网的综合应用,其以互联网及相关技术为载体和支撑,开展线下传统或线上衍生的医疗健康服务。本专题的文章分享了对互联网医疗的分析和见解。
专题
18017人已学习13篇文章
用户等级体系是产品的底层基础之一,也是用户成长激励体系之一。本专题的文章分享了如何搭建用户等级体系。
专题
15658人已学习15篇文章
汽车座舱的智能化,本质上是通过硬件+软件的手段,让汽车座舱具备人类“智能”的能力,使人与车直接协作更加安全高效。本专题的文章分享了智能座舱的产品模块解读。
专题
56959人已学习14篇文章
一次成功的线上活动能让你刷爆朋友圈,拉新活跃留存应有尽有。