指標生命周期管理
本文旨在通過分享一系列從實踐出發的方法和策略,解決指標管理中的混亂問題,提升業務與數據團隊的工作效率。我們將探討如何規范指標的上線、使用和下線流程,以確保數據的準確性和一致性,從而幫助企業更好地做出決策和優化業務流程。
前幾天一個同學前來訴苦,說他們公司指標太混亂了,一大堆相似的指標,每次用起來都要花大量的時間去確認到底該用哪一個。時不時就會出現彼此對不齊的情況,業務部門滿意度不高,數據部門也比較痛苦。受到這個的啟發,決定把之前處理類似問題的經驗總結下來,希望對大家有所幫助
一、指標上線
一個指標上線前,要明確指標的各種元數據信息,其中包含指標中英文名稱,指標類型(原子、派生、復合),指標等級(業務、安全),指標分類(業務、主題、標簽),指標負責人(DS、DE、業務)和指標口徑(業務、技術)。以上都是最基本的指標元數據信息,實際在業務落地中,可能還會配置支持查詢的數據源、指標支持的維度等。
這些的核心是要保證指標的規范和標準,具體的操作方式和需要注意的點舉例如下:
- 指標命名:指標命名要有遵循一定的規范,避免出現有的指標用中文“安卓”,有的指標用英文“Android”,這樣的情況
- 默認含義:一些默認的含義要提前預定好,避免出現歧義。例如時間指標單位有的是分鐘有的是秒,如果默認是秒,那指標單位是分鐘的時候就需要進行特別標識。再比如曝光默認是指只要1個像素曝光就算,如果是有效曝光(不同情況下,有效曝光的定義也可能不同)要特別說明。
二、指標使用
指標上線之后,就要開始對指標各方面的情況進行例行監控,發現問題及時處理,以免影響業務。
1. 使用量監控
對指標的使用情況進行分時間段監控,例如配置近30天、90天、180天指標的使用情況的報表,最好包含指標中英文名稱、業務負責人、數據負責人和被引用次數等信息。如果之前沒做過指標的清理下線,并且業務也發展了一段時間,可能會發現多數指標使用的頻率非常低甚至都沒有使用(之前出現過近30天,70%多的指標都沒有被使用),這些指標是應該被識別和處理的。
2. 一致性監控
一個指標的業務口徑往往可以明確且唯一,但技術口徑可能會存在多個。例如一個指標在Hive中有,同時也在StarRocks中有,正常情況下不同數據源不同表中出來的數據應該是相同的。但實際在使用過程中,難免會出現數據對不齊的情況,這時就需要檢查哪個數據源出現了問題,保障不同數據源不同表產出的同一個指標的數據是一致的。
三、指標下線
隨著業務的發展,指標覆蓋的場景越來越多,粒度也往往會越來越細,同時一些業務口徑也會進行調整,這樣就會使得指標的數量會越來越多。指標數量的膨脹不僅浪費存儲資源,也會在使用時造成更多的困惑,我們不得不花時間去區分一些相近的指標,進而確認具體使用哪個指標。
基于這樣的情況,我們要形成指標下線的流程,具體觸發下線的標準可以基于業務和數據量決定。如果現在業務在初期,數據量也并不大,可以把下線閾值放大一些,如果現在數據存儲壓力大,或者在使用的時候相近的指標已經造成比較大的困擾,這時可以把閾值設置的小一些。
當確認一些指標要下線時,不能簡單粗暴的刪除,這里主要要考慮兩個方面。
一是因為有的指標可能業務只是暫時不用,其實以后還會用到。例如有些指標只在階段性評估時使用,這樣就造成使用間隔比較久,但確實是需要使用的。
二是還可能存在一些對當前指標的依賴,如果刪除會造成一些報錯。例如有的報表使用了該指標,刪除后可能會造成報表整體異?;虿糠之惓?。同時一些復合指標使用了該指標,例如ctr = 點擊數/曝光數,如果刪除了曝光數,ctr也會出問題。
結合具體的業務情況,具體處理的方案有很多,這里提供一個之前使用的方案共大家借鑒:
- 業務溝通:和業務進行溝通,明確指標是否還需要繼續使用,如果反饋不需要進行第二步
- 指標下線:對指標進行下線處理,下線意味著不能再基于指標新增報表和指標,但之前使用到指標的地方不受影響,還可以進行進行查詢。這一步相當于關閉入水口。
- 指標刪除:對使用到下線指標的地方進行刪除或者替換,完成后對指標進行刪除,刪除前最好使用郵件或者群聊的方式周知相關方
上面聊到的都是具體處理問題的方案,但更重要的是方案的執行,要讓大家都嚴格按照一套規則去做事,其實有的時候更難,后面有機會再詳細聊聊如何推進落地。
本文由 @暮雪云然 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!