(文章始發(fā)個人公眾號：川術盖溺；歡迎關注)
你有沒有遇到過這樣的情況：不同的數(shù)據(jù)報告或產品中，相同的指標名稱锯玛，卻對應著不同的數(shù)字和不同的計算口徑咐柜？相信大部分人會點頭。我所在的環(huán)境中攘残，這個問題已然成為頑疾拙友，我們正在努力！解決該問題的關鍵點之一歼郭，便是：指標命名遗契。
在簡單的業(yè)務場景中，抓住以下幾點病曾，指標的命名一般不成問題：
- 指標名稱“名副其實”和“簡潔易懂”
- 遵照一定的行業(yè)慣例或者規(guī)范（如財務指標牍蜂、電商經(jīng)營指標）
當業(yè)務規(guī)模大，相似的職能線多泰涂，相似的部門多了后鲫竞，數(shù)據(jù)對齊的難度陡增（這一定程度上也會是組織架構的不合理的體現(xiàn)，但本文不對此展開討論）逼蒙。如何讓指標命名規(guī)范从绘，變成為了一個大問題。我們分兩步來解決這個問題是牢。
一僵井、解析一個指標的天然構造
如上圖，每個數(shù)據(jù)指標驳棱，其實都可以分解為“業(yè)務主題+限制條件+計算維度+指標名稱”的結構。
業(yè)務主題驻债，可理解為指標應用的業(yè)務范圍。這里可以是具體某個業(yè)務部門合呐，比如市場部；某個項目，比如客戶留存提升源织；某種職能，比如質控缘屹、KPI侠仇、數(shù)據(jù)研發(fā)等；甚至是某個分析師名字互亮，比如404余素。業(yè)務主題，理應能幫助指標閱讀者迅速理解這個指標的來源威根。
限制條件视乐，即是指標計算時需要處理的某些必要條件（不做處理指標會脫離業(yè)務意義）。對于分析師來說留美，更直觀的理解是SQL里面的WHERE條件。比如独榴，app活躍用戶計算時只計算登陸時間在1分鐘以上的用戶數(shù)奕枝；網(wǎng)站注冊轉化率計算時剔除爬蟲訪問；電商客單價計算時剔除大促訂單症歇；外賣單量計算時限制即時單等。
計算維度忘晤，即指標做某種維度切分后進行的匯總。比如城市凄吏、時段闰蛔、區(qū)域等。這點是可選項序六。限制條件實質上也是某種維度，但我建議分開理解随抠。限制條件是每個指標計算時必須要考慮的繁涂，而維度并不是。
最后是指標名稱椭懊，要求名副其實且簡潔易懂步势。
二、由構造形成命名
認識到指標名稱的構造盅抚，命名也就不難了倔矾。將各個結構進行羅列并用某種字符連接后，就是一個清晰的指標名稱丰包。我個人就比較習慣用“-”壤巷，如“數(shù)據(jù)研發(fā)-去爬蟲-上海-獨立訪客數(shù)”。
另外寄症，每部分結構中，有時會同時出現(xiàn)多個條件有巧，若是交集，建議用“-”符號連接男图，若是并集甜橱，用“&”符號連接。
但是問題來了渗鬼，每個指標名稱譬胎，都要覆蓋4個結構命锄，名稱就會很長，應用起來不方便镐侯。所以驶冒，我的建議是，除了業(yè)務主題外崇猫，其他結構都是可以設置默認值需忿，進而在名稱中隱去，使得指標名稱形成“主題-名稱”的簡寫形式涕烧。當然汗洒，默認值的說明一定要清晰。
當某些場景下（數(shù)據(jù)產品開發(fā)痹扇、可視化呈現(xiàn)等），業(yè)務主題加名稱的形式已然過長鲫构，可只保留名稱，而將業(yè)務主題變成注釋形式另外展示包晰。
總結一下炕吸，指標名稱，本質上有全稱和簡稱兩種形式树肃，普遍應用簡稱瀑罗，而使用者心里需明白全稱。
補充一點：“限制條件”劣像、“計算維度”的默認值摧玫，應當取最普遍的情況，讓數(shù)據(jù)使用者的理解成本降到最低屋群。比如坏挠，活躍訪客數(shù)的計算，大家普遍認知是剔除了爬蟲訪問癞揉，那么限制條件隱去的默認值便設置為此。當然柏肪，一定的宣導不能忽略芥牌。
給一個我們現(xiàn)實業(yè)務的樣例：
全稱，質控-全國-直營-平臺單-即時單&預訂單-組織運力&眾包運力-全標品-全維度-有效完成率谬俄；
簡稱，質控-有效完成率屎蜓。
本文所提出的命名方式钥勋，正在試驗階段，大規(guī)模應用能否實現(xiàn)扼劈，還需要驗證菲驴。希望這樣的思路能給你帶來一些啟發(fā)，也許就能設計出一套更合理的方案赊瞬。
