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