本來想探討一下數(shù)據(jù)產(chǎn)品和數(shù)據(jù)服務在業(yè)務應用中的價值量化模型，不過這個問題太抽象，目前還沒想清楚?？梢韵葟臄?shù)據(jù)開發(fā)的角度，來探討一下產(chǎn)出的數(shù)據(jù)價值量化模型，這個就具體、清晰、可操作地多。對于開發(fā)同學來說，不應該只埋頭開發(fā)，也需要關心自己產(chǎn)出的數(shù)據(jù)價值。
其實數(shù)據(jù)作為一個中間節(jié)點，可以以一個很簡單、直接、客觀的標準來衡量價值：如果下游使用得越多，則價值越高；如果沒有下游使用，則沒有價值。
數(shù)據(jù)開發(fā)的下游及應用場景主要包含：
- 為數(shù)據(jù)產(chǎn)品提供交互查詢
- 為業(yè)務平臺提供開發(fā)支持
- 為數(shù)據(jù)分析師adhoc計算用
平臺輸出與調(diào)用數(shù)據(jù)集成
按照上面的標準，數(shù)據(jù)產(chǎn)出價值完全由使用頻次來衡量，那么就應該盡可能完整地收集調(diào)用數(shù)據(jù)，那當然不能靠手動扔excel，需要通過平臺輸出并采集調(diào)用日志。平臺有多個沒關系，但日志格式需統(tǒng)一規(guī)范，并能聚合起來以作統(tǒng)一處理和計算。包括平臺頁面訪問、SQL查詢、接口調(diào)用，都需要明確到數(shù)據(jù)表粒度的日志。
數(shù)據(jù)倉庫血緣地圖
數(shù)據(jù)倉庫血緣地圖是一個DAG，表征著表節(jié)點生產(chǎn)的層次關系；既可用于指導數(shù)據(jù)生產(chǎn)的層級和順序，也可用于生產(chǎn)故障的快速定位與影響評估，是一套成熟數(shù)倉開發(fā)體系必不可少的工具。
在價值量化模型中，也是需要的——因為數(shù)據(jù)倉庫是分層建模的，有的底層表并不直接傳輸給下游使用，而是靠依賴其生成的上層表交付使用的，這種底層表也是需要參加價值量化計算的。
分層加權PageRank
數(shù)倉血緣地圖本身是一個網(wǎng)絡圖，而PageRank算法是一個經(jīng)典的以連接關系為主體的、計算節(jié)點權重的算法，所以當然也是適用于數(shù)倉DAG。不過相對于直接套用，有2個核心點需要考慮——
- 表層級：由于PageRank算法的特點，可能會造成越是底層的表，權重越高的傾向——不過最底層的表，往往是從業(yè)務系統(tǒng)中直接拉過來的，本身并不凝聚數(shù)據(jù)開發(fā)的邏輯和技術，因此需要把各個表節(jié)點本身在數(shù)據(jù)倉庫中的層級考慮進來，并對層級做一個折扣系數(shù)
- 調(diào)用權重：根據(jù)每個表被調(diào)用的頻次，歸一化成權重，作為PageRank排序的初始權重向量；當然，也不一定每次調(diào)用都等權重，可以根據(jù)部門、用戶、調(diào)用類型等多因素調(diào)整初始權重值
有了得分之后，就可以基于分布劃分區(qū)間：高價值、中價值、低價值、基本無價值。
打上價值標簽后，既可用于需求追蹤，也可用于長期復盤。
為什么要做數(shù)據(jù)產(chǎn)出價值量化？
思想方法（逼格）演示完了，我們再回過頭來，為什么要做這件事？
數(shù)據(jù)團隊的ToB服務本身也是需要數(shù)據(jù)化運營的，開發(fā)同學的每一次開發(fā)與支持，都需要留下數(shù)據(jù)，去分析、去復盤，去指導運營，作好數(shù)據(jù)化運營之后，才能做到——
- 把握重點：數(shù)據(jù)倉庫里那么多的表，打上了價值標簽后，你會發(fā)現(xiàn)高價值的產(chǎn)出表其實比例是很小的，這樣就能快速地get到重點，并且通過核心節(jié)點去了解業(yè)務主體脈絡
- 了解用戶：誰是重點用戶，誰的需求需要優(yōu)先支持滿足；誰的需求應該降低優(yōu)先級甚至拒絕？用戶的優(yōu)先級當然與其需求鏈接的數(shù)據(jù)價值對等
- 以價值為導向，而不是以支持為導向，將有限的資源向高價值的業(yè)務需求中傾斜，減少開發(fā)資源的虛耗，對于數(shù)據(jù)團隊的穩(wěn)定發(fā)展具有重要意義
不過需要強調(diào)的是，對于低價值需求，其責任并不在于數(shù)據(jù)開發(fā)，更多在于需求方——在于業(yè)務方和產(chǎn)品。
那么業(yè)務方和產(chǎn)品應該如何提升數(shù)據(jù)化運營思維，提高數(shù)據(jù)的整體價值水平？
這個問題下次再討論吧。
