知識星球解決口徑對不齊問題的關鍵點之一，便是：指標命名。
在簡單的業務場景中，抓住以下幾點，指標的命名一般不成問題：
-
指標名稱“名副其實”和“簡潔易懂”
-
遵照一定的行業慣例或者規範（如財務指標、電商經營指標）
當業務規模大，相似的職能線多，相似的部門多了後，資料對齊的難度陡增（這一定程度上是組織架構的不合理的體現，但本文不對此展開討論，畢竟架構都是各有利弊）。如何讓指標命名規範，變成為了一個大問題。我們分兩步來解決這個問題。
-
一、解析一個指標的天然構造
如上圖，每個資料指標，其實都可以分解為“業務主題+限制條件+計算維度+指標名稱”的結構。
業務主題，可理解為指標應用的業務範圍。這裡可以是具體某個業務部門，比如市場部；某個專案，比如客戶留存提升；某種職能，比如質控、KPI、資料研發等；甚至是某個分析師名字，比如404。業務主題，理應能幫助指標閱讀者迅速理解這個指標的來源。
限制條件，即是指標計算時需要處理的某些必要條件（不做處理指標會脫離業務意義）。對於分析師來說，更直觀的理解是SQL裡面的WHERE條件。比如，app活躍使用者計算時只計算登陸時間在1分鐘以上的使用者數；網站註冊轉化率計算時剔除爬蟲訪問；電商客單價計算時剔除大促訂單；外賣單量計算時限制即時單等。
計算維度，即指標做某種維度切分後進行的彙總。比如城市、時段、區域等。這點是可選項。限制條件實質上也是某種維度，但我建議分開理解。限制條件是每個指標計算時必須要考慮的，而維度並不是。
最後是指標名稱，要求名副其實且簡潔易懂。
-
二、由構造形成命名
認識到指標名稱的構造，命名也就不難了。將各個結構進行羅列並用某種字元連線後，就是一個清晰的指標名稱。我個人就比較習慣用“-”，如“資料研發-去爬蟲-上海-獨立訪客數”。
另外，每部分結構中，有時會同時出現多個條件，若是交集，建議用“-”符號連線，若是並集，用“&”符號連線。
但是問題來了，每個指標名稱，都要改寫4個結構，名稱就會很長，應用起來不方便。所以，我的建議是，除了業務主題外，其他結構都是可以設定預設值，進而在名稱中隱去，使得指標名稱形成“主題-名稱”的簡寫形式。當然，預設值的說明一定要清晰。
當某些場景下（資料產品開發、視覺化呈現等），業務主題加名稱的形式已然過長，可只保留名稱，而將業務主題變成註釋形式另外展示。
總結一下，指標名稱，本質上有全稱和簡稱兩種形式，普遍應用簡稱，而使用者心裡需明白全稱。
補充一點：“限制條件”、“計算維度”的預設值，應當取最普遍的情況，讓資料使用者的理解成本降到最低。比如，活躍訪客數的計算，大家普遍認知是剔除了爬蟲訪問，那麼限制條件隱去的預設值便設定為此。當然，一定的宣導不能忽略。
給一個我們現實業務的樣例：
全稱，質控-全國-直營-平臺單-即時單&預訂單-組織運力&眾包運力-全標品-全維度-有效完成率；
簡稱，質控-有效完成率。
本文所提出的命名方式，正在試驗階段，大規模應用能否實現，還需要驗證。希望這樣的思路能給你帶來一些啟發，也許就能設計出一套更合理的方案。
END
版權宣告：本號內容部分來自網際網路，轉載請註明原文連結和作者，如有侵權或出處有誤請和我們聯絡。
關聯閱讀：
原創系列文章：
資料運營 關聯文章閱讀：
資料分析、資料產品 關聯文章閱讀：
