構建數據指標體系中踩過的坑
編輯導語:作為數據產品經理,與數據打交道是必不可少的事項。搭建數據指標體系,一方面有助于數據產品經理根據數據縷清產品設計思路,另一方面也有助于推動團隊理解與后期產品落地。本篇文章里,作者總結了構建數據指標體系中的注意事項,一起來看一下。
構建指標體系可以說是數據產品經理的「基本功」,在工作當中總要和各種各樣的指標打交道,這篇文章聊聊在做指標設計的時候遇到的麻煩、解決的方法,對容易忽視的問題進行了重點標注。
文章的整體構架如圖:
一、數據指標體系概述
1. 「自下而上」理解「單個指標」的定義
在介紹如何構建數據指標體系之前,咱們先看看「單個指標」通常都是怎么定義的,以交易環(huán)節(jié)中常用的指標“當日通過微信支付的用戶數量”為例,對指標結構進行拆解:
- 時間周期:用于明確時間范圍,如當日、近3日、近7日、近30日、營銷窗口期……
- 修飾詞:用于明確場景類型,如瀏覽、閱讀、點贊、收藏、設為最愛……
- 原子指標:不可再拆分的核心表述,如總時長、文章數量、支付金額、下單筆數……
「自下而上」的應用方式:
幾乎所有的指標都可以依據上述的方法進行拆分,工作中我會使用它做兩件事情:
- 在指標設計的初期,快速地頭腦風暴幾個指標demo,便于后續(xù)和業(yè)務人員更具象地溝通討論,提升效率;
- 在指標設計交稿之前,復審指標有沒有拆分不到位、遺漏的情況,盡可能地減少二次開發(fā)。
2. 「自上而下」構建「數據指標體系」
1)第一層:業(yè)務板塊
數據平臺往往面向的是公司/事業(yè)群的業(yè)務,會有多個業(yè)務板塊(新聞、視頻、電商、廣告等等),每個業(yè)務板塊服務的人群是不一樣的,關注的維度也就不一樣。類比于公司的組織架構一樣,在設計指標體系的時候,第一層可以按照業(yè)務板塊進行劃分。
2)第二層:業(yè)務子模塊
面向業(yè)務的進一步模塊劃分;以電商為例,可以有用戶模塊、商戶模塊、供應鏈模塊、支付模塊等等,它們有些側重于屬性特征(如商戶模塊)、有些側重于行為特征(如支付模塊),進行拆分后便于管理和維護,同時也方便后期與其他系統(tǒng)進行基礎信息共享。
3)第三層:業(yè)務環(huán)節(jié)
對用戶行為等進行拆解,以支付模塊為例,通過對全鏈路進行拆解,可以劃分為“提交訂單→支付→退款”等環(huán)節(jié)。
4)第四層:時間周期、修飾詞、原子指標
時間周期很好理解,重點說一下修飾詞,這個地方需要去深入理解業(yè)務,才能設計出合理的、對業(yè)務真正有幫助的指標。
比如支付環(huán)節(jié),會有“正常支付的、超時未支付的、多次支付失敗的、因余額不足導致支付失敗的、自動退款的”等等。這部分內容要和需求方(運營、業(yè)務產品經理等)進行深入溝通和確認,后面的建設步驟中也會有介紹。
「自上而下」的應用方式:
在和需求方大致溝通業(yè)務需求之后,在整體框架設計中可以采用這種方式對指標體系進行梳理:
- 便于縷清思路,避免遺漏大的模塊和環(huán)節(jié)(如果架構上有遺漏,很有可能大大增加后期的維護和重構成本);
- 便于后期數倉開發(fā)的人員理解需求,減少溝通成本。
二、如何說服各方配合搭建數據指標體系
之所以把這個環(huán)節(jié)單獨作為一節(jié),是因為數據平臺具有中臺屬性,最終是要服務于業(yè)務,爭取各方支持對于數據指標體系的建設質量和價值體現非常重要,有了好的開頭后面的事情才會順利。
當然這件事有時并不容易,但做到了的話,好處是顯而意見的:
- 有利于爭取資源。畢竟公司的研發(fā)資源是有限的,爭取到更多領導的支持自然有助于獲取資源,不然可能就是“這個需求,排期明年吧”,有再好的想法沒有資源能落地也很難受。
- 指標更系統(tǒng)化、更有業(yè)務導向,不會閉門造車。術業(yè)有專攻,數據產品經理不可能洞悉所有的業(yè)務環(huán)節(jié)和細節(jié),而產品經理和運營人員更了解產品的模塊、關心點和常見問題等,有大家的深度參與最終的效果才會好。
- 有助于體現數據平臺的價值,獲得各方的認可。從心理學上講,大家親自參與的項目,會更有認同感和使用的欲望,畢竟只有大家真正的把數據用起來,才能更好地體現數據價值。
那究竟怎么做呢,有一些小tips僅供參考。
1)需求側,抓住一切可能的機會輸出「數據指標體系能夠提升大家工作效率」的理念。
比如多個部門在一個活動上匯報的數據不一致,大老板詢問數據平臺的時候,你可以抓住機會,“如果作為指標統(tǒng)一起來,可以避免大家對指標定義不一致的問題,可以更高效地定位問題,更準確地反映業(yè)務發(fā)展情況……”
再比如搞一個營銷活動,運營人員找到你,想要一個用戶增長數據的時候,你可以向他介紹,“臨時增加這個指標需要多長時間,他可能需要比較滯后才能看到這個數據,但是如果在早期就已經做好了指標的設計,那這個時候就只需要場景遷移,時間會縮短XXX”。
老板認可了,執(zhí)行層的員工也理解了這個事情對工作的幫助,合作起來自然比較愉快。
2)研發(fā)側,除了輸出理念,還有一點非常重要,做一個「靠譜的中間人」。
- 指標框架和需求要清晰明了,最好能有demo示例,便于高效達成一致理解,減少反復;
- 要對業(yè)務環(huán)節(jié)有一定程度的了解,提升效率,不能只做“傳話人”,對研發(fā)提的業(yè)務問題不能一問三不知;
- 有同理心,在匯報中盡量體現各方的貢獻和產出。
三、搭建數據指標體系的步驟
以電商場景為例,搭建數據指標體系。
1. 需求調研
在數據指標體系的搭建初期,一定要與各業(yè)務方深入了解業(yè)務場景、業(yè)務流程和核心關注點。
需求調研的方式有很多,從定性與定量、主觀和客觀兩個維度來劃分,大致有四種方法:用戶訪談、問卷調查、可用性測試和數據分析。
簡單說就是蘇杰老師的“定性地說,定量地說,定性地做,定量地做”(具體的方式建議大家讀一下《人人都是產品經理》,很經典的一本書,上面很多例子讓人印象深刻)。
- 用戶訪談:可用于產品前期問題收集以及日常發(fā)現問題的原因探尋;
- 問卷調查:可用于確定具體問題的重要程度;
- 可用性測試:招募用戶真實使用產品,收集用戶反饋;
- 數據分析:通過分析大量用戶的真實使用情況發(fā)現問題。
注意這里需求方提出的有可能是「偽需求」,數據產品經理要有「打破砂鍋問到底」的精神。
舉個例子:
- 運營喵今天說“用戶投訴今天支付失敗率好高,能給我一個界面看到失敗率嗎,有情況我好及時發(fā)現?”
- 產品汪完全按照需求方的要求,這個功能很快上線了。
- 后續(xù)需求馬上又來了“能給我一個區(qū)分支付渠道的失敗率嗎?”、“失敗原因的數據有沒有呀?”
- 于是產品汪和程序猿又忙碌了起來,好不容易兩天后功能上線了。
- 運營喵感慨“平臺效率好低哦,這個需求提了好久了呀,怎么這次又要等好幾天”。
- 最終的結果就是大家都很疲憊……
其實可以一次性解決的問題,工作中可能要折騰很多次,究其原因,有部分原因是在需求溝通的時候沒有聊透。
如果在第一次,產品汪能夠了解到,發(fā)現失敗率高之后運營喵要定位是哪個渠道出了問題,再進一步需要知道是收單機構的問題還是賬戶機構的問題,更進一步定位失敗原因,他就可以給運營喵提出建議,”你的問題可以通過系統(tǒng)錯誤碼和業(yè)務錯誤碼進行定位”,從而設計一個由錯誤碼為底層數據的數據采集和處理流程,指標體系的可擴展性就強了很多。
下次運營喵發(fā)現問題的時候,就可以通過數據平臺的下鉆功能一層一層地定位問題了,效率提高了不少,同時也可以提升用戶體驗。
這種情況相信大家多多少少都遇見過,其實大家都沒錯,只是看不到”認知范圍以外的事情”。
- 從運營喵的角度:定位問題原因是很常規(guī)的操作呀,需要費這么口舌嗎;
- 從產品汪的角度:收到的需求就是”展示失敗率”,滿足需求了呀;
- 從程序猿的角度:早說是這個功能呀,浪費了好多時間,后面還有好多需求排著呢。
收到需求后不要馬不停蹄地就開干,盡可能地去挖掘用戶的真正需求,極致的數據產品經理甚至能根據需求背后的問題場景,籌備更具有建設性的解決方案,“比用戶更了解用戶”。
2. 分析業(yè)務流程,明確業(yè)務口徑,劃分優(yōu)先級
電商是零售交易模式的一種,一般圍繞“人”、“貨”、“場”進行指標設計。在場中的平臺運營環(huán)節(jié),大致可以分為“瀏覽→加入購物車→提交訂單→支付→評價”(實際中還有注冊/登陸、加入收藏夾、退貨退款、復購等眾多可能環(huán)節(jié),此處不做展開)。
每個流程都需要很多業(yè)務指標支撐后續(xù)的分析,這里舉幾個例子,后面如果有時間再詳細寫:
- 瀏覽階段:用戶瀏覽量、頁面停留時長、頁面有效瀏覽時長、直接跳出APP的用戶比例等;
- 加入購物車階段:今日加購的商品數、近3日加購的商品數,加購超過30天的商品數,加購商品中女裝占比,加購商品平均價格等;
- 提交訂單:提交訂單的筆數、提交訂單的金額、提交訂單的用戶數量、提交訂單的地區(qū)分布等;
- 支付:支付成功/失敗筆數、支付成功/失敗金額、支付成功/失敗用戶數、支付成功/失敗商品數、支付失敗率、多次支付失敗的用戶數量、主動取消支付的用戶數量等;
- 評價:商品好評率/中評率/差評率,有效評價率等。
明確業(yè)務口徑的時候,對于有閾值設置的指標(例如近7天每天都登陸APP的用戶數量),要確認閾值的合理性,因為這個閾值有可能是需求方拍腦袋定的,而后續(xù)修改其實可能非常麻煩。
常用的方法是對指標分布進行測算,和需求方一起通過分布情況選擇一個合理的指標。從實際情況出發(fā),如果類似的指標比較多,測算時間來不及的話,可以選定其中幾個重要的指標進行測算,至少保證核心指標的可用性。
數據產品經理還有一項很重要的工作就是「劃分優(yōu)先級」,因為工作中每個業(yè)務都有非常非常多的指標需要建立,而這些都是有成本的,所以需要綜合考慮性價比,圈定核心指標優(yōu)先開發(fā)。
3. 明確技術口徑,判斷可行性
數據產品經理需要將指標框架和指標業(yè)務邏輯給到數倉建模工程師,由他完成指標的計算。可以在業(yè)務指標的初稿出來之后(而不是定稿之后),就與技術人員進行溝通。
- 需要確認指標是否可計算,有些數據沒有進行埋點上報,底層數據層面就是不支持的;
- 可以大致溝通一下開發(fā)時間和排期安排。
適當提前介入技術口徑階段,避免“理想很豐滿,現實很骨干”的狀況發(fā)生。
進階一步,告知需求方那些目前無法實現的指標,在上線了哪些功能/埋點后可以獲取,如果大家判斷說這個指標確實很重要,那么下一步組會業(yè)務方產品經理看看要不要做這個功能。
4. 原型設計
指標計算后,一般在數據平臺上進行可視化展現(儀表盤和報表等),這很考驗數據產品經理對數據的理解,需要根據指標的含義選擇其合理的展現形式:
- 表格:一般用于展示明細數據;
- 柱狀圖:一般用來展示2-4主體的指標對比情況;
- 餅狀圖:一般用來展現占比情況;
- 折線圖:一般用來展現趨勢變化,查看一定時間段的數據波動情況;
- 地圖:一般用來展現熱點地區(qū)分布情況;
- 漏斗圖:一般用于展現環(huán)節(jié)比較多的流程分析,如“瀏覽→加購→提交訂單→支付 ”每一個環(huán)節(jié)的流失率;
- 桑葚圖:一般用于展現用戶行為路徑,如新增用戶在一段時間后變?yōu)闀T、活躍用戶、僵尸用戶等。
互聯網公司一般都有專業(yè)的「BI方向」的數據產品經理,還有UI設計師,既然這章主要講指標設計,那這部分內容后續(xù)再單獨寫。
5. 項目流程跟進(評審、數據開發(fā)、前后端開發(fā)、測試、上線)
數據產品經理需要推進產品的開發(fā)狀態(tài),一般的環(huán)節(jié)如下:
- 評審:組會向重要環(huán)節(jié)成員介紹產品的價值、功能和交互形式,演示demo,目的一是拉齊大家對產品的理解,提高效率;二是傾聽不同領域的專家意見,查缺補漏,及時發(fā)現問題,避免返工。
- 數據開發(fā):對接大數據開發(fā)工程師、數倉建模工程師。
- 前后端開發(fā):對接UI設計師、前端開發(fā)工程師、后端開發(fā)工程師。
- 測試:對接測試工程師。
- 上線:對接運維工程師。
測試環(huán)節(jié)最好拿部分「現有的數據」和「待上線產品的數據」進行校驗,增加準確性,因為有些指標計算比較復雜,測試環(huán)節(jié)可能會有遺漏,畢竟是上線前的「守門員」,建議多一層防守。
6. 跟進用戶反饋
產品上線「是服務的開始,而不是服務的結束」,接下來要長期跟進指標的變化,優(yōu)化指標的展現形式。當有新產品上線、業(yè)務模塊更新或新營銷活動上線時,數據指標也需要進行更新。
數據產品也是產品,雖然現在大多數企業(yè)還是內部使用,沒有對外賦能,但是也需要有合理的”運營“和“推廣”。公司內部可以通過編寫使用手冊、開展跨部門培訓等方式讓大家更好地把數據平臺“用起來”,也可以小規(guī)模鍛煉自己在用戶增長方面的能力。
在收集用戶反饋方面,不要被動被吐槽,要主動出擊:
- 通過后臺數據可以分析最近用戶的使用頻率、常用的操作、高頻訪問的指標、失敗的操作記錄等;
- 主動找運營、業(yè)務產品的同事面對面聊聊,問問他們的使用體驗和建議。
近期會集中更新一些之前的筆記,期待交流和批評指正。
本文由 @Amy 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
感謝分享!作者大大的這篇文章對我一個數據小白在最近搭建數據指標體系的時候實在太有用了!
另外想請教一下,關于時間周期和修飾詞的梳理,是所有模塊通用的,還是按照不用業(yè)務模塊梳理不同的時間周期和修飾詞呢?
抱歉這段時間比較忙,剛看見您的信息。在時間周期和修飾詞上,我一般是先根據業(yè)務進行拆解分析,然后對這些業(yè)務進行“合并同類項”,盡量讓絕大多數(大概80%)是通用的,一小部分(大概20%)是個性化的。個人理解:
(1)如果都做成通用化的,為了覆蓋所有需求,就需要“取并集”,勢必造成很多冗余指標,業(yè)務人員查找、使用指標的時候其實不是很方便。比如用戶行為分析,業(yè)務同事可能只需要以天為維度的數據;訪問并發(fā)量,可能是以秒為維度;這種情況下沒有必要為了“通用”而都使用秒為維度,徒增系統(tǒng)計算的負擔而沒有業(yè)務收益。
(2)在業(yè)務人員提出需求的基礎上,預留空間。還是以用戶行為分析為例吧,現在業(yè)務人員的需求是“計算用戶的日訪問量/購買量”,那我們在設計指標的時候就好能下探和擴展一層,比如“用戶一天中訪問/購買最活躍的時間段”,這也是一個和常用的指標(當然這個比較靠經驗啦),那我們在設計指標的時候可以考慮以“小時”為維度(畢竟除了考慮業(yè)務需求,我們作為“業(yè)務”和“技術”的橋梁,也要同時考慮到數據倉庫后續(xù)的改造成本)