|0x00 如何理解指標體系
講道理，雖然今天互聯網企業已經足夠的數字化，但看清楚公司的運行情況，依舊是一件很難的事情。看清楚，不僅包括看清楚企業的投入情況，也包括看清楚業務的運行情況。
比如，投入了幾百萬的預算，帶回來多少DAU的增長？這其中每個階段的轉化情況怎么樣？1/7/30天后留存的有多少？本次活動各個渠道的質量如何評估？當下的互聯網企業，很多決策可以說是“無數據不決策”，不論是運營對活動效果的分析，還是高層對商業走勢的判斷，沒有成熟的分析看板，臨時做需求是接不住的。
但本文，要講述的，是數據看板的靈魂部分：指標體系。
什么是指標體系？用一句簡潔的話闡述，就是“對業務有幫助的統計結果”，什么是有幫助？即“描述發生了什么”、“度量發生了多少”以及“拆解發生的原因”，從而為業務提供幫助。
關于指標的分類，個人傾向于兩種分類方式，一種是原子指標，不加任何修飾詞，比如PV、UV、訂單量；一種是派生指標，也叫復合指標，通過四則運算或修飾限定得出，比如平均交易金額、購買轉化率、近N天訂單量。
以下兩個圖是網上講指標最常用的兩個圖，這里供大家參考：
指標體系要做的，技術從不同的“維度”梳理業務過程，將零散的、有關聯性的指標，系統化的組織起來，通過數據看板或接口形式，提供給運營、算法等不同的業務方使用。對于使用指標體系的人來說，指標體系能夠把業務體系化的展示出來，提高發現問題、分析問題、解決問題的效率。
|0x01 如何設計指標分析
“指標體系”，代表的是對業務的分析思路。總的而言，大體有三個階段：
- 圈定業務目標；
- 建立分析模型；
- 統計及展示數據。
定義指標體系，首先且最重要的一步，是要與高層的戰略目標達成一致，不能“你說你的規劃、我玩我的數據”。在實際工作中，指標與KPI是強相關的，數據是提高績效的一種利器。
比如今年的電商業務，目標是提高收入，那么平臺的交易量就要上去，指標體系就要圍繞訂單量來展開；比如今年的企業業務，希望能夠獲得更多的潛在客戶，那么如何提高平臺的注冊用戶量，就是指標體系的設計目標……
其次，選擇合適的分析模型，常見的有OSM方法、PLC模型、AARRR等。
OSM是一種如何將大目標拆解到小行動的方法：
- O：目標——用戶使用產品的目標是什么？產品滿足了用戶的什么需求？
- S：策略——為了達成上述目標我采取的策略是什么？
- M：度量——這些策略隨之帶來的數據指標變化有哪些？
例如在云計算行業，OSM的拆分可以按照下面的示例進行：
PLC模型則是另一種常見的方法論，即產品生命周期理論，將產品分成了探索、成長、成熟和衰退四個周期。
- 探索：關注用戶的關鍵行為，比如PV、UV、轉化率等；
- 成長：關注用戶的留存情況，比如留存率、自傳播量等；
- 成熟：關注用戶的活躍與商業化，比如DAU、付費用戶數等；
- 衰退：關注用戶的流失情況，比如流失用戶數、召回量等。
根據業務形態不同，可以自己定義相關的指標，周期示意圖如下：
其他的如AARRR、RFM等，就不一一介紹了。
接下來，有了分析的目標，我們就需要把相應的數據統計出來，統計及展示數據，這里涉及到的就是數據建模理論/數據看板搭建等我們接觸比較多的內容。
但有一些不同的是，數據建模理論，通常是把數據的采集與指標的統計分開來，例如CDM針對業務過程做統計，而ADS才是面向各個分析體系做統計的，CDM與ADS的區別，就在于是否存在跨業務域統計的情況。關于這部分內容，可以參考之前的文章：《數據建模實踐》。其實分析問題的思路，或者說是“套路”，還是比較重要的，我們需要用報表的形式來展示統計好的結果，關于這部分內容，可以參考之前的文章：《數據看板的搭建思路》。
綜上，不論是做報表也好、搭指標體系也罷，都是分析問題環節中的一部分，需要工程同學來搭建平臺，需要數據同學來維護數倉，需要分析同學來定義思路，也需要運營同學來實現KPI。根本的根本，依舊是如何“提升價值、降本提效”，要么發現新的商機，要么自動化現有工作。
|0x02 指標管理方法
指標體系并不是說建好了，就可以直接用，同樣需要一些工作，來管理和解釋這些指標。
讓我們體驗一個具體的場景。
某次促銷活動中，運營同學希望統計爆款率，在分會場中，分子是專場中銷量超過20件的商品數，分母則是專場內的總商品數。
那么，爆款率 = 銷量超過20件的商品數 / 商品總數，按照會場劃分維度。
看起來沒什么問題，其實坑很多，比如：
- 為什么爆款是銷量超過20，有沒有分析師來分析下歷史專場的銷售分部情況？
- 如何定義“銷量”，是加入購物車量、下單量還是支付量？退款情況要不要考慮進來？
- 銷售的商品件數是按商品銷售的件數還是按照商品下SKU的銷售件數？運營不關心這個事，但是影響到模型的設計。
然后，還有其他的問題，比如我們統計的維度是什么？統計的周期是什么？這個指標有什么用？這個指標給誰用？
雖然是一個看起來很簡單的場景，但如果解答不好，不僅會產生非常多的數據返工情況，爭吵甚至投訴，也就在所難免。
再比如，以網約車業務為例，今天的收入下降了50%，為什么？
分析師經過一頓操作，解答到：受疫情影響，乘客下單量降低20%。但問題是，還有30%，不知道什么原因，因為指標體系沒有體現出來。經過又一頓的分析，發現接單率也降低了，但因為之前指標體系沒有做，于是臨時倒排需求就來了。
其實，并不是我們算的每一個指標，都有實際的意義，但每個指標，都需要投入實實在在的人力資源。這個時候，作為數據團隊，計算某個指標的投入產出比，以及所消耗的機器資源，就是一項必備工作。運營的工作要支持，但也不能亂支持，數據本身不管是存儲還是計算，都是非常費錢的。
這其實就是阿里的OneData方法論希望做的事情：統一口徑、減少分歧、準確衡量效果，但更重要的是，降低投入的成本。
在超大規模數據量 + 超大業務復雜度情況下，《阿里巴巴大數據實踐》這本書，才能看出一些門道來。
正常規模的公司，其實用不到復雜的指標管理方法。但“量變都會引起質變”，當數據表的數量達到千萬級別時，就需要專門的方法論來治理數據，以及相應的指標了。
我們通常把這些工作，稱之為“數據治理”。
因此，指標體系的管理方法，與數據治理類似，需要平臺來管理，也需要數據來維護數據。詳情見文章：《數據資產治理概要：用數據來治理數據》。
|0xFF 正確認識指標體系
很多人碰到“指標體系”四個字，都覺得是個不錯的東西，想要一個模板來實踐一下。
但，指標體系并沒有一個“放之四海而皆準”的模板，就像管理體系沒有具體的拆解圖一樣，不同的業務，對于指標的需求是不同的，而這其中的差異，就像管理一樣，需要日積月累的深刻洞察，才能做出匹配業務需要的體系。當然，像電商這種發展了很多年的業務，其體系相對成熟，照抄大公司的模板，不失為一種走捷徑的方法。
“指標體系”，難在管理上，而不是技術上。
這里捎帶提一句，在互聯網的從業者，對于很多問題的定義，其實是不同的，大家學的都是同一套技術，但并沒有一套標準來約束你怎么使用這些技術。像財務等一些學科，對于問題的定義和分析，都是有明確定義的，總賬、資產、負債、利潤，等等，不論你在哪個國家、哪個學校，學到的都是同一套知識。因為電商的興起，互聯網對于分析業務（電商、廣告等），衍生出了自己的學科，比如數據運營，分析問題的思路，是近些年才逐步成熟的。過去數據開發崗位比較熱門，是因為基礎的數據技術與分析體系不成熟，但最近這幾年的數據從業者，分析師崗位與算法崗位是大熱選擇，其趨勢也是在技術不斷成熟、分析體系不斷完善的大背景下，逐步的發展起來的。
從這個角度看，指標體系，雖然對外透出的是各種指標與報表，但其內在的核心，是對于一個行業成熟的分析方法，這些都是在歷年的積累中打磨出來的。久而久之，這些分析方法沉淀之后，指標體系的歷史使命，大約也就完成了。因此，不建議在這個問題上花費過多的精力投入，而應該扎根到細分的行業之中，打行業專家的牌。
當行業增長到天花板，過去電商游戲這種躺著賺錢的業務，逐步的被其他玩家所掌握時，我們會喊著：“狼來了”，每個人都在焦慮行業的未來發展；但自然界總是處在動態的平衡之中，這時候，一些新的機會，也就悄然冒了出來。
上一個時代，是“人人都是產品經理”的時代；這一個時代，是“人人都是數據分析師”的時代。
