編輯導語：作為數據產品經理，與數據打交道是必不可少的事項。搭建數據指標體系，一方面有助于數據產品經理根據數據縷清產品設計思路，另一方面也有助于推動團隊理解與后期產品落地。本篇文章里，作者總結了構建數據指標體系中的注意事項，一起來看一下。

構建指標體系可以說是數據產品經理的「基本功」，在工作當中總要和各種各樣的指標打交道，這篇文章聊聊在做指標設計的時候遇到的麻煩、解決的方法，對容易忽視的問題進行了重點標注。

文章的整體構架如圖：

一、數據指標體系概述

1. 「自下而上」理解「單個指標」的定義

在介紹如何構建數據指標體系之前，咱們先看看「單個指標」通常都是怎么定義的，以交易環(huán)節(jié)中常用的指標“當日通過微信支付的用戶數量”為例，對指標結構進行拆解：

• 時間周期：用于明確時間范圍，如當日、近3日、近7日、近30日、營銷窗口期……
• 修飾詞：用于明確場景類型，如瀏覽、閱讀、點贊、收藏、設為最愛……
• 原子指標：不可再拆分的核心表述，如總時長、文章數量、支付金額、下單筆數……

「自下而上」的應用方式：

幾乎所有的指標都可以依據上述的方法進行拆分，工作中我會使用它做兩件事情：

1. 在指標設計的初期，快速地頭腦風暴幾個指標demo，便于后續(xù)和業(yè)務人員更具象地溝通討論，提升效率；
2. 在指標設計交稿之前，復審指標有沒有拆分不到位、遺漏的情況，盡可能地減少二次開發(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é)議。