一文幫你更好地理解指標

lee
0 評論 3510 瀏覽 13 收藏 14 分鐘

編輯導讀:產品每天在使用,數據在不斷增長,我們需要對產品的表現進行量化,建立一個精良的指標體系,以幫助我們做出科學的決策。如何搭建指標體系呢?本文作者從自身工作經驗出發,對此展開了五個維度的分析,一起來看一下吧。

隨著市場競爭進入白熱化,越來越多的公司由原來的增長黑客轉變為精細化運營,不管是增長還是留存,我們都需要對產品的表現進行量化。

數據指標,就是量化信息的別名,科學的決策離不開構建精良的指標體系。

本文重點從技術視角,給大家介紹指標的定義和實現。文中會有部分簡單的 SQL 示例,文末會給到一些實用的參考資料。

01 一個例子講清楚指標的定義

小明看到自己喜歡喝的一款高端酸奶標價 8 元,他連忙拿了一瓶去買單。結果店員告訴他,本次活動第一瓶是原價,第二瓶才是 8 塊的半價 。

上面的例子中,單純一個數字,是沒有意義的,必須要相應的解釋,人們才能理解。“買滿兩瓶,第二瓶酸奶的單價是 8 塊”,這才是真正完整的指標。

用一個簡單的公式給出指標的定義:

指標 = 數字 + 解釋

其中解釋包含兩方面:業務上的解釋;技術上的解釋。

業務解釋通常是圖文,意在給指標使用者解釋指標從何處來,怎么算。

技術解釋通常是用程序語言定義的計算邏輯,比如用 SQL 語句定義人數為 count(user_id),均價為 avg(price) 。

其實理解了元數據,就能理解指標,大家可以參考文末的元數據文章。

02? 如何設定合理的指標

互聯網發展到現在,很多行業或公司都有了成熟的指標體系,而最初構建指標體系,都要圍繞關鍵指標(北極星指標)展開。

社交類產品,關鍵指標是 DAU ,因為社交產品的核心是希望更多人能更頻繁地用它溝通交流。

電商類產品,關鍵指標是 GMV ,因為電商平臺希望能承載更多的線上交易。

視頻類產品,關鍵指標是用戶觀看時長,因為這類產品的目的就是為了幫助用戶殺時間。

不同行業,業務不同,核心關鍵指標也不同。

而不同之中有相同之處:關鍵指標都能反映產品表現,且能衡量產品的直接或間接商業價值。

指標體系的構建,要基于業務展開,尤其是核心業務。基于核心業務流程,進行層層拆解,逐漸構建起企業的業務指標體系。

拿電商行業的 AARRR 漏斗模型舉例,每個業務階段,都會有相應的北極星指標。

想要構建科學的指標體系,必須花時間深入了解公司、部門的關鍵業務。通常來說,經營性業務指標是業務型產品經理重點關注對象。

不過,公司對人才的綜合能力要求越來越高, T 型人才的說法廣為流傳,產品經理也被越來越多地要求具備數據分析能力,所以了解下指標的管理與實現,對我們會有很大的增益。

03 指標該怎么管,要解決哪些問題

公司業務多,則指標多,如此多的指標,怎么管才好呢?

起初,很多公司會用 Excel 管理,構建一本“指標字典”,如果不明白某個指標什么意思,就去翻翻字典。畢竟,先上車后補票,讓業務跑起來最重要。

公司業務發展好,人更多了,離線 Excel 文檔不便于多人協同的問題就暴露了,在線文檔出現后,離線文檔逐漸被替代。

也有的公司也會用腦圖來管理指標,不過這一類的工具,都算作是在線文檔。但文檔內容還是差不多,大體如下:

因為數據通常都是存在關系型數據庫中的,所以定義指標時,也需要技術人員基于業務的數據模型給出技術口徑,即指標的計算方式。

統一的指標共享文檔,解決了指標業務口徑一致性的問題,但還有 2 個問題沒有解決:

  1. 業務口徑和技術口徑的關聯
  2. 技術口徑的復用性

先說第一個問題。假設系統中有一張用于記錄用戶登錄的記錄表,其結構如下:

起初,每日活躍用戶定義為每天登錄的用戶數,日活用戶數的取數SQL表達式為:

業務發展一段時間,日活指標的定義修改為“每日停留時長達到 1 個小時的用戶”。業務定義變了,技術定義也要隨之變動也會變動。假定有另一張用戶行為記錄表,結構如下:

那么日活用戶數的取數的SQL表達式為:

而作為產品的運營者,我們監測用戶活躍度,往往還會得到更細的數據,比如近 1 天活躍用戶數、近 7 天活躍用戶數、近 14 天活躍用戶數。

每一個業務口徑都對應著特定的分析條件,業務口徑可有修改其中的分析條件組合方式,所以會對應很多種具體的技術邏輯(比如 SQL 語句)。

而且,當指標的業務口徑變化時,技術定義為了保證數據的準確性,也要隨之變更。如果每一種組合都寫定一個邏輯,那么工作量是浩大的。

為了降低技術對業務支撐的難度,聰明的工程師們就想出了辦法:對指標進行分層管理。

04 指標,具體如何分層

如果你看過指標管理的文章或書籍,或者體驗過指標管理系統,那你肯定這個結論:指標要分層,通常分 2-3 層。

按照阿里的分法,指標有兩層:原子指標(有一個小中間層:衍生原子指標)、派生指標。按照華為的分法有三層,分別是:原子指標、衍生指標、復合指標。

當我們接觸一個新東西, 我們通常最先會看到演進的最終結果。如果我們忽視演進過程不去探究,會有一個問題,我們回答不清楚為什么是這樣。

上文其實已經給出了指標分層管理的背景,那指標到底為什么要分層?

答案就是為了方便復用和重新組合。

事實表中有三種字段:事實屬性字段、度量字段、維度字段。

原子指標的來源有三種:

  1. 對事實表中的屬性字段進行計數,比如count、count(distinct)
  2. 對事實表中的維度字段進行計數,比如count、count(distinct)
  3. 對度量字段進行聚合操作,比如求和、求平均值等

原子指標 +? 時間限定 + 業務限定(修飾詞) = 衍生指標

第一節中,我們知道指標是由數值和解釋組成。假設我們知道了一個數值的業務含義,接下來,我們就會關心這個數值從何而來,以及數值是怎么計算得出的。

而原子指標,就承擔了這樣的角色。原子指標定義了數值從哪里取得,如何計算。比如活躍人數,是從用戶登錄表根據對 user_id 進行計數而得來。也就是上面表格里面的 count (user_id)。

為了識別和區分,我們會對事物進行歸類。比如性別:男/女,時代:當代/近現代/古代,地區:國內/國外。

這些區分事物的“東西”,我們稱其為維度。維度還可以拆得更細,且不同維度之間是可以組合的。

阿里對派生指標的定義為:

衍生/派生指標 = 原子指標 + 時間周期 + 修飾詞

其中的時間周期,我們也可以理解為時間維度,因為大多數時候,我們業務分析上都是用的離散的時間值,比如近 1 天、近 3 天、截止當前等。

修飾詞,可以理解為不同的維度,或者是維度中特定某個值。比如地區維度,且維度值為北京。

抽象的東西,通過例子來理解:

近 1 個月北京市的活躍用戶數 = 活躍用戶數(原子指標) + 近 1 個月(時間周期) + 北京市(修飾詞)

將原子指標、時間周期、修飾詞、維度等分別定義出來,就好像樂高積木,工程師將最細粒度的標準化零件構建出來,并且設定好零件之間的組合規則,用戶可以根絕自身業務需求進行組合,組合完成后,系統自動生成對應的 SQL 語句。

一方面減少了重復勞動,另一方面,對某個原子指標進行改動的時候,其他依賴該原子指標的衍生指標對應的邏輯系統也會自動更新。

05 建設指標管理系統的認知層次

如果你同為數據平臺的產品經理,也要為公司建設指標管理系統,可以從如下三個層次進行認知突破。

第 1 層次:

掌握一些常識概念,了解基礎流程。

通過查閱各個競品,知道原子指標、派生指標、復合指標、業務限定等基礎概念,大概知道指標的需要哪些屬性(要是要做系統,可以先照貓畫虎)。

第 2 層次:

明白數倉分層,以及指標體系。

對數據倉庫(維度建模、分層)、業務數據庫(范式建模尤其是 3NF)、數據庫基礎(聚合函數和group by)、元數據等有一定的理解。

第 3 層次:

深入業務,服務業務,優化業務。

深入了解業務,知道業務方關心哪些核心指標,核心指標建設的優先級、怎么管、怎么運營,指標如何幫助業務部門解決問題。畢竟,數據價值最終要在業務上體現~

06 寫在最后

本人作為數據平臺產品經理,現在重點參與部分是數據中臺的指標系統建設,對于業務方的指標需求認知還有許多不足之處。

從我的視角出發,給有不同需求的小伙伴一些建議。

如果你是業務型產品(前臺),平時要負責產品的規則和玩法設計,需要觀測產品的各項用戶指標,那你應該側重掌握業務邏輯,定義運營指標,并拆解出業務指標體系。

如果你是平臺型產品(中后臺),要更多考慮是為業務賦能,降本增效。建議你熟悉掌握相關技術知識和底層概念,構建全面的技術認知,再深入了解業務需求。

學以致用,祝各位都能用好指標,管好指標,共同創建美好的數據時代。

 

作者:lee;公眾號:樂說樂言

本文由 @lee 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自?Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!