本文由作者?董小礦?于社區發布

前言：有幸深度參與了公司從無數據，到有數據，到開始重視數據，最后能夠尊重數據結果，參考數據進行決策的過程。本篇文章是筆者在這個過程中，作為數據產品搭建數據指標體系，如何踩坑、出坑，以及對數據倉庫建設中的一些總結。

如標題所言，如果貴司已經是B輪之后，數據指標和平臺化產品應該已經比較健全，屬于數據產品應用階段。如果貴司處于B輪及B輪之前階段，大概率上會出現筆者下面所描述的情況。

本文較長，目錄如下：

1 混亂期：資源有限，功能為先，忽視數據

1.1?資源永遠不夠用

1.2?數據產品的窘境

2 規范期：他山之石：GrowingIO和神策

2.1?GrowingIO平臺實踐總結

2.2?神策平臺實踐總結

2.3?他山之石后的埋點設計及管理

3 平臺期：建設數據倉庫

3.1?數據維護及治理

3.2?數據倉庫架構設計

4 未來：數據中臺？

4.1?我理解的數據中臺

4.2?數據中臺學習資料推薦

------正文分割線------

1

混亂期：資源有限，功能為先，忽視數據

1.1 資源永遠不夠用

筆者所在的內容服務公司，在搭建指標體系前，已經“裸奔”了3年。對于內容產品來說，最影響用戶體驗的是內容本身，公司前期依靠不錯的內容口碑，搭上知識付費的風口，發展迅速，公司資源和業務方向更多是受運營驅動、銷售驅動，目標簡單而明確，做什么心里都有大致預判，輕輕拍拍腦袋，這事兒就定了。后來平臺用戶數達到第一個1000w，日活進入50w量級后，新人加入，業務線也在拓展，基于主線業務上的優化和探索，不敢再輕易拍腦袋了；各業務線也有不同的訴求，如何評判優先級和協調資源，沒有數據，很容易僵持不下。

也是在那個時候，決定要參考數據來決策了。之前APP偏向于做功能，只在特殊功能點，或活動節點時，會在產品需求文檔中，附上埋點需求。彼時突然想看很多數據，會發現除了一些大數據（日活、激活率、付費率等）外，缺少很多細部數據，因為壓根沒有做埋點上報的需求，從日志中也無法解析出相關數據。

后來在每個版本中，由功能產品經理附上相關功能的埋點需求，大部分開發資源還在具體功能開發上。在功能上線后很久，才會想起來撈數據看看效果。初創公司很容易在業務快速擴張中忽視數據的作用，產品開發團隊首要解決的是不斷新增的業務需求。資源總是不夠用的，所以數據埋點處理、數據分析、復盤等工作一直處在被忽視的地方。

1.2?數據產品的窘境

彼時我轉崗到數據產品，常自嘲自己是一個取數機器。公司有數據需求的部門共有7個，我負責對接各部門的數據需求，梳理清晰后再提交任務給大數據組，由他們做具體的ETL工作。這中間，常會陷入到以下的汪洋大海中：

與需求方溝通并最后明確最后的數據需求（比如：活動組提需求想看某活動頁分享數據，經溝通之后，其目的是想看新頁面的文案上線后，對分享/瀏覽比的影響，因此明確了該需求是該頁面的uv、pv，以及分享控件點擊的人數、次數）；

提交明確需求后，大數據組發現之前沒有埋點，然后需要跟需求方解釋，這個數據為什么拿不到，從ta的分析目標再看看，是否還有其他數據也能夠達成這個分析目標。

那段時間非常忙碌，但總感覺自己是個二傳手，最大的收獲，就是在對接了N個需求之后，發現我司的數據基礎建設情況慘不忍睹：平臺埋點不規范、數據指標定義不統一、業務數據庫和數據倉庫標準不統一、數據需求處理周期長……?我的精力很多耗在溝通需求、管理需求上。后來與公司的數據分析部門一同討論制定了一套新的數據提交流程：每個部門的需求匯總到部門中的一個數據對接人，由ta先行提交到數據分析組，簡單需求，會由數據分析組通過DBeaver等工具，連接數據庫導出，復雜類、工具類需求，則提交給我：

圖1：數據需求提交流程

另外，針對每個部門的數據對接人進行了指標定義的說明，以及提交數據需求的規范標準的培訓：

圖2：培訓資料一頁：什么是好的數據需求

此時的工作還停留在偏臨時需求的處理上，作為數據產品，卻沒有做出多少數據產品出來。

2

規范期：他山之石：GrowingIO和神策

在決定搭建數據體系后，我司接洽了幾家頭部的數據平臺，如GIO、ThinkingData、神策等，來補充我司埋點功底薄弱的問題，最后選擇了GIO，在使用了一年多之后，因為要做私有化部署，而GIO的私有化部署功能還剛處在開發階段（寫這篇文章的時候，他們的私有化部署已經做出來了），于是我司又決定換神策平臺，重新來一遍POC和SDK接入工作（對，就是這么折騰，o(╥﹏╥)o）。

在完整地對接了這兩家平臺之后，我司數據體系逐步走向規范，我也總結了一下兩家平臺關于指標管理、數據體系搭建的工具特點，以及思路進行了一些總結，如下。

2.1?GrowingIO平臺實踐總結

在接觸了幾家平臺后，我們最終選擇了GIO，該平臺的特點非常明顯：

1、擁有無埋點技術，能夠實現做功能時，不需要專門針對埋點花費工時，接入GIO的SDK，在功能上線后，SDK能夠采集基礎使用信息，同時，針對頁面瀏覽數據，和頁面控件點擊數據，可以通過“圈選”的方式實現（對于彼時苦于埋點效率低下的現狀，這種方案極具誘惑）；

2、公有云部署，接入成本低；

3、后臺操作界面簡潔，屬于運營思路的一款產品，上手較容易；

4、因為是SaaS服務，線上問題反饋速度比較快。

但后來發現一些問題：接入SDK后，我們只簡單對接了會員狀態數據，做了少量的埋點指標，除此外手動圈選了大量頁面指標和控件數據，因為GIO的圈選功能實在太好用了，所見即所得，不必再發版等埋點上線，經過簡單操作后就可以自己取數、看數，結合GIO提供的基礎分析工具，如事件分析、漏斗分析、留存分析等功能，人人都能成為一名分析師了。

圖3：GIO圈選功能

但到后期，圈選數據的問題逐漸暴露，也成為平臺要更換GIO平臺的導火索。圈選數據的邏輯：是根據頁面xpath路徑，監聽頁面瀏覽事件，和頁面上的控件的瀏覽、點擊事件，保留7天，因此圈選完成后，能往前追溯7天的數據。圈選功能的問題主要在于：

1、耗流量，看下邏輯你應該能理解；

2、一旦版本迭代，對頁面的路徑做修改，或者控件位置、文案有修改，原來的圈選數據可能就會出錯，需要重新圈選，之前利用圈選指標設定的分析模型都要替換；

3、圈選指標無法區分細部參數，比如：書籍詳情頁，無法通過圈選數據來區分是哪一本書；

4、對web的頁面數據處理一直不好，尤其是涉及到APP的內嵌H5頁時，非常痛苦。

圖4：版本升級后，某圈選指標數據突降

這其實也是GIO的業務同事比較推崇無埋點技術，而我司彼時經驗尚不充足踩下的坑，到后半階段開始補課，開始做客戶端和服務端埋點了，埋點開發周期雖然長了點，但是至少能夠用得起來。但是因為之前對GIO工具使用上產生的各種不爽，導致后面有了更準確的埋點后，大家用起來也常常懷疑，這數據準不準，能不能用？

一旦對數據源產生不信任感，產研團隊的解釋成本高，數據發揮價值的周期變長，團隊屢受質疑又看不到成績，大數據團隊本身在數據體系建設的早期存在感就低，如此一來，工作積極性變得更低。

后來受資方等多因素影響，我們需要做私有化部署，對數據的準確度、智能運營也有更進一步的需求，而彼時GIO還沒有成熟的私有化部署功能，因此我們兩家后來好聚好散，轉而選擇了神策。（此處抱著GIO的同學哭一會兒）

但總體來說，GIO平臺還是可圈可點，它的優勢在于：

1、數據響應速度快，圈選功能比較成熟，對于快速迭代活動的場景，圈選功能最為便捷；

2、用戶操作界面友好，幾大核心分析功能邏輯結構清晰，學習成本低，能夠實現在公司大范圍推廣使用（你千萬別覺得這類數據工具是可以輕易上手的，根據我在公司推廣GIO和神策的經驗，工具使用門檻并不低）；

3、售后團隊比較專業，能夠從分析視角，發現我司業務上的問題；并且對平時提到的問題，反饋及時，問題解決程度也比較高。

2.2?神策平臺實踐總結

后來因為私有化部署的訴求，選擇了神策平臺的產品。這里解釋下，為啥沒有選擇自己研發數據產品。這其實是一個很經濟學的考量。在接入GIO前，我司有自己一套ubt的埋點系統，但是只是基礎的數據采集，以及raw data進數據庫，從raw data 到數倉，再到提取，把統計類數據以excel形式，或者教會分析人員使用SSMS或PowerBI來進行取數分析，中間流程太長，無法做到快速響應及反饋。而找一個團隊自研，時間成本和人力成本都太高。

神策、GIO這樣的平臺，取數功能完整度比較高，而且有一個比較完整的可視化分析平臺，包含了事件分析、漏斗分析、留存分析等基礎的分析功能，也有歸因分析模型、用戶畫像等功能，這些功能找一個大數據團隊和幾個算法工程師，一年的成本高了去了。對于B輪左右的公司，建議別折騰，花點錢，除了避免自研成本，還能從這些SaaS平臺的服務中，了解到比較成熟的方法論。

神策的分析全家桶有以下幾款產品：

圖5：神策產品矩陣

其中，左邊【數據基礎能力】是基礎服務，可以選Pass，也可以選私有化部署，但是節點費、流量費是根據自己的流量來核算。（市政單位，或者對業務數據安全敏感度高的，建議私有化。不是說Pass不安全，像神策、GIO這樣專門做數據服務的平臺，不至于去泄露客戶數據，一個客戶數據泄露事件就可以讓這類企業直接掛掉，這個賬他們拎得清，而且有數據隱私協議）

右邊的【數據應用產品】則是可選項了，【神策分析】包含了事件分析、漏斗分析等基礎的分析功能，一般必不可少；【神策用戶畫像】和【智能運營】是偏向于運營側的工具，如果自己沒有精準營銷的產研能力，這兩項服務業比較好用。至于【智能推薦】和【神策客景】則根據公司情況，對于內容龐雜，品類繁多的內容平臺、電商平臺，還是比較有必要。但我個人認為，前三項服務玩得轉了，再去考慮采購后兩項服務不遲。

神策平臺的特點是一開始推的是埋點方案，而非無埋點方案；而且最早支持私有化部署的數據服務平臺。這一點是讓他們能夠獲得一些金融行業、政企行業的單子的原因。這也是我們最后評估后，選擇他們的原因。

2.3?我司平臺的埋點設計及指標管理

在經過了UBT、GIO和神策三套埋點方案的使用和比較后，對于我司自己的埋點系統也有了比較清晰的方向，最后決定采用常規數據使用前端埋點、關鍵數據使用服務端埋點、臨時活動搭配使用全埋點的方案。

全埋點、前端埋點和服務端埋點的區別

而我司基本是前端埋點和服務端埋點的組合，其中關于數據指標的設計和管理，采用了下圖所展示的字段名，對事實表進行管理和維護。

圖6：我司數據指標維護表頭

關于數據指標管理，最讓我頭大的就是如何保證可讀性的前提下，梳理不斷新增的數據埋點需求。我的設計思路是：以使用者視角設計，盡可能合并同類型指標，用維度保證擴展性，用備注內容保證可讀性。

上面的指標維護表，是要同時給開發人員，和運營人員看的，這里指的使用者，是指運營人員。因為最后埋點設計做完了，也正常上報了，但是運營人員看不懂，用不起來，培訓成本高企，是無法充分發揮數據價值的。所以在這里就需要數據產品經理平衡簡約和可用性。

舉兩個例子：

例子1：平臺資源位埋點設計

對于一般互聯網產品平臺來說，資源位無外乎兩種類型，彈出型和輪播型；而具體指標無外乎瀏覽和點擊，因此，將這兩種類型的資源位抽象成下面4個指標，由維度（資源位位置、輪播位置）來進行拆分。

圖7：平臺資源位埋點設計

例子2：內容詳情頁埋點設計

對于內容類、電商類平臺來說，內容詳情頁和商品詳情頁是最為關鍵的頁面，因此這個頁面的瀏覽數據極為重要。因為詳情頁是一個通用頁面，而且對于一篇文章，或者一個商品來說，可能會在APP出現多個入口，如果對N個入口進行分別埋點，會讓指標建設冗余，并且因為網絡環境等影響，點擊數≠頁面加載≠頁面加載成功，可能會采到臟數據上來。因此我在這里的設計思路是：以頁面加載成功為觸發，區分頁面本身的數據信息，以及上一個頁面的維度信息。

圖8：內容詳情頁埋點設計

這里的挑戰來自于去梳理上一個頁面的類型和具體參數值，需要與運營組、數據組同事溝通清楚，他們關心的維度，以及下鉆的顆粒度。

?

3

平臺期：建設數據倉庫

建設數據倉庫是一個必然的選擇，在業務體量不大，數據需求不多的情況下，從業務數據庫撈數據，甚至解析日志，都是能夠滿足的。但后期必然會有更多維度、更復雜的分析型、報表型數據需求，全部依靠業務數據庫顯然不現實。現在計算機存儲成本不高，數據倉庫可以看做是一個【用空間換時間】的方案，數據倉庫是面向分析、應用的數據庫，在建立好標準的ETL流程和更新機制后，分析型、報表型數據需求從數據倉庫中獲取，從而提高效率，也解放業務數據庫，讓業務庫專心處理業務。

目前有關數據倉庫的文章非常多，對數據倉庫應該分幾層，也有很多說法。這里需要明確一點，數據倉庫的分層是一個理念，其核心是將不同應用層級的數據進行劃分。一般來說至少有三級，我司采用的也是三級數倉。

3.1?數據維護及治理

基于Hadoop的成熟體系，搭建完成數倉系框架后，接下來要做的是往數倉中填充數據“血肉”，以及持續進行數據治理的工作了。在用數據賦能業務的鏈條中：產生數據（埋點）-> 獲取數據(ETL) ->?分析數據 ->?發現問題 ->業務決策，似乎并沒有數據治理的事情。

鏈條上的四點是可見的過程，而數據本身產生污染后，可能會到獲取時、分析時，甚至是決策階段，才會意識到數據本身可能出現了問題。數據從觸發上報->?發送-> ETL->?進數倉，中間有任何一個過程出問題，都可能會影響數據的穩定、準確和及時。另外，不斷擴展的業務需求，業務數據字段會發生變更，這時錯傳、漏傳了數據進數倉，也會影響數據質量。

總結下來，基于下面三個點，需要持續進行數據維護和治理：

1.數據進倉鏈路長，存在出現臟數據的風險；

2.新業務需求增刪改字段，沒有及時同步進數倉；

3.數倉表結構字段設計擴展性不足，新數據需要單獨建表，導致冗余。

針對第1點，我司對于數據指標本身的異常波動做了監控的設計。在接入了神策平臺之后，該平臺提供了一個指標異常波動提醒的功能，還挺好用。

圖9：神策數據異常監控

針對第2點說說我司實踐。我司通過搭建【異構數據平臺】來解決業務數據同步到數據倉庫的問題。業務數據在進數據倉的同時，會按照約定的規范，同步傳送一份到數據倉庫；如果有修業務數據的情況，也需要異步地通過該平臺，發消息給數據倉庫，由數倉消費后，更新數倉的數據。

針對第3點，沒有什么好辦法，需要數據產品和大數據組、業務產品經理多溝通，對于數倉目前有哪些表，哪些字段，功能規劃上，未來會新增哪些產品線，與當前業務線的關系，有一個大致預判，最大程度減少重復建表的工作。

3.2?數據倉庫架構設計

基于以上，我司數據倉庫是基于Hadoop框架，Hive處理離線數據，Flink處理實時數據，實現用戶行為數據和業務數據準實時入數倉（有一些延時），并且前端數據產品應用，從數據倉庫中調接口取數。（目前還沒有完全實現所有業務數據都從數據倉庫走，還在建設中）

圖10：數據倉庫架構設計

4

未來：數據中臺？

數據中臺概念在19年實在太火了，頗有些12年，到處都在說O2O的情形。對于數據產品來說，將產出的數據產品抽象化、共用化，成為像中臺一樣的基礎服務能力是心之所向。但是否應該盲目上中臺項目，談談我的理解。

4.1?我所理解的數據中臺

我很喜歡【中臺】這個詞：處于中間，承上啟下；成為平臺，隔絕上下流動，但自身提供服務上下的能力。對于數據中臺，其核心是提煉各業務線的共性需求，將這些需求解決方案封裝為標準化、組件化的解決能力，然后以接口的形式提供給前前臺業務數據。從而實現盡量少地重復造輪子，盡量多地提高研發的敏捷性。

不是所有公司都需要立刻做中臺，但根據熵增定律，一家能持續發展的企業，其業務形態一定會不斷發展和膨脹，而當新業務線和老業務線有共性訴求，能夠通過中臺化來提高效率，并且具有能串聯多業務線的項目能力，這些問題想清楚，就可以開始做中臺項目了。

------正文分割線------

那么，如何才能快速低成本搭建自己的數據體系呢？

快來「云隊友」招個靠譜的兼職數據分析師吧！

總結

以上是生活随笔為你收集整理的埋点、数仓到中台：数据体系的从0到1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。