數據平臺在產品發展中的定位是怎樣的呢？應該何時搭建數據平臺？數據平臺的作用又是什麼呢？數據產品經理如何從0開始做數據平臺？
我是一名創業公司的產品經理，從0到1做公司的產品，近兩年，因公司業務發展的需要，開始做公司內部的數據平臺，我也由一名業務產品經理轉為數據產品經理。以下是我結合自身工作的一些總結，與大家分享。
數據平臺的定位
產品經理看事情總是先面後點，我們也按照這個思路來展開話題。
那麼數據平臺在產品發展中的定位是怎樣的呢？應該何時搭建數據平臺？數據平臺的作用又是什麼呢？
請看下圖：
1. 試錯期的迴音壁
我們的主產品是做社區O2O電商平臺，上圖也是以此為背景進行展開的。
我們的主產品2015年下旬上線，彼時公司對產品的定位還不清晰。連續幾個版本基本上就是“試試試”，產品團隊開展了大量的競品調研以及用戶調研，針對於社區業主，我們先後提供了物業服務、社交服務、優選商品服務、周邊信息服務等。公司的業務部門也不斷招人，組建新團隊，支撐各個業務。
這個階段，全公司上下都在埋頭做業務，對於做數據平臺，一是沒意識，二是沒概念，三是沒精力，四是沒必要，所以這個階段的數據建設主要依靠第三方平臺。通過埋點和漏斗，完全可以掌握產品的基本情況，哪個功能訪問量高，哪個功能訪問量低，迭代後的效果如何，一看便知。
（上圖截取自友盟的demo ）
2. 拉昇期的度量尺
通過一年的內功修煉，我們逐漸搞清了套路，2016年中旬，開始做推廣、拉用戶。公司開始制定KPI，各個業務部門開始背指標，我們的自建數據平臺也是從這時開始的。之所以開始做自建的數據平臺，主要為了方便考核，大家都懂的。
平臺的主要內容就是各類報表、分部門、分渠道的各類指標。
上圖是我們的一張報表，因為我們的業務是圍繞社區開展的，故此以社區為維度考核，這張報表監控了每個社區的註冊用戶數、認證用戶數。
除了做報表，在這個階段也要同步建立數據的權限管理，畢竟老闆不希望每個員工都知道公司全部的數據。
3. 轉化期的顯微鏡
熟悉產品生命週期的各位同行都知道，拉昇期之後該開始做轉化了。到了這個階段，數據的事情就有些複雜了。我們在2017年，做了一整年的商城，配套也做了一系列數據產品。包括交易數據、用戶數據、商品數據、實時數據、會員數據等。
這個階段最主要的任務是為業務部門提供方便的數據分析的模型，發揮數據的顯微鏡作用，讓數據能夠即時、準確的反映業務實質、幫助業務進行改進。
關於數據模型的，後面的內容會提到。
4. 平臺期的指揮艙
“指揮艙”這個詞有點大，但概念卻恰如其分。到了平臺期，產品已經成為比較大的流量入口，各個商家開始重視平臺的作用，投入人力、物力運營自己的店鋪。這時，數據產品也要及時跟進，為他們的運營提供支持。就像淘寶、京東商家的數據後臺，可以方便的幫商家查詢各類信息。
這個階段數據的第二個應用是推薦系統和搜索系統，當用戶數和SKU數足夠大時，讓用戶快速的找到自己想要的商品，能夠極大的縮短決策流程，對轉化率大有幫助。
當然，在這個階段，我們利用數據還可以做風控系統，預測系統等大數據產品，幫助平臺更加健康的成長。
數據平臺的三大法寶
在數據平臺的建設過程中，有諸多的要點，但有三個方面還是要單獨拿出來說，因為他們實在是太重要了。指標、維度、模型我認為是數據平臺建設的三大法寶。
1. 指標第一
指標！指標！指標！
對於指標這個概念的重要性，強調再多遍也不過分，我在這上面踩了不少坑。
剛開始做數據平臺時，我們的CTO跟我說先整理指標和維度，我不以為然，在網上找了個帖子直接了事。結果一系列挖坑的過程就此開始了，產品上線後，業務說數不準，我說沒問題，都核對過了。結果找來找去是雙方對指標的定義不統一。
關於指標有兩個方面經驗跟大家分享。
（1）原始指標和聚合指標
在我們定義指標時，要分清楚那些是原始指標，那些是聚合指標。
業務上直接產生的數據就是原始指標；按照某個維度進行計算後的指標就是聚合指標。正常的順序是先定義原始指標，再定義聚合指標。
舉個例子說明：
一條訂單記錄，訂單金額就是原始指標；計算一天的GMV就是聚合指標。
- 定義原始指標時，概念要清晰，例如：定義訂單金額時，算不算郵費、算不算優惠等。
- 定義聚合指標時，維度要清晰，例如：我們公司的例會通常是每週六召開，所以我們在統計時設置了一個例會周的概念，例會周是從上週六到本週五。kpi指標都是按這個維度聚合。
（2）指標的迭代
指標要跟著業務的發展進行迭代。
我們在做會員時，有一個最基礎的指標：增加會員數。這個指標看似簡單，但我們經過了幾個版本的修正。
請看下圖：
上圖中可以看出：概念和指標，會隨著業務變化而變化。
值得一提的是：表中的指標都是聚合指標，在我們做這個定義之前還應該做好維度的定義，例如：淨增會員數=新增會員數-減少會員數。新增會員數是
按照充值的時間聚合；減少的時間按照退會或者出會的時間聚合（而不是這個用戶成為會員的時間）。我們應在數據平臺建設的初期，建立好指標庫，指標庫儘量詳盡和豐富。指標的概念應該與業務核對清楚，並由領導審批，最後交給技術。
指標庫是全公司公共的概念，業務考核、產品迭代，都是以此為基準。
2. 維度第二
維度的存在，讓指標變得更加立體，就像OLAP中的多維數據模型。事實上，維度的建設會比指標更加貼近業務，市場上的做電商的平臺，可能大部分指標都是相同的，但每個平臺一定會有一些特有的核心維度，這些特有的維度也恰恰定義了企業的商業模式。
下面是一些梳理維度的思路：
（1）顯而易見的維度
一些通用的維度還是比較容易梳理的，下圖以電商產品為例簡要列了一些，供大家參考：
我們在梳理維度時可以直接分級，也可以先不分級，做模型的時候在需要的場景下再分級。
（2）與業務緊密相關的核心維度
上文提到，每個平臺都有特定的核心維度，梳理這些核心維度，考驗了產品經理對業務的理解能力和抽象能力。
舉個例子來說明一下什麼是核心維度：
事實上核心維度並不是指的優先級最高的維度，而是按照優先級排列的一系列維度集合。
（3）業務發展過程中出現的動態維度
細心的讀者可能發現，在前兩個小節中，我漏掉了一個重要的維度——用戶維度。事實上在任何一個產品分析中，用戶維度都是極其重要的。在我的概念中，用戶維度是一個在業務發展過程中的動態維度。
那麼，何為動態維度？
動態維度在一開始並不是顯現的，不像時間、空間、業務實體這種來自於組織架構或者業務形態等，直接可以在業務流程圖中讀出的維度。動態維度需要業務發展過程中歸納提煉而出，並且會隨著業務的發展不斷變化。
回到用戶維度，在業務發展的初期、中期、後期用戶的畫像和模型一定是不同的。依然用張老闆飯店的例子為大家說明：（我們需要假設張老闆在創業初期就能夠獲取用戶數據）
用戶維度是最重要的動態維度之一，與此同時，根據不同的業務，還會有其他的動態維度。例如：商品可以按照價格區間、利潤率設置維度；店鋪可以按照動銷比、好評度設置維度；我們需要結合自身的業務，挖掘這種新的維度。
3. 模型第三
當我們建立好指標庫和維度庫後，接下來就是設計數據平臺了，但在此之前，我們先來了解“模型”這個概念。
模型，相信大家都不陌生，像AARRR模型，RFM模型都是我們耳熟能詳的經典模型。但模型的概念，在很多人心中也許是不同的。
比如：我們和研發聊模型時，研發的心中是：業務模型、數據模型、物理模型。對於數據分析或者數據平臺設計過程中的模型，我心中的概念是：經過實踐、在一段時間內固化下來的數據分析的方法。
數據平臺的頁面和圖表，其實就是數據模型的體現。所以設計數據平臺，其實就是建立分析模型的過程。
那麼如何來做呢，接著跟大家分享：
（1）從KPI和業務入手
前文中提到，需要建立內部數據平臺時，企業已經發展到了一定階段，所以不管有沒有模型的概念，事實上，在管理層和業務人員的心裡已經有了模型。從領導的角度，模型會體現在下發的KPI上，從業務的角度，會體現在各自的業務分工或流程上。
我們仍然以張老闆的飯店舉例，假設飯店處於第二階段：張氏酒樓承接散客和酒席。
下圖是為張老闆設計的每日數據臺賬：
我們在給張老闆的報表中，首先按照兩個業務“散客”、“酒席”將三個關鍵指標營業額、顧客數、菜品量進行了拆分。
我們為什麼這樣拆，可能是張老闆為這兩個業務線定了不同的KPI，也可能是這兩個業務分由兩個人分管。但最重要的原因是：這兩條業務線的運營流程是不同的。我們首先需要把這兩項分開，才能進一步分析。
（2）模型的類型
上圖只是一個示例，所謂數據平臺，就是通過一張一張的圖表，把業務的真實情況反映出來。展現給各個相關的崗位人員，幫助他們改進做法。
我歸納了幾個模型類型，供大家參考：
- 拆解模型：上面的例子就是一個拆解模型。當我們遇到相對獨立的維度時，可以用拆解模型，例如：按業務拆、按地域拆、按用戶拆。
- 流程模型：當我們在分析一個流程性的業務時，適用於流程模型，比較經典的：AARRR模型，漏斗模型都是屬於此類。
- 對比模型：數據，對比才有意義。所以我們在分析數據時，最常用的就是對比模型。例如：環比，銷售品類相同的不同商家之間的對比等。
- 歸納模型：歸納模型要稍微難一些，有點類似於上文提到的動態維度，我們需要在摸索中總結，找到評價和總結某個事物的核心指標和維度。例如：RFM模型、用戶畫像、店鋪畫像等都屬於歸納模型。
4. 三大法寶之外
除了上面說的三大法寶，構建數據平臺還有一些其他要素：
（1）可視化
說白了就是什麼情況下用什麼圖，怎麼設計和組合圖形，才能準確、形象的傳達信息。事實上數據可視化是一門比較高深的藝術，我印象裡國際上好像還有類似的比賽，這方面的資料、書籍也比較多，都比我專業許多，就不展開說了。
（2）權限
數據權限是比較重要的，做數據產品經理，應該在一開始就樹立數據的保密意識。
這部分大致上分為功能權限和數據權限：
- 所謂功能權限：就是按照菜單劃分權限，有的人能看到這個菜單，有的人不能；
- 所謂數據權限：就是雖然大家都能看到這個頁面，但每個人看到的都是篩選過的數據，僅是自己能看到的範圍。
我們在這方面做的比較簡單，相信在大型公司，權限部分要複雜的多，還請大牛朋友指點。
（3）結構
這裡說的結構，我想表達的是數據平臺的各個菜單怎麼來設置，都放哪些內容。數據平臺說白了是個B端產品，B端產品在意的是效率，所以我們的頁面結構，通常情況下是按主題來分的。
當然有條件的也可以讓業務自定義看板。下圖是截取的友盟、騰訊移動分析、GrowingIO、諸葛io的菜單截圖，供大家參考，大家也可以自行登錄相應的網站查看demo學習。
總結
怎麼從0開始做數據平臺：
- 找定位：看到底需不需要做，做到什麼程度；
- 訂指標：制定儘量詳盡的指標庫；
- 畫維度：按照重要程度列出與業務相關的維度；
- 建模型：與數據用戶一起，構建每個崗位的分析模型。
完成這四部之後，就可以做原型圖，寫需求了。當然過程中還要注意、權限的管理、可視化的運用、以及結構的編排。
那麼有了以上這些就夠了嗎？
其實這只是一小部分，能夠順利搭建數據平臺，還有三個關鍵點：
- 一是企業的管理層是否支持，包括政策上的支持，資源上的支持。在資源緊張的情況下，領導是否願意拿出一部分資源來做數據平臺；
- 二是研發資源是否匹配，大家都知道做大數據是有一定的技術門檻的，這塊出了問題，很可能造成後期數據不準、查數據慢、迭代困難等；
- 三是業務上要有使用數據的習慣，這個大家都懂得，要讓你的用戶和你的產品一起進步。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
