作為數據產品經理,該如何搭建數據指標體系?

本文面向互聯網行業讀者,包括但不僅限於產品運營同學。主要講如何搭建企業內部數據指標體系,為什麼需要、如何構建、具體怎麼做?希望對大家有所啟發,個人認知有限,歡迎隨時探討。

數據產品經理,除了“產品經理”應該所具備的如「溝通/原型/文檔/項目管理」等基本技能外,還應該具有精於“數據”的核心專業技能如「數據認知/數據技術/數據平臺/數據分析/搭建指標體系」等。而“搭建數據指標體系”是其中最為重要的,將直接影響數據「產生→處理→存儲→計算→應用」的全流程,也將影響數據平臺產品的系統性、穩定性和擴展性。

一、為什麼需要指標體系?

1.1 什麼是指標?

通常我們講述的指標是指將業務單元精分後量化的度量值,譬如「DAU」「訂單數」「金額」等。當然,原子指標還會基於維度、修飾詞、統計口徑而構建出派生指標。指標的核心意義是它使得業務目標可描述、可度量、可拆解

1.2 指標不成體系會怎樣?

  • 從業務視角看

經常碰到的一種現象是

業務上線了之後發現數據不夠用,缺指標或缺維度。隨之而來的便是數據需求更改:添加指標、增加維度、增加各種五花八門的數據報表等,這一系列的需求變更和反覆迭代造成的苦果,會使得報表越發臃腫,數據參差不齊。業務同學分析具體問題時找數據變得越來越難,每天會消耗大量時間在不斷的尋找數據、核對指標的泥潭中。

  • 從技術視角看

基於需求的變更,業務團隊技術同學將需要重新去更改設計和開發埋點。數據團隊技術則需要重新採集、清洗、存儲數據;更為致命的是,若在原有的監控報表上增加指標或維度還會需要:1)在原有的數據存儲結果表上動刀,增加存儲列等 2)數據計算SQL邏輯更改 3)數據回算 4)結果展現邏輯更改;這一系列下來不僅耗費人力物力,同時實現本身週期也會更長,反饋效率低下。

1.3 指標體系化後能不能解決?

一個好的指標體系設計,不能說可以規避掉百分百的問題,但至少讓問題出現時各方臨危不亂。

首先,業務同學需要對自己的業務有一個大概的預判,譬如:在整體的業務里程碑上什麼時間點會有哪些策略動作,對應的業務體量會是多大。與此同時也提前去預知大概會監控哪些指標,從哪些維度拆解等。

其次,在有了初步預判之後與團隊技術溝通,與數據團隊溝通,儘量讓各方信息對稱。這樣的好處是我們能儘量提前將指標體系設計得不重不漏、條理清晰。同時技術團隊也會有所準備,在做數據底層設計時多去考慮其穩定性、擴展性等。

1.4 指標體系化的本質

體系化本質是將數據指標系統性的組織起來。具體會按照業務模型,按標準對指標不同的屬性分類及分層;當然,不同的業務階段、不同業務類型會有不同階段的劃分標準。那麼,我們該如何依據現有業務去搭建指標體系呢?

二、如何搭建指標體系?

2.1 明確業務是什麼

在搭建指標體系之前,需要明確自己的業務是什麼?公司整體的目標是什麼?在產品實現上,如何幫助用戶解決問題。譬如像電商C2C企業,業務本質上要解決的是需求「匹配」和「匹配效率」的問題,是一個不斷豐富供給和滿足需要的過程。目標上會去追求實現更多用戶的雙邊關係需要,對應到數據去看會衍生出「DAU」「訂單」「GMV」等戰略指標。下面將會以“電商C2C”為例,從「業務整體大盤」和「業務子單元」拆分講解數據指標體系的構建方法。

2.2 按業務大盤拆解

根據企業戰略目標,按照業務大盤的方式拆解數據指標體系,在業內有個有名的方法論AARRR(也叫海盜指標法),整體的拆分邏輯是「獲取→活躍→留存→營收→傳播」感興趣的朋友可以去谷歌搜一搜。這個方法論的特點是比較系統和籠統的拆解了精益創業中的增長模型,不過在對應到現實業務上應用時,仍會有些讓人不知所以。儘管如此,我們依舊可以在此基礎上進行改良,進行基於自身業務本地化之後的擴展延伸。

2.2.1 用戶實現需要的路徑

我們先對自身業務模式進行拆解,畫出業務模型流程圖。觀察其在業務主流程上,不同階段實現用戶側買家和賣家需求時,用戶會做什麼、產生哪些數據、我們需要監控哪些數據。如下圖,我們得出兩點:

1)無論買家還是賣家,在整個業務主流程上的動作比較相似

2)主流程中認知、激活註冊、行為、溝通、交易、售後六個階段,可依據階段的差異性進行數據分類

作為數據產品經理,該如何搭建數據指標體系?

2.2.2 數據還原業務真相

通過上一步的拆解,我們基本可以摸清楚,用戶在實現需要的路徑上會產生哪些數據,這些數據將會為我們還原業務真相:

1)認知階段:市場渠道相關數據,品牌廣告數據。如:渠道新增、渠道DAU、渠道留存、渠道轉化、渠道ROI等

2)激活註冊:應用激活量、激活註冊轉化率、版本分佈、機型覆蓋率等

3)關鍵行為:用戶行為數據,如:發佈商品、搜索、瀏覽商品、收藏、添加購物車等

4)溝通:留言、私信、電話溝通

5)交易:下單、支付等

6)售後:

交易仲裁、申訴投訴、催單等

2.2.3 建立大盤指標體系

基於不同階段需要觀察指標的不同,結合海盜指標法勾勒出業務數據的關鍵漏斗。再加上整體概況數據、「用戶/商品/訂單」核心指標實時數據,我們就能夠對「業務大盤」有粗粒度的、相對完善的監控。

2.3 按業務單元精分

有了業務大盤之後,我們對「這個業務做了什麼?我們拿到了什麼數據?」有了大致瞭解。但對於企業來講更為重要的是,需要去考慮兩個問題:

1)為了解決用戶在不同業務環節中的問題,企業應該配備什麼樣的團隊去解決?

2)該如何通過不同的“第一關鍵指標”考核不同的團隊?

2.3.1 企業如何介入

相對應的,我們通過對用戶實現需要的路徑拆解,也拆解了企業在不同階段需要配備哪些不同的團隊,不同團隊間既獨立又相互需要,但整體上都是為了實現業務閉環而組成。具體如下:

1)認知階段:需要配備的團隊是渠道市場部、品牌市場部

2)激活註冊:基礎體驗部、其他垂直業務部

3)關鍵行為:搜索推薦團隊、基礎體驗、風控、垂直業務部

4)溝通:與通信及推送相關的架構部、運營部、風控部、公關部

5)交易:交易中臺、運營部、財務部

6)售後:客服部、風控部、公關部

作為數據產品經理,該如何搭建數據指標體系?

2.3.2 第一關鍵指標

在《精益數據分析》一書中,“第一關鍵指標”指的是當前階段無比重要的第一指標,同時也指出了在創業階段的任意時間點上應該且只關注一項重要指標。這套理論在我們去考核不同團隊的時候同樣有借鑑意義,公司當前階段的“第一關鍵指標”拆解到不同部門之後,就成了各部門的“第一關鍵指標”,也是團隊的考核度量(OKR或KPI)。通過調研不同部門及業務單元,他們基於自身的業務、基於考核關鍵指標應該去關注哪些數據呢?

舉例(下圖):在認知階段最相關的部門是渠道部和品牌公關部。如果他們的目標是“如何通過更少的錢獲取到更多的新用戶”,那麼關鍵指標可以認為是「新增用戶數」「ROI」,再按照“指標*維度矩陣”的方式對關鍵指標進行拆解。其他部門的關鍵指標也可以照此方式抽象拆解,方法類似,不再逐一列舉

作為數據產品經理,該如何搭建數據指標體系?

三、具體怎麼做?

3.1 明確關鍵指標

通過上文的描述,無論是企業整體概況,還是某個業務單元的考核目標。我們都可以找到其在當下業務階段的關鍵指標,諸如:DAU、新用戶數、支付訂單數、新買家數、新賣家數等。下面以「支付訂單數」舉例。

3.2 指標體系設計

需要將「支付訂單數」進行拆解,按不同的維度(觀察指標的視角)進行下鑽,具體需要哪些維度也會因為企業產品、業務模式的不同而不同。支付訂單數大致可以從六個維度拆解:

1)終端:按訂單實際支付訂單的場景終端進行拆分,分端內/端外、PC端、小程序端等。一旦某個終端的支付抖動厲害,可以立即發現定位問題

2)渠道:按用戶認知企業產品,下載應用的渠道拆分。也可依據需要拆解得更細,進一步提升監控敏感度

3)訂單來源:電商行業裡,訂單來源常常需要重點關注。不同的運營活動、客戶端版本策略都將直接影響搜索、推薦、列表頁等來源的訂單量波動

4)訂單類型:按照訂單類型拆分,主要是儘可能的去感知促銷或紅包等運營手段對用戶支付的影響,這塊通常也會因為直接涉及到促銷紅包成本等方面而拆得足夠細緻

5)商品品類:這是商品自身的屬性,不同商品品類的訂單波動往往受到垂類運營活動、季節、外部環境、競品等因素的影響

6)應用版本:按客戶端應用版本拆分,有便於迅速找到產品在升級更新時有可能會對支付訂單帶來的問題

作為數據產品經理,該如何搭建數據指標體系?

3.3 設計埋點收集

指標體系設計完成後,我們確定了數據收集的邊界。根據不同維度場景下需要的數據,通過埋點事件模型設計數據採集方案,也可以直接從關係型數據庫中拉取非日誌類數據,最終同步到數據倉庫中。這其實是一個業務驅動指標設計,再驅動數據收集的過程。

3.4 統計與應用

有了基本數據之後,依據業務指標定義確定數據的統計邏輯,最終計算結果可視化到報表系統中,供日常離線/實時監控使用;也可以依據數據倉庫中存儲的用戶、商品、訂單等信息進行數據分析、挖掘。

3.5 驗證指標體系設計的合理性

指標體系設計是否合理,往往也是一個不斷被挑戰,然後不斷優化改進的過程,下面列舉幾個驗證指標設計合理性的關鍵點:

1)可執行可描述:所有設計出來的指標應該可被執行,也應當可被業務語言和技術語言描述

2)完整性:可依據金字塔等原理,枚舉指標和維度,不重不漏以保證完整性

3)優先級:按優先級確定哪些維度下的哪些指標需要優先解決,以保證執行效率

數據指標體系設計流程:

作為數據產品經理,該如何搭建數據指標體系?

四、需要注意的問題

4.1 是否剛開始,就需要設計一套大而全的方案

不需要。業務還在摸索階段,量級還沒起來的時候設計大而全的方案不僅耗費人力,同時對計算、存儲資源也是較大的損耗。但整體設計要有預見性,業務團隊與數據團隊時刻都需要保持信息對稱

4.2 如何進行需求管理

業務需要推動需求管理 :

)確定優先級

2)保證輸出效率

3)迭代反饋和修正

4.3 指標的生命週期

數據指標服務於業務,也會受到業務變動的直接影響。在一個業務變革飛速的時代,通常半年一年業務本體便發生質變,隨之原有的指標設計便不再適合,也不再需要。數據產品經理要時刻保持敏銳的業務嗅覺,週期性調研數據指標的使用反饋,再去做好指標自動化下線、計算任務暫定等工作。不斷釋放優化計算存儲資源,從而保證資源投入產出比最優。

4.4 兵無常形,量體裁衣

以上所說的,不一定適用於你

五、後記

求知若飢,虛心若愚;從知道到懂得是一個漫長的過程,求索也很艱苦,但又怎樣呢?人總要成長呀。


分享到:


相關文章: