從技術和業務視角，認識資料平臺
本文主要面向讀者為網際網路行業相關從業人員，期望對企業資料平臺有所瞭解的人群；因篇幅有限，文中所述的主題及相關概念點到為止。
一、什麼是資料平臺？
資料平臺字面的意思是“資料+平臺”：
- 資料：源於業務又作用於業務；
- 平臺：基於資料也服務於資料。
整體看資料平臺是由「資料流程」和「業務流程」兩大運轉主體共同構成的解決方案，兩大主體相輔相成、互相依賴、密不可分。
- 從資料流程的視角看： 不同業務型別企業的解決方案大同小異，目標都是為了保證資料整體的完整性、準確性、時效性；
- 從業務流程的視角看： 不同業務型別企業的解決方案各有不同，本文中業務型別偏電商類。
二、資料的技術視角
資料從生產到應用的整體流程是任何一個數據從業者都繞不開的主題，即便是非資料領域的產品和運營同學，同樣也應該對業務中資料的流向有個初步的認識。要展開描述，我們必須從資料的技術視角思考兩個問題：
- 需要解決的問題是什麼？
- 如何保證資料流中不同階段的最優解？
1. 需要解決的問題是什麼？
- 資料供給：提供便捷的資料生產方案，以資料產生為起點，規範資料整個主體的供給，為夯實資料平臺的基礎提供保障；
- 資料產出：保證資料在產出層面的普遍適用性。該階段包括分析報表，自動化分析工具，查詢入口等的建設；
- 過程管理：保證資料的完整性、準確性、時效性，實現資料從產生到應用全流程的高效管理。
2. 資料流的不同階段如何保證最優解？
「立足現狀，具體問題具體分析」，不同企業所處的業務發展階段不同，所面對的問題會不一樣。同樣，業務本身特性及企業對資料建設的資源傾斜程度不同，也會直接影響資料全流程處理的差異。最重要的還是立足於現狀，站在更高的戰略視角去思考整體的解決方案。下面從技術視角以“資料流”為骨架展開講解資料產生至應用各環節中我們分別需要做什麼：
2.1 資料產生
資料產生，這個階段是最適合向業務方宣灌資料生產應用流程的階段，因為該階段的優劣將會直接影響之後的各環節。該階段的關鍵字是「規範輸入」，需要給資料上游的業務方提供可行的資料埋點規範（業務團隊自身業務庫除外）：
- 資料接入流程： 需要對業務資料的接入流程做全面瞭解，重點從資料認知層面規避“不合理的輸入”；
- 資料上報地址及API應用方法： 確定API應用規範，保證資料上報位置準確，上報資訊不被丟棄；
- 埋點規範及內容 ： 在遵循資料接入埋點規範的前提下，保證各業務中具有差異性部分資料的完整性，通常會基於事件模型中的“who when how where what”幾個關鍵要素設計埋點；
- 資料測試方法： 資料測試方法也會依據埋點形式的不同而不同，一般分為前端和後端資料測試。前端常見測試抓包工具如“Fiddler”，後端通常將資料上報至測試伺服器，撈取日誌觀察其完整性、實時性。
2.2 資料採集
資料採集，這個階段是一個既主動又被動的環節。我們偶爾會收到xx業務方的疑問“為什麼業務上線了，沒有看到資料”，排查後才發現是因為模組日誌並沒有被採集。那該環節關鍵字便是「讓日誌被正確的採集」
- 針對現有業務： 資料部門會提供給業務方不同場景下的模組日誌採集方案清單，業務方只需按照現有清單選擇模組上報，資料部門會自動收集；
- 針對新業務： 資料部門會提供模組日誌註冊系統，形成良性註冊機制，讓資料部門提前感知，自動化收集模組資料。
2.3 資料處理
資料處理、清洗是資料輸入到倉庫的前置階段，該階段關鍵字是「清洗規則」，目的是建立符合業務需要的資料清洗方案。比如什麼格式的資料該被過濾；比如在廣告投放中，使用者符合哪種規則算是作弊使用者；比如在使用者行為資料中，符合哪種特徵的行為算是爬蟲使用者等等。
2.4 資料倉庫
資料倉庫面向應用而生，該階段的關鍵字是「分層、建模」。為了保證資料的普遍適用性及拓展性，會對倉庫進行分層，通常分為：源資料層、資料倉庫層、資料集市層、資料應用層。常見資料倉庫模型為“星型模型”，星型模型就是一種典型的維度模型。我們在進行維度建模的時候會建一張事實表，這個事實表就是星型模型的中心，然後會有一堆維度表，這些維度表就是向外發散的星星。
2.5 資料計算
資料計算是資料變活的過程，主要分為離線和實時計算，該階段的關鍵字是「準確、穩定」。會按照不同業務單元的需要，設計資料指標，並按照不同場景中的業務邏輯確定統計規則，最終由系統實現例行計算。資料本身並不具備任何價值，但一旦我們將它變為衡量事情的標準、將它變為洞察業務的眼睛，它就有了不可估量的力量。
2.6 資料應用
資料的應用是資料最終產生價值的部分，該階段的關鍵字是「完善、洞察」。基於資料流前面的流程處理，該環節最終會提供給應用方業務報表、資料訪問、自動化工具、統計模型等應用；以下描述了資料平臺和資料應用方在應用階段需要長期持續關注的問題：
- 資料平臺： 是否能提供完善的業務分析指標體系，是否能提供完善的精細化運營工具；
- 資料應用方： 現有資料是否足夠支撐業務分析，是否能依據現有資料發現更多的業務問題，是否能洞察潛在的商業機會。
2.7 元資料管理
元資料管理貫穿整個資料流程始終，是一個較為寬泛的概念，元資料治理的好壞將直接決定了整個資料平臺的品質。元資料管理主要分為三部分：技術元資料、業務元資料、過程元資料。
- 技術元資料： 如日誌檔案的路徑/格式、倉庫表結構、資料表血緣關係等；
- 業務元資料： 如指標歸屬業務單元、業務描述、計算邏輯、業務型別等；
- 過程元資料： 如表更新規則（增量/全量）、更新頻率、更新時間、量級等依據以上，我們可以從技術視角總結出資料平臺需要哪些東西，下圖是參考示例：
三、資料的業務視角
基於立場的不同，導致了從業務視角與從技術視角看到的表現層內容會不一樣，但究其本質是相通的。無論資料在應用層面以何種方案最終呈現，最終都是為了解決問題而存在；參考「黃金圈法則」我們同樣也需要從資料的業務視角去思考三個問題：
- 為什麼需要資料團隊解決？
- 需要解決的問題是什麼？
- 該通過什麼方式解決？
1. 為什麼需要資料團隊解決？(why)
「聞道有先後，術業有專攻」與「有所為而有所不為」，業務技術團隊的定位是服務於業務一線，資料團隊的定位是提供專業性的資料解決方案，二者分工上的差異性決定了解決問題的最佳路徑。如下列舉了需要資料團隊解決幾類問題：
- 資料型別： 資料產生場景複雜、資料型別多（行為、交易、使用者、商品..），資料結構複雜（結構化/非結構化/半結構化資料）；
- 資料量級： 儲存量級大，傳統關係型資料庫不能解決；
- 資料處理： 清洗規則多，計算任務流程長，計算血緣關係複雜等；
- 資料應用： 行為分析，多維交叉分析，實時多維分析，豐富的視覺化等。
2. 需要解決的問題是什麼？(how)
（1）我的業務是什麼
不同業務單元依據自身業務屬性，需要資料團隊解決的資料問題也不一樣。如市場團隊關注應用市場投放相關的資料，客戶端團隊關注裝置/應用版本/使用者轉化相關的屬性資料，運營團隊關注活動相關資料，風控團隊關注風控相關資料等。
（2）我該如何衡量它們
團隊屬性的不同，也決定了量化到資料指標的衡量標註不同。各業務團隊擁有自己的關鍵唯一指標和對應拆解/下鑽的指標體系。
（3）如何讓資料驅動業務
市場團隊通過衡量不同渠道來源使用者的質量，評估渠道ROI，優化投放策略；客戶端團隊通過觀察不同產品方案的轉化效果，改進註冊及其他核心行為發生的主流程設計；運營團隊通過使用者細分，評估不同使用者群在活動對的轉化效果，進行精細化運營等。
3. 通過什麼方式解決？(what)
以下從業務視角拆解資料平臺產品解決方案：
3.1 實時監控
- 實時看板：專注於關鍵核心指標的實時表現，如使用者、商品、訂單等。視具體情況會將關鍵指標維度下鑽後進行實時監控
- 實時電視監控：依據平臺數據源，適用於電視投屏，監控看板展現等
- 紅包/促銷監控：關於紅包主題的實時監控，觀察業務中的紅包發放/紅包使用等波動情況，判斷業務健康度
- 使用者監控：監控使用者活躍/使用者新增的表現，與推送服務、品牌投放、投放等的業務動作進行相關分析，判斷效果是否符合預期，及時優化策略動作
- 其他
3.2 離線分析
- 核心看板：企業業務發展所處階段的不同，所關注的核心指標也不同，核心看板著重關注公司戰略層核心指標在核心維度上的趨勢及構成表現
- 業務看板：業務看板服務於不同業務團隊，亦可視作各業務單元的核心看板
- 流量分析：描述使用者從哪裡來，不同渠道使用者的後續核心業務表現。同時也承載渠道資料管理的工作（如渠道分組/渠道關係維護等）
- 使用者分析：使用者構成、使用者留存、使用者轉化、行為、生命週期等場景的分析
- 商品分析：商品構成、庫存、售出、質量、商品生命週期等場景的分析
- 交易分析：主要用於交易主題的多維交叉分析，使用者與商品在交易鏈路上的具體表現，如：曝光→瀏覽→諮詢→下單→支付→售後等鏈路的分析
- 專題分析：搜尋推薦分析、風控分析、競對分析、垂類分析、運營位分析、垂類專區分析、活動分析等
- 其他
3.3 精細化運營工具
- 事件分析：基於事件模型的自動化分析工具，業務方可依據行為埋點查詢到不同行為事件的使用者表現
- 事件漏斗分析：基於事件模型的自動化漏斗分析工具，可自行設定業務轉化漏斗，觀測各精分業務流程中的轉化效果，拆解轉化問題
- 留存分析：按照留存模型，起始行為精分使用者群體，依據精分使用者群不同行為頻次的表現，觀測各層使用者的留存
- 畫像分群：按照不同主體拆分屬性，通過屬性組合，篩選目標分群，進行精細化運營（1.使用者分群：以唯一使用者ID為主體，組合使用者的不同分類屬性，篩選目標使用者群，做差異化運營或使用者分析；2.商品分群：以唯一商品ID為主體，組合商品的不同分類屬性，篩選目標商品群，做精細化商品分析；3.訂單分群：以唯一訂單ID為主體，組合訂單的不同分類屬性，篩選目標訂單群，做精細化交易分析）
- SQL查詢工具：視覺化SQL查詢
- 其他
3.4 智慧預警及分析
- 實時異常分析：實時異常分析基於歷史資料，獲取當前時間點的可能數值範圍，當實際值在該範圍以外時，即認為資料異常。關鍵要求是及時和準確
- 智慧分析：具體策略是對關鍵核心指標進行維度拆解，尋找出影響核心指標波動中不同維值的“貢獻度”，最終定位問題
- 其他
3.5 其他解決方案
- 自動郵件：通過配置化的方案，實現資料報表的自動郵件推送。也可以在離線報表上設定開關，傳送具體頁面資料表到指定郵箱
- 資料分析：如：商品分析、交易分析、轉化分析、DAU預測、訂單預測等
- 資料探勘：通過聚類、迴歸、關聯規則等常見挖掘演算法分析問題，發現機會
- 外部資料：競對資料抓取及分析
- 其他
依據以上，我們可以從業務視角總結出資料平臺產品矩陣，下圖為參考示例：
四、最後
我們在實際工作中，技術視角和業務視角應該是交叉共存的。即在沿著技術視角去開展資料流鏈路上的工作時，也需要同時關注業務本身的情況，設計出更優雅的解決方案；同樣在業務視角應用資料手段去推進工作時，也需要關注資料流中各階段上潛在的問題與風險點。
道阻且長，溯洄從之。
作者：蔣坤偉，轉轉產品經理；個人公眾號：黑夜月
本文由 @黑夜月 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議