本文將通過具體案例來介紹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日留存率等能直接反應用戶的質量和運營做的好壞。商品的動銷率（銷售款數/上架款數），能直接反映這批商品的好壞?？偨Y一下一般能直接促進交易額、類似轉換率這種帶分子、分母的指標都是非虛榮指標。

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

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

什么是數據倉庫

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

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

我：好的。

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

我收集的這些數據我需要把它放在一個地方，我暫且把它放在一個叫“新年好”的文件夾，這些來自不同地方的數據，我需要做維度統一處理、字段命名規范處理、去噪處理（比喻年齡為100這種數據）等等。這是做一份報告，如果做一個平臺或者一個項目呢？

比如支付寶的年度賬單；網易云音樂的年度報告；那區區一個新年好就應付不過來了，所以，需要一個儲藏這些數據的數據庫來替代上面的“新年好”，這個用來儲存按照我們需要的、對我們有用的、已經清洗過、很規范的東西就是我們的數據倉庫。

數據倉庫與數據庫的區別

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

?數據倉庫是層級分明的

既然要做數據處理，我們數據前后肯定有變化，那么為了保險，我們需要將各個維度的數據分層儲存，比如一個訂單數據，讓我羅列我可以整出二、三十個字段，可是最后我們真正用到的只有：uid、time和goods id，這個過程需要不斷的過濾。每過濾一層就需要在新的一層儲存一次。業務是分層的參考標準，不同的業務，分層不一樣，比如阿里的數據分層分為：ODS、DWD、DWS、ADS。

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

DW*（匯總數據層）：這個是數據倉庫的第二層數據，DWD和DWS很多情況下是并列存在的，這一層儲存經過處理后的標準數據。增加了維度形成了統計寬表，比如專場的爆款商品有哪些。

ADS（應用數據層）：這個是數據倉庫的最后一層數據，為應用層數據，直接可以給業務人員使用。比如某日某個專場爆款率是多少、總的爆款率是什么。

看到這里，你也許會問，為什么要分層？

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

數據模型有很多，如：范式模型、維度模型、Data Vault 等等。感興趣的可以自行查閱資料，今天我們重點講一下維度模型中的“星型模型”。

星型模型的基本概念

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

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

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

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

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

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

星型模型的特點：

• 數據冗余?。ㄒ驗楹芏嗑唧w的信息都存在相應的維度表中了，比如用戶信息就只有一份）
• 結構清晰（表結構一目了然）
• 便于做OLAP分析（數據分析用起來會很開心）
• 增加使用成本，比如查詢時要關聯多張表

數據看板的設計

到現在為止指標已經定義好了，也采用三層建模的形式存儲了下來。在這里就跳過數據開發這塊，太過于偏技術化。指標計算好后最重要的就是指標的展示了，此時有個坑，你會發現每個人關注的數據不太一樣，老板關注的和部門領導關注的是有差別的、部門領導關注的和一線的執行人員關注的還是有差別的，我們做了很多看板還是無法滿足住全公司每個用戶的數據看板需求。

最后決定采用自定義看板的方案，我們數據中臺提供的是看板庫，所有的指標已經在數據中臺分門別類的定義好，計算好。

如果遇到新的數據指標，現在的看板庫無法滿足，數據中臺會進行新一輪的開發，開發完成后將指標計算的結果放到看板庫中?？磾祿耐驴梢酝ㄟ^查看、搜素自己想要的指標，通過拖拉拽的方式形成自己的個性化看板，并能通過微信、小程序形成自己的每日看板報告。

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

看數據人員選擇自己想要的指標通過拖拉的方式定制自己的看板，可以選擇顯示方式如折線圖、餅圖、柱狀圖等常規圖表，也可以選擇統計周期等屬性。

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

定制完看板后可以對接微信、內部的小程序、APP等。進行數據指標的個性化推送。

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

相關閱讀：

《數據中臺實戰（一）：以B2B點電商為例談談產品經理下的數據埋點》

作者：Wilton（董超華），曾任職科大訊飛，現任富力環球商品貿易港大數據產品經理。微信公眾號：改變世界的產品經理。簡單、簡短、有用，堅持原創、堅持做感動你的好文章。

本文由@華仔 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。