自從阿里提出了「大中臺，小前臺」概念之後，這幾年數據中臺這個概念火了起來，網際網路巨頭們紛紛搭建起了自家的數據中臺，究竟數據中臺有什麼魅力，能讓企業如此重視？本文筆者從數據中臺是什麼、怎麼做數據中臺和為什麼要做數據中臺三個方面對這個問題進行了回答。
一、什麼是數據中臺？
很多人會問，到底什麼是數據中臺？
通俗地講，數據中臺就是一個在數據層面上為企業業務提供幫助、決策的一個工具。
在以前，數據往往只被顯示，不被存儲；慢慢地，人們需要隨時隨地查找數據，存儲數據的概念被普遍認知；再慢慢地，人們漸漸產生了數據思維，發現可以通過觀看數據來制定運營策略；當網際網路時代進入了爆發期，此時產生了大量的數據，人們通過數據挖掘，收集大量的外界數據作為決策的依據。
而如今，網際網路已步入一個較為成熟的時期，大公司紛紛去打造自家的數據中臺，將海量的數據作為自身的資產，並擅於利用數據中臺將數據進行整合、智能分析，以數據驅動決策。
說到數據中臺，又會牽扯到數據倉庫，很多人一看，數據倉庫？不就是資料庫嘛，存儲數據的東西，其實這是不太正確的認識，那這兩者的區別又是什麼呢？
1. 面向的業務場景不同
數據倉庫主要是將收集到的數據進行分析、處理；
而資料庫主要是面向事務的處理；
2. 側重優化數據方式不同
數據倉庫主要集中資源去優化資源的獲取方式，因為業務人員、運營人員對於數據的獲取需求是非常大的，往往每天都有大量的數據會被調用、獲取以及處理；
而資料庫主要集中資源對增、刪、改、查等等方面的功能進行優化，防止過多的數據更新和事務影響資料庫的效率和穩定性；
3. 數據的組織方式不同
數據倉庫往往是以時間來進行組織數據，以電商訂單為例，數據倉庫分別會以「1小時訂單」、「1日的訂單」、「1個月的訂單」組織好數據分析表，方便業務人員獲取分析；
而資料庫則是以索引和實體內容來組織數據，例如「數碼產品訂單」、「生鮮訂單」、「服裝訂單」等等將不同的數據表進行組織；
4. 冗餘性不同
數據倉庫往往是高冗餘的，因為數據倉庫希望藉助更多重複類型的數據去分析整個產品的運營走勢，為下一步的運營決策做依據；
而資料庫往往是低冗餘的，資料庫不希望存儲大量重複類型的數據，從而影響資料庫整體的性能效率；
談到這裡，大概對數據中臺有初步的了解，那接下來看看我們如何去搭建一個最適合自己公司的數據中臺吧。
二、如何搭建最適合自己的數據中臺？
為什麼要說是「最適合」自己的數據中臺呢？
數據中臺無論是功能、邏輯都是非常的複雜，其中涉及到的欄位、維度非常的多，那如何打造最適合自己的數據中臺呢？可以這樣去思考：
1. 先分析需要什麼數據
首先必須根據自身業務出發，去分析到底我們需要什麼數據？下面是例子：
（1）電商業務
電商，離不開訂單、商品、支付等等這些數據，就訂單數而言，就可以拆分這幾個維度進行統計：分/時/日/周/月訂單數、人均訂單數、男性/女性用戶訂單數、服裝/數碼產品訂單數、復購訂單人數、訂單銷售額 、訂單成交率、訂單退換率等等；
如果是商品，又會涉及到商品種類成交數、商品點擊率、商品評價數等等；
如果是支付，則會涉及到支付成功/失敗率，支付次數、支付渠道、支付優惠使用率等等。
（2）直播業務
談到直播業務，核心角色可分為主播和用戶，整個直播平臺就是圍繞著這兩大核心角色進行設計的。
簡單的說，直播就是主播和用戶進行信息交換的一個過程，主播提供內容，用戶消費內容，反饋信息（發送彈幕，贈送禮物等等，當然用戶也可以不做任何操作，但也為主播提供了人氣和觀眾數）；
可以分析整個直播流程就是：主播打開直播間——用戶收到推薦/訂閱提醒/搜索/首頁推薦等等方式進入了直播間——主播與用戶進行信息交換、互動——用戶退出直播間/主播下播——直播流程結束。
那麼從這一簡單的流程中，我們就可以挖掘出許多的數據指標，例如：開播1分鐘/小時觀眾數、消息推送/訂閱/首頁推薦點擊率、搜索次數、彈幕發送次數/率、送禮種類/數量、觀看直播1/5/10…分鐘的用戶數、各種留存率等等，由於數據指標過多，暫先列出以上數據。
（3）出行業務
出行業務，我們也是根據業務流程去分析：用戶提交訂單——司機接單——用戶上車，司機確認，訂單開始——到達目的地，司機確認，用戶下車——用戶支付（自行決定是否評價）——訂單流程結束。
根據流程，我們可以繼續挖掘數據指標，例如：某區域內1小時內訂單發起數、司機一天接單數、平均訂單金額、訂單取消數/率、訂單公裡數、某區域訂單平均響應時間、訂單好評/差評率等等。
因此要分析需要什麼數據，必須切實地從自身業務的流程一步步去拆解出各個指標數據。
2. 如何落地中臺開發
（1）明確需求
當明確自身需要什麼數據後，此時可以與業務、運營人員進行溝通，他們需要什麼樣的數據，需要怎樣組合數據，呈現方式是什麼，是否支持導出數據等等，都需要產品經理與業務方進行詳細地溝通，明確每一個需求，才能算是前期工作準備的良好開頭。
（2）原型設計
當明確需求後，就可以開始進行原型設計了，這裡就涉及到了設計的細節：如何讓數據可視化更清晰？如何讓操作更加簡便，業務人員更容易上手？
因此在設計的過程中，除了跟開發保持溝通，同時還需要跟業務人員保持一定的聯繫，防止原型設計好，業務人員不滿意又要大改。
（3）需求評估，跟進開發進度
當設計好原型和撰寫好需求文檔後，就可以進行需求評估了，這個階段如果出現難以實現的功能，那產品和開發就要共同去想如何換另一種設計方式去解決同樣的問題；
然後還有就是進行需求排期，大概確定每一個時間節點，產品經理時刻跟進開發進度。
（4）開發完成，嚴格測試
可能大家會想，中臺又不是給C端用戶用，測試那麼嚴格沒必要；但正是因為中臺不是給用，而是給業務人員用，如果出現了數據上的嚴重紕漏，影響了運營的決策，那麼帶來的業務影響也是非常嚴重的，因此嚴格的測試必不可缺。
（5）成功上線，時刻跟進問題
測試結束後，終於可以上線了，然而重頭戲才剛剛開始，此時會發現，業務方使用了中臺後向你提出各種各樣之前測試測不出來的bug，此外，還會吐槽功能的各種不好用，甚至給你提另外的需求……
作為中臺產品經理的你，此時可能會感覺壓力非常的大，但只要我們時刻保持跟進，合理安排項目進度，解決需求，我想，業務同學也不會刻意去為難你。
三、為什麼大公司需要自建數據中臺？
據調研發現，其實市面上已經存在不少如「神策數據」、「BDP」、「帆軟」等等的第三方智能數據平臺，企業購買即可使用，那相當於已經有現成的了，為什麼還要大費周章去自己開發呢？
我想，可能是因為這些原因：
1. 數據安全性
對於大公司來說，他們擁有的數據是海量的，海量的數據裡面往往存在著許多商業價值極高的數據，簡稱商業機密，是不能洩露到外界去的，因此自家研發的平臺能夠保障一定的安全性。
2. 數據即資產
數據對於企業來說，就是資產，尤其在大公司，數據就是運營決策的依據，若被競爭對手得知了數據，提前判斷到對方的下一步運營策略，萬一在某一重要節點的活動中競爭失敗，對於企業來說則是遭受非常大的損失。
3. 成本可控性
第三方數據平臺往往是根據付費價格來區分服務質量的，如果想要享受到更多更好的服務，必須提高支付的費用，如果需要定製化方案，成本會變得更高；
如果採用自建平臺，首先開發什麼功能，調用多少資源都可以自己決定，對於成本有一定的把控能力，同時，如果後期擴展功能，也會更加地方便。
4. 組合多樣性
由於用戶的需求種類繁多，因此業務人員提的需求往往存在個性化特徵，例如需求以報表形式呈現，報表由各種指標組成，指標與指標之間形成了多對多關係，指標之間互相關聯，那麼這種多樣化指標是第三方平臺無法滿足的，因此自建的平臺就能體現它的作用了。
當網際網路的紅利逐漸消失，如何利用數據智能化運營將會是每一家企業的重要任務，運營人員的能力固為重要，但擁有一個好中臺，會讓你的運營走得更加順暢。
本文由 @Silence 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議