數據中臺實戰（二）：基於阿里OneData的數據指標管理體系

本文將經過具體案例來介紹OneData的實施流程，繼而介紹阿里OneData數據體系中數據指標的管理和數據模型的設計，最後再爲你們講數據看板的設計。

上一篇文章講了《數據中臺實戰（一）：以B2B點電商爲例談談產品經理下的數據埋點》，本文咱們先以一個例子實戰介紹OneData實施流程。接着再講阿里OneData數據體系中數據指標的管理、數據模型的設計。最後講一下數據產品中，數據看板的設計。全是實戰乾貨，看完本文你就會知道數據中臺最核心的內容。

阿里OneData實施過程實戰

好比當時咱們運營提了一個比較有指導意義的數據指標叫爆款率，咱們以爆款率爲例先說一下OneData每一個步驟實施的流程和涉及的角色。

第一步：要肯定指標的業務口徑

業務口徑應該由數據中臺的產品經理主導，找到提出該指標的運營負責人溝通。首先要問清楚指標是怎麼定義的，好比運營說爆款率的定義分子是是專場中商品銷售件數超過20件的商品數，分母是專場內的總商品數（專場如上圖所示，商品會放在運營人員組的一個一個專場裏面）。

這裏面有幾個坑：

1. 這個20件多是運營拍腦殼定義的數據，這時要協調咱們的數據數據分析師看下歷史專場銷售件數的分佈找出最合理的值，而後和運營基於數據再一塊兒定義最終的閾值。若是歷史數據專場銷售件數大部分都遠遠超過20件那麼這個指標就全部的專場都是爆款專場，就沒什麼意義了。

2. 商品的銷售件數超過20件，其中有一個十分有爭議的字眼那就是銷售，怎麼定義銷售？是下單就算，仍是支付纔算？考慮不考慮退款？若是考慮退款是發起退款就算仍是退款實際發生後再算？實際上是有不少問題要考慮的。最終和運營肯定爲該專場支付後的商品件數除以專場商品的總件數。

3. 銷售的商品件數是按商品銷售的件數仍是按照商品下SKU的銷售件數，這個是要搞清楚的，可能運營不關心這個事，可是影響到模型的設計。

處理完這些坑後關於指標的定義還須要問這幾個問題。咱們統計的維度是什麼？好比爆款率的計算維度是專場內商品的維度，一個是要專場內，一個是商品，原子指標就是銷售款數。還有就是統計週期，通常統計週期分爲按小時、按天（當天）、按業務周（運營本身定義的統計週期）、按天然週週、按天然月月、按年，還有就是截止到昨天也是比較經常使用。爆款率的統計週期是統計專場開始到結束時間內的銷售件數。

接下來要問清楚這個指標有什麼用，給誰用。

不是全部的指標都有開發的意義，由於後面你會發現咱們數據中臺前期每作一個指標都會花費大量的人力資源，因此必定要考慮這個指標的性價比，咱們投入這麼多資源，可以給公司帶來什麼，要麼直接和交易額相關，要麼就是能節省運營同事大量的工做時間，節省人力成本也是爲公司省錢嘛。

好比咱們的爆款率是給商品負責人看的，專場的商品是由商品運營人員組的，爆款率就決定這個運營人員的組貨能力，組貨能力強的商品運營必定是可以給公司帶來更多的交易額。這樣公司就應該多投入資源給那些爆款率比較高的那些運營人員。這樣就很清楚了，咱們的爆款率是給運營負責人和商品運營看的。

另外咱們的商品運營會長時間在市場選貨，那咱們團隊決定把這個指標作成移動端可看，而且商品運營人員能夠實時查看爆款率這個指標。

第二步：要肯定指標的技術口徑

技術口徑是由建模工程師主導，此時數據中臺產品經理要和模型設計師溝通整個指標的業務邏輯，另外就是要協調業務方的技術開發人員和咱們的建模工程師一塊兒梳理數據庫層面須要用到表結構和字段。

必定要精確到字段級別，好比咱們的爆款率涉及到專場表、商品表、訂單表、涉及的字段有商品的銷售款數（須要關聯專場和商品表）、專場的總商品件數等字段。

這些字段都肯定好後，就能初步定下來這個指標能不能統計，若是不能統計這時產品經理應該主動協調運營告知，而且還要告訴運營同事作了哪些功能才能統計這些指標，接下來就是協調業務方產品經理討論是否是要作這些功能。

第三步：原型設計和評審

此時由數據中臺產品經理主導設計原型，對於爆款率來講咱們要一方面要展現他們的實時銷售件數，另一方面要實時展現爆款率的變化趨勢，加上專場的轉化率（支付人數/UV）就能夠綜合判斷這個專場的質量，當運營人員發現轉化率和爆款率比較低時再結合商品的數據及時把一些表現比較差勁的商品下架，讓銷量好的商品獲得更多的曝光機會。

原型的評審分爲內部評審和外部評審。

內部評審要拉上咱們的架構師、建模工程師、數據開發工程師、後端開發工程師、前端開發工程師、UI，一塊兒說明整個功能的價值和詳細的操做流程，確保你們理解的一致。接下來就要和咱們的運營根據原型最終肯定問題。比較重要的功能要發郵件讓咱們的運營進一步確認，並同步給全部的運營同事保證你們的口徑一致。

第四步：模型設計

此時主導的是咱們的模型設計工程師，按照阿里的OneData建模理論的指導，模型設計工程師會採用三層建模的方式把數據更加科學的組織存儲。分爲 ODS（操做數據層），DWD(明細數據層)、DWS（彙總數據層）、ADS （應用數據層），這是業務對數據分層經常使用的模型。模型設計工程師要清楚的知道數據來源自那裏，要怎麼存放。

關於數據建模下一篇文章會更加詳細的介紹，在此就再也不多說。

第五步：數據開發

此時主導的是大數據開發工程師，首先要和數據建模工程師溝通好技術口徑明確好咱們計算的指標都來自於那些業務系統，他們經過數據同步的工具如DataX、消息中間TimeTunnel將數據同步到模型工程師設計的ODS層，而後就是一層一層的經過SQL計算到DW*層，一層一層的彙總，最後造成可爲應用直接服務的數據填充到ADS層。

另外大數據開發工程另一個比較重要的工做就是設置調度任務，簡單來說就是何時計算提早寫好的計算腳本如T-1天天凌晨處理上一天的數據，隨着業務的增加，運營會對實時數據的需求愈來愈大，還有一些實時計算任務的配置也是由大數據開發工程師完成。

第六步：後端開發

此時由後端開發主導，後端開發工程師基於產品經理的功能定義輸出相應的接口給前端開發工程師調用，因爲ADS層是由數據開發工程師已經將數據注入常規的關係型數據庫（如MYSQL等），此時後端開發工程師更多的是和產品經理溝通產品的功能、性能方面的問題，以便給使用者更好的用戶體驗。

第七步：前端開發

此時主導的是前端開發工程師。原型出來後產品經理會讓UI設計師基於產品功能的重點設計UI，UI設計師通過反覆的設計，UI最終定型後，會給咱們的前端開發工程師提供切圖。前端開發工程師基於UI的切圖作前端頁面的開發。

第八步：聯調

此時數據開發工程師、前端開發工程師、後端開發工程師都要參與進來。此時會要求大數據開發工程師基於歷史的數據執行計算任務，數據開發工程師承擔數據準確性的校驗。先後端解決用戶操做的相關BUG保證不出現低級的問題完成自測。

第九步：測試

測試工程師在完成原型評審後就要開始寫測試用例，那些是開發人員本身要自測經過才能交上來測試的，那些是本身要再次驗證的都在測試用例寫清楚。此時有經驗的產品經理會向運營人員要歷史的統計數據來覈對數據，不過運營人員的數據不必定準確，只是拿來參考。最終測試沒問題產品經理協調運營人員試用，試用中發現的一些問題再回爐從新修改，此時整個研發過程就結束了。

第十步：上線

運維工程師會配合咱們的先後端開發工程師更新最新的版本到服務器。此時產品經理要找到該指標的負責人長期跟進指標的準確性。重要的指標還要每過一個週期內部再次驗證，從而保證數據的準確性。

經歷了以上步驟數據中臺的一個指標終於開發完成，能夠看得出一個小小的指標須要調動8個角色在一塊兒溝通、確認很久才能完成上線。因此產品經理必定要把握好指標的價值，把有限的資源花費到最有價值的指標上去。下面介紹一下完成這些步驟最核心的數據指標的定義與數據模型的創建。

基於阿里OneData的數據指標管理體系

數據指標的定義

咱們在梳理公司的數據指標時發現每一個部門對同一個指標定義的不一致，就比如交易額這個指標在電商產品中就是一個模糊的指標，是下單金額、仍是支付金額（無包含優惠）、或者有效金額（剔除退款），這樣沒有一個統一的標準，就很難對部門間作橫向的對比。

甚至部門間對同一個指標的口徑也存在不同的狀況，更不用說整個指標的開發要涉及運營同事、產品同事、技術同事等，只要一個環節出問題，指標計算就會不許確。咱們也是採用阿里的一套針對指標的規範定義，讓你們在一個標準下看數據消除歧義。

其中的名詞定義咱們簡單過一下：

數據域：面向業務的大模塊，不會常常變。好比咱們公司有環貿快版打版服務、億訂電商業務、供應鏈業務等等大的業務模塊相似產品線。

業務過程：如電商業務中的下單、支付、退款等都屬於業務過程。

時間週期：就是統計範圍，如近30天、天然周、截止到當天等。

修飾類型：比較好理解的如電商中支付方式，終端類型等。

修飾詞：除了維度意外的限定詞，如電商支付中的微信支付、支付寶支付、網銀支付等。終端類型爲安卓、IOS等

原子指標：不可再拆分的指標如支付金額、支付件數等指標

維度：常見的維度有地理維度（國家、地區等）、時間維度（年、月、周、日等）

維度屬性：如地理維度中的國家名稱、ID、省份名稱等。

派生指標：原子指標+修飾詞+時間週期就組成了一個派生指標。

阿里就是用這一套嚴格的指標拆分體系來管理每一個指標。之因此拆這麼完全，就是要消除歧義。條件容許的話能夠協調開發同事、測試同事、產品同事口述一下對這個指標的理解看看有什麼不一樣。最大程度的消除指標的歧義。

關於數據指標還有two more thing要談：

1. 怎麼分出指標的重要性。當你不是從0到1跟一個產品，那麼此時你可能沒大家的運營懂產品的各項數據，當你問大家運營問那些指標是比較重要的，由於他們所處的崗位不一樣，看事情的角度不一樣，最後你會發現獲得一個結果：一大堆的指標，都重要。此時有個技巧，你能夠問人事或者他們的部門負責人要一下部門的績效考覈指標，也許這些就是他們最重要的指標。另外這些指標你能夠和部門的負責人溝通，那些是他比較關注的指標，那就應該從這些指標作起。

2. 關於虛榮指標。產品經理須要識別那些是虛榮指標，那些是更有用的指標。好比常見的PV、UV、月活、總用戶數、總商品數等等都是虛榮指標，由於他沒法直接促進交易額的增加。uv、月活再多有什麼用，用戶就是不購買。 好比電商行業的主路徑的專戶率，訪問-商品列表、商品列表-商品詳情、商品詳情-加購、加購-下單轉化率這些都是下降流失就能提升交易額的。還有用戶的第二天留存、7日留存率（新用戶7往後是否再次訪問）、30日留存率等能直接反應用戶的質量和運營作的好壞。商品的動銷率（銷售款數/上架款數），能直接反映這批商品的好壞。總結一下通常能直接促進交易額、相似轉換率這種帶分子、分母的指標都是非虛榮指標。

基於阿里OneData的模型設計體系

首先你要知道這些概念。什麼是數據倉庫、數據倉庫和數據庫的區別、數據倉庫的分層、數據模型的定義。

什麼是數據倉庫

我用個比喻解釋這個概念。

馬雲：作個報告，我要知道開年到如今還沒進入工做狀態的有哪些人。

我：好的。

我開始收集：上/下班打卡數據、門口探頭統計上廁所頻率的數據、手機wifi上網數據、微信羣活躍數據、發出零食聲音最恐怖的工位數據、有事沒事熬電話粥的數據…一週以後，分析報告上咱們部門主管的名字佔據第一，他讓我加了一週的班……

我收集的這些數據我須要把它放在一個地方，我暫且把它放在一個叫「新年好」的文件夾，這些來自不一樣地方的數據，我須要作維度統一處理、字段命名規範處理、去噪處理（比喻年齡爲100這種數據）等等。這是作一份報告，若是作一個平臺或者一個項目呢？

好比支付寶的年度帳單；網易雲音樂的年度報告；那區區一個新年好就應付不過來了，因此，須要一個儲藏這些數據的數據庫來替代上面的「新年好」，這個用來儲存按照咱們須要的、對咱們有用的、已經清洗過、很規範的東西就是咱們的數據倉庫。

數據倉庫與數據庫的區別

數據庫與數據倉庫都用來儲存數據，在本質上其實做用是相同的，當從業務出發，二者的區別就很大了。

​數據倉庫是層級分明的

既然要作數據處理，咱們數據先後確定有變化，那麼爲了保險，咱們須要將各個維度的數據分層儲存，好比一個訂單數據，讓我羅列我能夠整出2、三十個字段，但是最後咱們真正用到的只有：uid、time和goods id，這個過程須要不斷的過濾。每過濾一層就須要在新的一層儲存一次。業務是分層的參考標準，不一樣的業務，分層不同，好比阿里的數據分層分爲：ODS、DWD、DWS、ADS。

ODS(操做數據層)：是數據倉庫第一層數據，直接從原始數據過來的，通過簡單地處理，爆款率涉及到的表結構好比訂單表、專場表、商品表、用戶表等。

DW*（彙總數據層）：這個是數據倉庫的第二層數據，DWD和DWS不少狀況下是並列存在的，這一層儲存通過處理後的標準數據。增長了維度造成了統計寬表，好比專場的爆款商品有哪些。

ADS（應用數據層）：這個是數據倉庫的最後一層數據，爲應用層數據，直接能夠給業務人員使用。好比某日某個專場爆款率是多少、總的爆款率是什麼。

看到這裏，你也許會問，爲何要分層？

在這篇文章裏，過多解釋這個緣由，沒有意義，這個階段，你就記住，分層是爲了更清晰的掌控、管理數據。瞭解了數據倉庫的基本概念，咱們就得實戰啦，如基本的數據模型。

數據模型有不少，如：範式模型、維度模型、Data Vault 等等。感興趣的能夠自行查閱資料，今天咱們重點講一下維度模型中的「星型模型」。

星型模型的基本概念

星型模型中有兩個重要的概念：事實表和維度表。

事實表：一些主鍵ID的集合，沒有存聽任何實際的內容。

上圖是我本身畫的一個星型模型表結構（僅輔助說明），如上圖中的「報告表」就是一張事實表，這個報告表會隨着用戶的購買行爲不斷的優化和更新，每一個ID對應維度表中一條記錄。

維度表：存放詳細的數據信息，有惟一的主鍵ID。如上面的商品表、用戶表等等。

星型模型適用的業務場景：

• 電商網站：某寶、狗東等分析用戶的買買買行爲。
• 新聞網站：虎嗅*、36kr*、推酷*等分析用戶的閱讀行爲。
• 寫做網站：知乎*、簡書等用戶的創做回顧分析。
• ……

星型模型的特色：

• 數據冗餘小（由於不少具體的信息都存在相應的維度表中了，好比用戶信息就只有一份）
• 結構清晰（表結構一目瞭然）
• 便於作OLAP分析（數據分析用起來會很開心）
• 增長使用成本，好比查詢時要關聯多張表

數據看板的設計

到如今爲止指標已經定義好了，也採用三層建模的形式存儲了下來。在這裏就跳過數據開發這塊，太過於偏技術化。指標計算好後最重要的就是指標的展現了，此時有個坑，你會發現每一個人關注的數據不太同樣，老闆關注的和部門領導關注的是有差異的、部門領導關注的和一線的執行人員關注的仍是有差異的，咱們作了不少看板仍是沒法知足住全公司每一個用戶的數據看板需求。

最後決定採用自定義看板的方案，咱們數據中臺提供的是看板庫，全部的指標已經在數據中臺分門別類的定義好，計算好。

若是遇到新的數據指標，如今的看板庫沒法知足，數據中臺會進行新一輪的開發，開發完成後將指標計算的結果放到看板庫中。看數據的同事能夠經過查看、搜素本身想要的指標，經過拖拉拽的方式造成本身的個性化看板，並能經過微信、小程序造成本身的每日看板報告。

這樣老闆想看的指標數據中臺本身定製頁面，定製看板的權限交給每一個同事，不過要注意權限的設定，有些同事是不能看到特別關鍵的指標。

看數據人員選擇本身想要的指標經過拖拉的方式定製本身的看板，能夠選擇顯示方式如折線圖、餅圖、柱狀圖等常規圖表，也能夠選擇統計週期等屬性。

在此放一張配置後的數據看板DEMO， 左側的看板都是看數據的同事自行配置的。

定製完看板後能夠對接微信、內部的小程序、APP等。進行數據指標的個性化推送。

接來下會講數據中臺產品設計、用戶畫像、個性化推薦模塊。