本文將通過具體案例來介紹OneData的實(shí)施流程，繼而介紹阿里OneData數(shù)據(jù)體系中數(shù)據(jù)指標(biāo)的管理和數(shù)據(jù)模型的設(shè)計(jì)，最后再為大家講數(shù)據(jù)看板的設(shè)計(jì)。

上一篇文章講了《數(shù)據(jù)中臺(tái)實(shí)戰(zhàn)（一）：以B2B點(diǎn)電商為例談?wù)劗a(chǎn)品經(jīng)理下的數(shù)據(jù)埋點(diǎn)》，本文我們先以一個(gè)例子實(shí)戰(zhàn)介紹OneData實(shí)施流程。接著再講阿里OneData數(shù)據(jù)體系中數(shù)據(jù)指標(biāo)的管理、數(shù)據(jù)模型的設(shè)計(jì)。最后講一下數(shù)據(jù)產(chǎn)品中，數(shù)據(jù)看板的設(shè)計(jì)。全是實(shí)戰(zhàn)干貨，看完本文你就會(huì)知道數(shù)據(jù)中臺(tái)最核心的內(nèi)容。

阿里OneData實(shí)施過程實(shí)戰(zhàn)

比如當(dāng)時(shí)我們運(yùn)營提了一個(gè)比較有指導(dǎo)意義的數(shù)據(jù)指標(biāo)叫爆款率，我們以爆款率為例先說一下OneData每個(gè)步驟實(shí)施的流程和涉及的角色。

第一步：要確定指標(biāo)的業(yè)務(wù)口徑

業(yè)務(wù)口徑應(yīng)該由數(shù)據(jù)中臺(tái)的產(chǎn)品經(jīng)理主導(dǎo)，找到提出該指標(biāo)的運(yùn)營負(fù)責(zé)人溝通。首先要問清楚指標(biāo)是怎么定義的，比如運(yùn)營說爆款率的定義分子是是專場中商品銷售件數(shù)超過20件的商品數(shù)，分母是專場內(nèi)的總商品數(shù)（專場如上圖所示，商品會(huì)放在運(yùn)營人員組的一個(gè)一個(gè)專場里面）。

這里面有幾個(gè)坑：

1. 這個(gè)20件可能是運(yùn)營拍腦袋定義的數(shù)據(jù)，這時(shí)要協(xié)調(diào)我們的數(shù)據(jù)數(shù)據(jù)分析師看下歷史專場銷售件數(shù)的分布找出最合理的值，然后和運(yùn)營基于數(shù)據(jù)再一起定義最終的閾值。如果歷史數(shù)據(jù)專場銷售件數(shù)大部分都遠(yuǎn)遠(yuǎn)超過20件那么這個(gè)指標(biāo)就所有的專場都是爆款專場，就沒什么意義了。

2. 商品的銷售件數(shù)超過20件，其中有一個(gè)十分有爭議的字眼那就是銷售，怎么定義銷售？是下單就算，還是支付才算？考慮不考慮退款？如果考慮退款是發(fā)起退款就算還是退款實(shí)際發(fā)生后再算？其實(shí)是有很多問題要考慮的。最終和運(yùn)營確定為該專場支付后的商品件數(shù)除以專場商品的總件數(shù)。

3. 銷售的商品件數(shù)是按商品銷售的件數(shù)還是按照商品下SKU的銷售件數(shù)，這個(gè)是要搞清楚的，可能運(yùn)營不關(guān)心這個(gè)事，但是影響到模型的設(shè)計(jì)。

處理完這些坑后關(guān)于指標(biāo)的定義還需要問這幾個(gè)問題。我們統(tǒng)計(jì)的維度是什么？比如爆款率的計(jì)算維度是專場內(nèi)商品的維度，一個(gè)是要專場內(nèi)，一個(gè)是商品，原子指標(biāo)就是銷售款數(shù)。還有就是統(tǒng)計(jì)周期，一般統(tǒng)計(jì)周期分為按小時(shí)、按天（當(dāng)天）、按業(yè)務(wù)周（運(yùn)營自己定義的統(tǒng)計(jì)周期）、按自然周周、按自然月月、按年，還有就是截止到昨天也是比較常用。爆款率的統(tǒng)計(jì)周期是統(tǒng)計(jì)專場開始到結(jié)束時(shí)間內(nèi)的銷售件數(shù)。

接下來要問清楚這個(gè)指標(biāo)有什么用，給誰用。

不是所有的指標(biāo)都有開發(fā)的意義，因?yàn)楹竺婺銜?huì)發(fā)現(xiàn)我們數(shù)據(jù)中臺(tái)前期每做一個(gè)指標(biāo)都會(huì)花費(fèi)大量的人力資源，所以一定要考慮這個(gè)指標(biāo)的性價(jià)比，我們投入這么多資源，能夠給公司帶來什么，要么直接和交易額相關(guān)，要么就是能節(jié)省運(yùn)營同事大量的工作時(shí)間，節(jié)省人力成本也是為公司省錢嘛。

比如我們的爆款率是給商品負(fù)責(zé)人看的，專場的商品是由商品運(yùn)營人員組的，爆款率就決定這個(gè)運(yùn)營人員的組貨能力，組貨能力強(qiáng)的商品運(yùn)營一定是能夠給公司帶來更多的交易額。這樣公司就應(yīng)該多投入資源給那些爆款率比較高的那些運(yùn)營人員。這樣就很清楚了，我們的爆款率是給運(yùn)營負(fù)責(zé)人和商品運(yùn)營看的。

另外我們的商品運(yùn)營會(huì)長時(shí)間在市場選貨，那我們團(tuán)隊(duì)決定把這個(gè)指標(biāo)做成移動(dòng)端可看，并且商品運(yùn)營人員可以實(shí)時(shí)查看爆款率這個(gè)指標(biāo)。

第二步：要確定指標(biāo)的技術(shù)口徑

技術(shù)口徑是由建模工程師主導(dǎo)，此時(shí)數(shù)據(jù)中臺(tái)產(chǎn)品經(jīng)理要和模型設(shè)計(jì)師溝通整個(gè)指標(biāo)的業(yè)務(wù)邏輯，另外就是要協(xié)調(diào)業(yè)務(wù)方的技術(shù)開發(fā)人員和我們的建模工程師一起梳理數(shù)據(jù)庫層面需要用到表結(jié)構(gòu)和字段。

一定要精確到字段級(jí)別，比如我們的爆款率涉及到專場表、商品表、訂單表、涉及的字段有商品的銷售款數(shù)（需要關(guān)聯(lián)專場和商品表）、專場的總商品件數(shù)等字段。

這些字段都確定好后，就能初步定下來這個(gè)指標(biāo)能不能統(tǒng)計(jì)，如果不能統(tǒng)計(jì)這時(shí)產(chǎn)品經(jīng)理應(yīng)該主動(dòng)協(xié)調(diào)運(yùn)營告知，并且還要告訴運(yùn)營同事做了哪些功能才能統(tǒng)計(jì)這些指標(biāo)，接下來就是協(xié)調(diào)業(yè)務(wù)方產(chǎn)品經(jīng)理討論是不是要做這些功能。

第三步：原型設(shè)計(jì)和評(píng)審

此時(shí)由數(shù)據(jù)中臺(tái)產(chǎn)品經(jīng)理主導(dǎo)設(shè)計(jì)原型，對(duì)于爆款率來說我們要一方面要展示他們的實(shí)時(shí)銷售件數(shù)，另外一方面要實(shí)時(shí)展示爆款率的變化趨勢，加上專場的轉(zhuǎn)化率（支付人數(shù)/UV）就可以綜合判斷這個(gè)專場的質(zhì)量，當(dāng)運(yùn)營人員發(fā)現(xiàn)轉(zhuǎn)化率和爆款率比較低時(shí)再結(jié)合商品的數(shù)據(jù)及時(shí)把一些表現(xiàn)比較差勁的商品下架，讓銷量好的商品得到更多的曝光機(jī)會(huì)。

原型的評(píng)審分為內(nèi)部評(píng)審和外部評(píng)審。

內(nèi)部評(píng)審要拉上我們的架構(gòu)師、建模工程師、數(shù)據(jù)開發(fā)工程師、后端開發(fā)工程師、前端開發(fā)工程師、UI，一起說明整個(gè)功能的價(jià)值和詳細(xì)的操作流程，確保大家理解的一致。接下來就要和我們的運(yùn)營根據(jù)原型最終確定問題。比較重要的功能要發(fā)郵件讓我們的運(yùn)營進(jìn)一步確認(rèn)，并同步給所有的運(yùn)營同事保證大家的口徑一致。

第四步：模型設(shè)計(jì)

此時(shí)主導(dǎo)的是我們的模型設(shè)計(jì)工程師，按照阿里的OneData建模理論的指導(dǎo)，模型設(shè)計(jì)工程師會(huì)采用三層建模的方式把數(shù)據(jù)更加科學(xué)的組織存儲(chǔ)。分為 ODS（操作數(shù)據(jù)層），DWD(明細(xì)數(shù)據(jù)層)、DWS（匯總數(shù)據(jù)層）、ADS （應(yīng)用數(shù)據(jù)層），這是業(yè)務(wù)對(duì)數(shù)據(jù)分層常用的模型。模型設(shè)計(jì)工程師要清楚的知道數(shù)據(jù)來源自那里，要怎么存放。

關(guān)于數(shù)據(jù)建模下一篇文章會(huì)更加詳細(xì)的介紹，在此就不再多說。

第五步：數(shù)據(jù)開發(fā)

此時(shí)主導(dǎo)的是大數(shù)據(jù)開發(fā)工程師，首先要和數(shù)據(jù)建模工程師溝通好技術(shù)口徑明確好我們計(jì)算的指標(biāo)都來自于那些業(yè)務(wù)系統(tǒng)，他們通過數(shù)據(jù)同步的工具如DataX、消息中間TimeTunnel將數(shù)據(jù)同步到模型工程師設(shè)計(jì)的ODS層，然后就是一層一層的通過SQL計(jì)算到DW*層，一層一層的匯總，最后形成可為應(yīng)用直接服務(wù)的數(shù)據(jù)填充到ADS層。

另外大數(shù)據(jù)開發(fā)工程另外一個(gè)比較重要的工作就是設(shè)置調(diào)度任務(wù)，簡單來講就是什么時(shí)候計(jì)算提前寫好的計(jì)算腳本如T-1每天凌晨處理上一天的數(shù)據(jù)，隨著業(yè)務(wù)的增長，運(yùn)營會(huì)對(duì)實(shí)時(shí)數(shù)據(jù)的需求越來越大，還有一些實(shí)時(shí)計(jì)算任務(wù)的配置也是由大數(shù)據(jù)開發(fā)工程師完成。

第六步：后端開發(fā)

此時(shí)由后端開發(fā)主導(dǎo)，后端開發(fā)工程師基于產(chǎn)品經(jīng)理的功能定義輸出相應(yīng)的接口給前端開發(fā)工程師調(diào)用，由于ADS層是由數(shù)據(jù)開發(fā)工程師已經(jīng)將數(shù)據(jù)注入常規(guī)的關(guān)系型數(shù)據(jù)庫（如MYSQL等），此時(shí)后端開發(fā)工程師更多的是和產(chǎn)品經(jīng)理溝通產(chǎn)品的功能、性能方面的問題，以便給使用者更好的用戶體驗(yàn)。

第七步：前端開發(fā)

此時(shí)主導(dǎo)的是前端開發(fā)工程師。原型出來后產(chǎn)品經(jīng)理會(huì)讓UI設(shè)計(jì)師基于產(chǎn)品功能的重點(diǎn)設(shè)計(jì)UI，UI設(shè)計(jì)師經(jīng)過反復(fù)的設(shè)計(jì)，UI最終定型后，會(huì)給我們的前端開發(fā)工程師提供切圖。前端開發(fā)工程師基于UI的切圖做前端頁面的開發(fā)。

第八步：聯(lián)調(diào)

此時(shí)數(shù)據(jù)開發(fā)工程師、前端開發(fā)工程師、后端開發(fā)工程師都要參與進(jìn)來。此時(shí)會(huì)要求大數(shù)據(jù)開發(fā)工程師基于歷史的數(shù)據(jù)執(zhí)行計(jì)算任務(wù)，數(shù)據(jù)開發(fā)工程師承擔(dān)數(shù)據(jù)準(zhǔn)確性的校驗(yàn)。前后端解決用戶操作的相關(guān)BUG保證不出現(xiàn)低級(jí)的問題完成自測。

第九步：測試

測試工程師在完成原型評(píng)審后就要開始寫測試用例，那些是開發(fā)人員自己要自測通過才能交上來測試的，那些是自己要再次驗(yàn)證的都在測試用例寫清楚。此時(shí)有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理會(huì)向運(yùn)營人員要?dú)v史的統(tǒng)計(jì)數(shù)據(jù)來核對(duì)數(shù)據(jù)，不過運(yùn)營人員的數(shù)據(jù)不一定準(zhǔn)確，只是拿來參考。最終測試沒問題產(chǎn)品經(jīng)理協(xié)調(diào)運(yùn)營人員試用，試用中發(fā)現(xiàn)的一些問題再回爐重新修改，此時(shí)整個(gè)研發(fā)過程就結(jié)束了。

第十步：上線

運(yùn)維工程師會(huì)配合我們的前后端開發(fā)工程師更新最新的版本到服務(wù)器。此時(shí)產(chǎn)品經(jīng)理要找到該指標(biāo)的負(fù)責(zé)人長期跟進(jìn)指標(biāo)的準(zhǔn)確性。重要的指標(biāo)還要每過一個(gè)周期內(nèi)部再次驗(yàn)證，從而保證數(shù)據(jù)的準(zhǔn)確性。

經(jīng)歷了以上步驟數(shù)據(jù)中臺(tái)的一個(gè)指標(biāo)終于開發(fā)完成，可以看得出一個(gè)小小的指標(biāo)需要調(diào)動(dòng)8個(gè)角色在一起溝通、確認(rèn)好久才能完成上線。所以產(chǎn)品經(jīng)理一定要把握好指標(biāo)的價(jià)值，把有限的資源花費(fèi)到最有價(jià)值的指標(biāo)上去。下面介紹一下完成這些步驟最核心的數(shù)據(jù)指標(biāo)的定義與數(shù)據(jù)模型的建立。

基于阿里OneData的數(shù)據(jù)指標(biāo)管理體系

數(shù)據(jù)指標(biāo)的定義

我們?cè)谑崂砉镜臄?shù)據(jù)指標(biāo)時(shí)發(fā)現(xiàn)每個(gè)部門對(duì)同一個(gè)指標(biāo)定義的不一致，就好比交易額這個(gè)指標(biāo)在電商產(chǎn)品中就是一個(gè)模糊的指標(biāo)，是下單金額、還是支付金額（無包含優(yōu)惠）、或者有效金額（剔除退款），這樣沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，就很難對(duì)部門間做橫向的對(duì)比。

甚至部門間對(duì)同一個(gè)指標(biāo)的口徑也存在不一樣的情況，更不用說整個(gè)指標(biāo)的開發(fā)要涉及運(yùn)營同事、產(chǎn)品同事、技術(shù)同事等，只要一個(gè)環(huán)節(jié)出問題，指標(biāo)計(jì)算就會(huì)不準(zhǔn)確。我們也是采用阿里的一套針對(duì)指標(biāo)的規(guī)范定義，讓大家在一個(gè)標(biāo)準(zhǔn)下看數(shù)據(jù)消除歧義。

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

數(shù)據(jù)域：面向業(yè)務(wù)的大模塊，不會(huì)經(jīng)常變。比如我們公司有環(huán)貿(mào)快版打版服務(wù)、億訂電商業(yè)務(wù)、供應(yīng)鏈業(yè)務(wù)等等大的業(yè)務(wù)模塊類似產(chǎn)品線。

業(yè)務(wù)過程：如電商業(yè)務(wù)中的下單、支付、退款等都屬于業(yè)務(wù)過程。

時(shí)間周期：就是統(tǒng)計(jì)范圍，如近30天、自然周、截止到當(dāng)天等。

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

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

原子指標(biāo)：不可再拆分的指標(biāo)如支付金額、支付件數(shù)等指標(biāo)

維度：常見的維度有地理維度（國家、地區(qū)等）、時(shí)間維度（年、月、周、日等）

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

派生指標(biāo)：原子指標(biāo)+修飾詞+時(shí)間周期就組成了一個(gè)派生指標(biāo)。

阿里就是用這一套嚴(yán)格的指標(biāo)拆分體系來管理每個(gè)指標(biāo)。之所以拆這么徹底，就是要消除歧義。條件允許的話可以協(xié)調(diào)開發(fā)同事、測試同事、產(chǎn)品同事口述一下對(duì)這個(gè)指標(biāo)的理解看看有什么不同。最大程度的消除指標(biāo)的歧義。

關(guān)于數(shù)據(jù)指標(biāo)還有two more thing要談：

1. 怎么分出指標(biāo)的重要性。當(dāng)你不是從0到1跟一個(gè)產(chǎn)品，那么此時(shí)你可能沒你們的運(yùn)營懂產(chǎn)品的各項(xiàng)數(shù)據(jù)，當(dāng)你問你們運(yùn)營問那些指標(biāo)是比較重要的，因?yàn)樗麄兯幍膷徫徊煌?，看事情的角度不同，最后你?huì)發(fā)現(xiàn)得到一個(gè)結(jié)果：一大堆的指標(biāo)，都重要。此時(shí)有個(gè)技巧，你可以問人事或者他們的部門負(fù)責(zé)人要一下部門的績效考核指標(biāo)，也許這些就是他們最重要的指標(biāo)。另外這些指標(biāo)你可以和部門的負(fù)責(zé)人溝通，那些是他比較關(guān)注的指標(biāo)，那就應(yīng)該從這些指標(biāo)做起。

2. 關(guān)于虛榮指標(biāo)。產(chǎn)品經(jīng)理需要識(shí)別那些是虛榮指標(biāo)，那些是更有用的指標(biāo)。比如常見的PV、UV、月活、總用戶數(shù)、總商品數(shù)等等都是虛榮指標(biāo)，因?yàn)樗麩o法直接促進(jìn)交易額的增長。uv、月活再多有什么用，用戶就是不購買。 比如電商行業(yè)的主路徑的專戶率，訪問-商品列表、商品列表-商品詳情、商品詳情-加購、加購-下單轉(zhuǎn)化率這些都是降低流失就能提高交易額的。還有用戶的次日留存、7日留存率（新用戶7日后是否再次訪問）、30日留存率等能直接反應(yīng)用戶的質(zhì)量和運(yùn)營做的好壞。商品的動(dòng)銷率（銷售款數(shù)/上架款數(shù)），能直接反映這批商品的好壞?？偨Y(jié)一下一般能直接促進(jìn)交易額、類似轉(zhuǎn)換率這種帶分子、分母的指標(biāo)都是非虛榮指標(biāo)。

基于阿里OneData的模型設(shè)計(jì)體系

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

什么是數(shù)據(jù)倉庫

我用個(gè)比喻解釋這個(gè)概念。

馬云：做個(gè)報(bào)告，我要知道開年到現(xiàn)在還沒進(jìn)入工作狀態(tài)的有哪些人。

我：好的。

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

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

比如支付寶的年度賬單；網(wǎng)易云音樂的年度報(bào)告；那區(qū)區(qū)一個(gè)新年好就應(yīng)付不過來了，所以，需要一個(gè)儲(chǔ)藏這些數(shù)據(jù)的數(shù)據(jù)庫來替代上面的“新年好”，這個(gè)用來儲(chǔ)存按照我們需要的、對(duì)我們有用的、已經(jīng)清洗過、很規(guī)范的東西就是我們的數(shù)據(jù)倉庫。

數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別

數(shù)據(jù)庫與數(shù)據(jù)倉庫都用來儲(chǔ)存數(shù)據(jù)，在本質(zhì)上其實(shí)作用是相同的，當(dāng)從業(yè)務(wù)出發(fā)，兩者的區(qū)別就很大了。

?數(shù)據(jù)倉庫是層級(jí)分明的

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

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

DW*（匯總數(shù)據(jù)層）：這個(gè)是數(shù)據(jù)倉庫的第二層數(shù)據(jù)，DWD和DWS很多情況下是并列存在的，這一層儲(chǔ)存經(jīng)過處理后的標(biāo)準(zhǔn)數(shù)據(jù)。增加了維度形成了統(tǒng)計(jì)寬表，比如專場的爆款商品有哪些。

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

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

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

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

星型模型的基本概念

星型模型中有兩個(gè)重要的概念：事實(shí)表和維度表。

事實(shí)表：一些主鍵ID的集合，沒有存放任何實(shí)際的內(nèi)容。

上圖是我自己畫的一個(gè)星型模型表結(jié)構(gòu)（僅輔助說明），如上圖中的“報(bào)告表”就是一張事實(shí)表，這個(gè)報(bào)告表會(huì)隨著用戶的購買行為不斷的優(yōu)化和更新，每個(gè)ID對(duì)應(yīng)維度表中一條記錄。

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

星型模型適用的業(yè)務(wù)場景：

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

星型模型的特點(diǎn)：

• 數(shù)據(jù)冗余小（因?yàn)楹芏嗑唧w的信息都存在相應(yīng)的維度表中了，比如用戶信息就只有一份）
• 結(jié)構(gòu)清晰（表結(jié)構(gòu)一目了然）
• 便于做OLAP分析（數(shù)據(jù)分析用起來會(huì)很開心）
• 增加使用成本，比如查詢時(shí)要關(guān)聯(lián)多張表

數(shù)據(jù)看板的設(shè)計(jì)

到現(xiàn)在為止指標(biāo)已經(jīng)定義好了，也采用三層建模的形式存儲(chǔ)了下來。在這里就跳過數(shù)據(jù)開發(fā)這塊，太過于偏技術(shù)化。指標(biāo)計(jì)算好后最重要的就是指標(biāo)的展示了，此時(shí)有個(gè)坑，你會(huì)發(fā)現(xiàn)每個(gè)人關(guān)注的數(shù)據(jù)不太一樣，老板關(guān)注的和部門領(lǐng)導(dǎo)關(guān)注的是有差別的、部門領(lǐng)導(dǎo)關(guān)注的和一線的執(zhí)行人員關(guān)注的還是有差別的，我們做了很多看板還是無法滿足住全公司每個(gè)用戶的數(shù)據(jù)看板需求。

最后決定采用自定義看板的方案，我們數(shù)據(jù)中臺(tái)提供的是看板庫，所有的指標(biāo)已經(jīng)在數(shù)據(jù)中臺(tái)分門別類的定義好，計(jì)算好。

如果遇到新的數(shù)據(jù)指標(biāo)，現(xiàn)在的看板庫無法滿足，數(shù)據(jù)中臺(tái)會(huì)進(jìn)行新一輪的開發(fā)，開發(fā)完成后將指標(biāo)計(jì)算的結(jié)果放到看板庫中?？磾?shù)據(jù)的同事可以通過查看、搜素自己想要的指標(biāo)，通過拖拉拽的方式形成自己的個(gè)性化看板，并能通過微信、小程序形成自己的每日看板報(bào)告。

這樣老板想看的指標(biāo)數(shù)據(jù)中臺(tái)自己定制頁面，定制看板的權(quán)限交給每個(gè)同事，不過要注意權(quán)限的設(shè)定，有些同事是不能看到特別關(guān)鍵的指標(biāo)。

看數(shù)據(jù)人員選擇自己想要的指標(biāo)通過拖拉的方式定制自己的看板，可以選擇顯示方式如折線圖、餅圖、柱狀圖等常規(guī)圖表，也可以選擇統(tǒng)計(jì)周期等屬性。

在此放一張配置后的數(shù)據(jù)看板DEMO， 左側(cè)的看板都是看數(shù)據(jù)的同事自行配置的。

定制完看板后可以對(duì)接微信、內(nèi)部的小程序、APP等。進(jìn)行數(shù)據(jù)指標(biāo)的個(gè)性化推送。

接來下會(huì)講數(shù)據(jù)中臺(tái)產(chǎn)品設(shè)計(jì)、用戶畫像、個(gè)性化推薦模塊。

相關(guān)閱讀：

《數(shù)據(jù)中臺(tái)實(shí)戰(zhàn)（一）：以B2B點(diǎn)電商為例談?wù)劗a(chǎn)品經(jīng)理下的數(shù)據(jù)埋點(diǎn)》

作者：Wilton（董超華），曾任職科大訊飛，現(xiàn)任富力環(huán)球商品貿(mào)易港大數(shù)據(jù)產(chǎn)品經(jīng)理。微信公眾號(hào)：改變世界的產(chǎn)品經(jīng)理。簡單、簡短、有用，堅(jiān)持原創(chuàng)、堅(jiān)持做感動(dòng)你的好文章。

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

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