編輯導語：幾乎所有的數據分析工作都會提到一個詞——“建立數據指標體系”，雖然這個詞對于大家來說并不陌生，但是如何具體的搭建，很多人還是一頭霧水的。今天，本文作者就和我們好好聊一聊數據指標體系如何從構思到落地。

一、數據指標與體系

1. 什么是數據指標？

指標是一個可以量化目標事物多少的數值，有時候也稱為度量，如：DNU、留存率等都是指標。

一個指標通常需要從多維度來分析指標構成，這就要求指標與多維度關聯支持多維度分析，如DNU就可以按照不同渠道查看各渠道流量大小，也可以按操作系統查看不同操作系統的人數，這里的渠道、操作系統就是維度。

2. 好的指標體系該是什么樣的？

指標體系就是將各個指標按照特定的框架組織起來，從不同維度梳理指標，梳理的過程也是對業務本質進行思考的過程。

一個好的指標體系應該有以下兩點性質：

1. 上能指引高層領導把控業務整體方向，下能指導業務人員落地執行業務目標；
2. 指標之間要形成閉環相互作用相互影響產生反饋，才能稱之為體系，以數據定位問題，再反向作用運營和產品，最終形成數據驅動產品設計及用戶運營的閉環。

二、如何搭建指標體系

指標體系的搭建分為兩大步驟：設計指標體系和落地指標體系，這兩大部分又可以拆成一些小步驟，我們先來看一張指標體系從設計到落地的整體步驟圖，下面再根據這張圖細分拆解其中的每個步驟是怎樣落地的。

1. 如何設計指標體系

1）需求來源

主要需求來源隨著產品生命周期而改變。搭建數據指標根據數據現狀分為初中后三個階段。首先要明確的是先有目標方案后再有數據指標，而不是憑空捏造出一些指標體系然后往產品上套。

• 在數據指標搭建初期以產品戰略目標為主，優先搭建北極星指標的全方位指標監控；
• 中期以業務驅動為主，搭建指標衡量現有業務，業務驅動直接獲取到的指標一般是二級指標，需要整合到指標模型里面去；
• 到了后期，此時各數據指標已經搭建的差不多了，是時候根據模型查缺補漏，搭建針對產品的指標閉環，通過數據來反向推動產品的迭代優化。

2）確定一級指標

一級指標其實就是反映產品在各個重要方面的運營情況怎么樣，把對用戶的運營當成一個流水線，圍繞著用戶生命周期即可挖掘到一些重要的一級指標并自然而然的形成閉環。

在眾多指標模型中我覺得AARRR模型能很好的概括用戶的生命周期，美中不足的是遺漏了用戶流失這一環節，個人覺得AARRRR比較能完整概括用戶生命周期，即Acquisition（獲?。?、Activation（激活）、Retention（留存）、Revenue（收入）、Referral（自傳播）、Recall（召回）。

圍繞這六大方面，可以拓展以下一級指標（只是舉例一些通用指標，具體的一級指標可根據具體業務進行定義）：

3）得到二級指標

二級指標由一級指標衍生而來，為了實現一級指標，企業會采取一些策略，二級指標通常與這些策略有所關聯?？梢院唵卫斫鉃橐患壷笜说膶崿F方式，用于替換定位一級指標的問題。

二級指標的作用就是將一級指標的漲跌落實到具體的業務部門或者是責任人，通過成分拆解我們可以從一級指標得到對應的二級指標。例如收入這個一級指標，通過成分拆解可以分為廣告收入和內購收入等。

4）得到三級指標

通過二級指標的分析可以找到相應問題的責任方，而三級指標的作用正是指導該責任方去定位具體問題，進而修復問題。

通過對二級指標的路徑拆解即可得到三級指標，一線人員可通過三級指標的具體表現快速做出相應的動作，所以三級指標的要求是盡可能覆蓋每一個關鍵路徑上的關鍵動作。

這里繼續拿內購收入這個指標舉例，通過路徑拆解，最終促成內購的關鍵行為路徑是：瀏覽商品、加入購物車、提交訂單、支付成功。

按照以上流程不斷查缺補漏確定各一級指標并對其進行逐步拆解，即可搭建出一套行之有效的數據指標體系。為了加深印象，下面看看各級指標的應用實戰案例：

責任方找到了，那就該趕緊定位解決問題啦。

問題就這樣自上而下的逐步拆解直到解決，當然了，現實工作中各級人員都要時刻關注自己負責的那部分指標將問題扼殺在萌芽階段，不要等著領導發現問題找過來再亡羊補牢?？偨Y起來整個指標體系的應用流程如下：

2. 如何落地指標體系

終于到了開干時候，有了目標之后接下來就是將規劃的指標進行埋點落地了。

落地指標就不像設計指標那樣首先著眼于一級指標，而是應該首先著眼于二級指標，因為一級指標是由二級指標組成的，二級指標埋點好了之后一級指標自然而然地可以計算出來。

埋點不是一個人的事情，需要各部門通力合作，下圖就是埋點的整個設計到落地的流程：

不知看完這張圖有沒有一個疑惑，責任方為什么還要去理解熟悉需求，需求方不是給出指標了嗎，照著去埋點就好了啊。如果你這么想的話，那你注定只能做一個工具人。

首先各指標跟具體的業務邏輯設計緊密相關的，如果你不去熟悉業務，是無法針對指標進行多維度細化埋點設計的，最終設計出來的埋點方案必定是丟三落四漏洞百出。

再者需求方給出的指標不一定是全面的，需求方往往數據意識不強，無法洞察到當前業務的很多細節是數據可分析的。

所以這就需要數據產品經理熟悉業務懂產品懂用戶，才能一針見血設計出一套有指導性意義的埋點方案，而不是照本畫葫蘆搞出一些冷冰冰的數據看看就好，要記住，每一個埋點都是有深意的，數據也是有靈魂的。

明確了埋點的工作流程，接下來要確定的是選擇自研數據門戶還是使用第三方工具，如：神策、Growing IO、諸葛IO等。這兩者主要有以下區別：

• 自研工作量大，搭建周期長，第三方提供現成的模型，搭建周期短；
• 自研更靈活，相對埋點實施方上報數據更友好，無需過多無謂的邏輯記錄，在后期的指標計算方式上可以隨心所欲，如某些耗時只要打好點，自研就可以通過兩個事件的時間差計算出耗時，而有些第三方則不支持。

總之，自研前期痛苦后期爽，第三方前期爽后期痛苦。從實現難度上來說自研需要的人力物力遠遠大于第三方服務，絕大部分中小公司會選擇第三方服務，下面的埋點介紹就基于第三方服務的方式進行講解。

老規矩，在講解之前先上一張整體的流程圖：

1）埋點規范文檔

正如前面所說，指標體系的搭建需要各部門通力合作，一份埋點規范文檔既能規范工作流程提高效率，又能明確需求規范減少溝通成本避免理解出現偏差。埋點規范文檔包括了工作流程規范、命名規范、需求文檔規范等，這些應該在指標體系落地之初就規定好。

當然由于一開始經驗不足并且有的問題在后續的工作中才會暴露出來，初版的規范文檔可能并沒有那么詳細，但是大體框架還是要有的，后續再補充一些細枝末節的東西。

2）拿到需求原型

就是產品功能原型或者活動原型。

3）定義頁面、元素名稱

拿到需求原型后，首先將原型里面的頁面及頁面中的元素名稱提前定義好，以便后續進行統一使用避免不同指標出現頁面命名不一致的情況。

如果是頁面的話建議全部命名，頁面里面的元素可能會有點多，可以挑一些關鍵路徑上的重要元素進行命名，其它元素視后續工作需求再進行埋點（當然了有精力的話全部命名進行監控是更好的，畢竟數據是多多益善，避免后續需要用數據發現沒有埋點的情況發生）。

4）定義事件名稱

為什么要規范事件名稱？我直接舉個例子吧，某天你想查看用戶的使用路徑，當你使用用戶路徑分析之后發現有大量的展示事件穿插在用戶行為事件中，這時候你是不是很惱火。

如果之前埋點的時候對事件進行規范命名，這時候你只需要在篩選條件中過濾掉事件名前綴為展示的事件，就可以輕松過濾掉所有跟用戶行為無關的事件。

事件規范命名除了以上好處，還有個好處就是方便需求方使用，使用者可以通過事件名輕松知道這個事件具體的含義，提高了使用效率，事件命名可由以下幾部分組成：行為、對象、結果、類型。

各部分解釋：

• 行為：事件的具體行為，主要有 4 類：

1. 點擊 – 點擊某個按鈕或元素的一類事件；
2. 進入 – 進入某個頁面或功能的一類事件；
3. 展示 – 展示某個頁面或元素的一類事件；
4. 退出 – 退出某個頁面或功能的一類事件。

事件行為必須填寫，后續可按實際情況增加其他行為。

• 對象：事件行為對應的具體對象可以是頁面，或者是功能，事件對象必須填寫。
• 結果：對該對象進行的行為最終的結果，主要有3類：

1. 成功 – 針對該對象進行的行為結果為成功；
2. 失敗 – 針對該對象進行的行為結果為失??；
3. 結果 – 針對該對象進行的行為結果為成功或者失敗，此時具體結果存儲在該事件的維度中，事件結果必須填寫。

• 類型：此參數為拓展參數，如展示事件可能展示的是頁面，也可能展示的是彈窗，這時候在事件后面加個頁面后綴或者彈窗后綴，后續使用起來就能很方便的區分事件的具體類型。事件類型為可選參數，視情況而定。

以上就是事件的命名標準，可以從該標準進行如下一些命名：注冊_指標_成功、進入_充值頁面_成功等。

5）梳理指標維度

這時候就要隆重介紹一下前面《指標體系搭建流程圖》中提到的新4W1H分析法了。為什么叫新4W1H，因為針對傳統的4W1H進行了新的的解釋，在新的釋義上可以更加合理的加上本人在實際工作中總結的經驗。

根據平時的埋點總結，事件維度主要由主題和事件因果幾個大維度組成。主體即用戶、設備和應用，因果即這個事件的來源和結果。通過增加因果維度可以方便的看到一個事件的來源和去向。

我們先用一張圖來了解下新4W1H分析法是如何定義維度的：

• Who：觸發該事件的主體，是唯一區分用戶的標志，如果用戶登錄了則使用用戶ID（設備ID也需要記錄），未登錄則使用設備ID；
• When：事件發生的時間，使用UNIX時間戳就好；
• What：描述觸發這個事件的參與主體具體信息，一般有三個主體，用戶本身、應用、還有設備。使用第三方服務的話除了用戶信息需要我們埋點設置，其他的第三方SDK都會自動采集，所以這部分參數不是我們工作的重點；
• Where：事件發生的物理地點，可以用過GPS、LBS、IP來判斷，具體視用戶的授權而定。位置信息第三方SDK也會自動采集；
• How：事件的具體描述，這一塊才是我們工作的重點，缺乏經驗的話往往會遺漏一些重要的維度，導致后續的分析支持不上。根據個人總結的因果分析法可以將事件的描述分為來源和結果描述，事件的來源去向無非有兩類：多個行為造成同一個結果、一個行為造成不同結果。

例如：進入充值頁面，可能從不同入口進來的；點擊充值按鈕，可能會充值成功或者充值失敗。

事件的結果即為對該事件的具體信息描述。通過因果分析法進入充值頁面到充值成功這一系列行為我們可以做以下事件埋點（以下事件維度只列舉因果分析法相關維度，其它參數視具體業務自由增加）：

通過這樣的埋點，我們就可以很清晰的知道進入充值頁面各個入口的分布情況，也能知道點擊充值按鈕后充值成功和失敗的分布。

6）明確上報時機

事件的上報時機由事件的定義來具體決定。主要有以下三大類：

1. 展示：展示時候上報，需要明確重復展示是否重復上報，像那種自動輪播的banner就不需要重復展示重復上報，因為這樣的重復上報是沒什么意義的，而用戶反復滑動導致的重復展示可以重復上報；
2. 點擊：點擊時上報，這個是最簡單的上報時機，一般沒什么爭議；
3. 接口：這個涉及到與后端的接口交互，如前面舉例的購買_金幣_結果事件，上報時機則為充值成功或者失敗時上報，即客戶端拿到后端返回的具體結果時上報。

7）輸出數據需求文檔

當上面工作已經做完時，就可以輸出需求文檔了，需求文檔主要包含以下信息：

8）錄入指標字典

埋點指標上線后，為了方便業務方使用，可以將各指標按照業務分為不同的主題，方便使用者快速找到需要的指標，具體包含以下信息：

三、數據應用

數據的作用用一句話來概括就是總結過去，預測未來，常見的使用方式如下：

鑒于篇幅問題這里就不再細說數據的分析應用了，后續有時間再另寫一篇有關數據分析的經驗。不知不覺寫了這么多，終于把指標設計到落地總結完了，希望大家看完能有所收獲。

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

題圖來自 Unsplash，基于 CC0 協議