一、什麼是名額
來自百度百科的定義：名額是說明總體數量特征的概念及其數值的綜合。
綜合資料大V的定義：針對某一具體事物或行為進行量化描述的數值。
上面兩個定義可能都不是特别的好了解，看一下下面的2個例子，會更形象一些，9.96億的GDP，4982億的GMV，這些就是名額。當别人問一下平時看哪些關鍵名額時，隻要交流具體名稱即可。
在上面直接講“9.96億的GDP，4982億的GMV”這一串數字的時候，我相信大家一定是有疑問的。這裡我們開始引入“次元”概念。
二、什麼是次元
次元是名額的屬性或者特征，同時也是名額的必要定語。先看下圖，9.96萬億如果加上2019年和江蘇省這兩個屬性，是不是就更加明确和有意義了？
是的，2019年是時間次元，江蘇省是地區次元，天貓是平台次元。時間次元從低層到高層包括日、周、月、季度、年度等。地區次元從低層到高層包括區/縣、市、省、國家等。當然還可以根據自己業務需要重新定義和劃分。
三、什麼是好的名額
因為名額是名額體系的關鍵，有必要強調一下什麼是好的名額，為後續建設名額池打下基礎。
- 準确性 ：一個名額最要的就是能否準确的進行統計，如果這點滿足不了，其他一切免談，否則隻會搬起石頭砸自己的腳。
- 可比較性：是指有次元可比較，比如同期比較，不同地區比較，如果沒有比較，名額也沒有意義。
- 業務指導性：當一個名額發生異常變動，對營運下步的執行沒有任何指導意義的時候，或者說還是按照之前的方式繼續執行的時候，這個名額就是沒有指導性的，可以直接放棄。
- 簡單易懂：如果無法一個名額無法快速的讓人了解，運用效果一定是差強人意。
名額管理的痛點問題
1. 同名不同義
名額名稱相同，統計口徑不一緻，缺少命名規範限制。
不同業務僅從自己部門出發，缺少全局視角，如财務口徑的營收要嚴格按照嚴謹的邏輯計算實收實付的每一分錢，而産品/營運端則更多考慮轉化效果，但在各自的KPI監控報表中，都把名額命名為營收。
2. 同義不同名
名額統一邏輯一緻，但不同産品命名不一緻，不同階段、或不同業務方/産品經理對名額命名不同，導緻在不同資料産品頁面，同一名額不同名。
3. 口徑不清晰
隻是同義詞再複述一遍，如活躍使用者數：通路使用者數。
4. 命名難了解
表意不清模棱兩可，或過于專業化僅名額建立人才可以懂。例如轉化率名額，有創單轉化率、成單轉化率，直接叫轉化率可讀性就非常差。
5. 邏輯不準确
名額口徑描述有誤，例如UV名額，口徑描述為“按照裝置ID去重”，實際上不同平台去重邏輯并不一緻，如微信小程式按照UnionID去重、APP按照DeviceID去重，PC和H5按照loginkey去重。
6. 資料難追溯
資料産品名額資料來源缺少直覺的鍊路追蹤能力，名額資料異常問題排查通過翻代碼去看資料來源，路徑長、耗時久，早上業務回報名額問題，排查出結論後可能一上午就過去了。
7. 資料品質差
名額管理常見的問題綜合在一起，往往會導緻業務對資料名額的信任度大打折扣，發現資料波動後，第一反應是先和資料部門确認資料是不是有問題，而不是去考慮業務上有何變動。
四、名額管理平台
名額化管理的概念很多年前就存在，各個網際網路公司都在建設自己的管理平台，學習了很多關于名額管理系統建設的文章會發現，做的事情大同小異。主要是圍繞名額管理的痛點問題，以阿裡的OneData理論為方法論依據，相同的事情隻要做一遍，剩下的是提供産品化的解決方案，讓名額建設、名額複用更加的規範和高效。
下面是名額管理平台産品功能的整體結構：
1）名額清單
目标：名額業務中繼資料、技術中繼資料資訊查詢和檢索，線上、共享式的名額字典，友善使用者快速找到目标名額，确定統計口徑，申請權限，直接複用資料，提供一站式名額應用服務。
2）新增名額：名額開發人員直接進入名額編輯頁面，其他角色進入名額需求申請彈窗。開發者角色需要填寫名額的業務基礎資訊，并綁定資料源。
3）名額應用：名額經過分析/産品驗證通過後，即可在名額字典清單中檢視。
名額可以輸出到其他資料産品，由系統拼接每個名額和應用方式對應的查詢SQL，生成API接口，應用端每次隻需要傳入名額辨別、Where條件（篩選條件）、GroupBY字段（次元），即可擷取對應名額和次元的資料。
五、總結
上面我們重點介紹了一下名額管理平台裡面的核心功能，即名額的錄入、定義、口徑維護、名額查詢和應用場景等。實際上，一個完整的名額管理平台還會有對次元的管理、詞根的管理、資料集的管理等功能，當然了，系統的基礎功能，例如權限管理、稽核流程等功能也是必備的。整體來說，在企業内部，名額管理平台使用起來較為容易，主要目标還是對次元、名額進行規範化的管理，保障資料口徑的一緻性。