編輯導語：幾乎所有的資料分析工作都會提到一個詞——“建立資料指標體系”，雖然這個詞對於大家來說並不陌生，但是如何具體的搭建，很多人還是一頭霧水的。今天，本文作者就和我們好好聊一聊資料指標體系如何從構思到落地。
指標是一個可以量化目標事物多少的數值，有時候也稱為度量，如：DNU、留存率等都是指標。
一個指標通常需要從多維度來分析指標構成，這就要求指標與多維度關聯支援多維度分析，如DNU就可以按照不同渠道檢視各渠道流量大小，也可以按作業系統檢視不同作業系統的人數，這裡的渠道、作業系統就是維度。
2. 好的指標體系該是什麼樣的？指標體系就是將各個指標按照特定的框架組織起來，從不同維度梳理指標，梳理的過程也是對業務本質進行思考的過程。
一個好的指標體系應該有以下兩點性質：
- 上能指引高層領導把控業務整體方向，下能指導業務人員落地執行業務目標；
- 指標之間要形成閉環相互作用相互影響產生反饋，才能稱之為體系，以資料定位問題，再反向作用運營和產品，最終形成資料驅動產品設計及使用者運營的閉環。
指標體系的搭建分為兩大步驟：設計指標體系和落地指標體系，這兩大部分又可以拆成一些小步驟，我們先來看一張指標體系從設計到落地的整體步驟圖，下面再根據這張圖細分拆解其中的每個步驟是怎樣落地的。
1）需求來源
主要需求來源隨著產品生命週期而改變。搭建資料指標根據資料現狀分為初中後三個階段。首先要明確的是先有目標方案後再有資料指標，而不是憑空捏造出一些指標體系然後往產品上套。
- 在資料指標搭建初期以產品戰略目標為主，優先搭建北極星指標的全方位指標監控；
- 中期以業務驅動為主，搭建指標衡量現有業務，業務驅動直接獲取到的指標一般是二級指標，需要整合到指標模型裡面去；
- 到了後期，此時各資料指標已經搭建的差不多了，是時候根據模型查缺補漏，搭建針對產品的指標閉環，透過資料來反向推動產品的迭代最佳化。
2）確定一級指標
一級指標其實就是反映產品在各個重要方面的運營情況怎麼樣，把對使用者的運營當成一個流水線，圍繞著使用者生命週期即可挖掘到一些重要的一級指標並自然而然的形成閉環。
在眾多指標模型中我覺得AARRR模型能很好的概括使用者的生命週期，美中不足的是遺漏了使用者流失這一環節，個人覺得AARRRR比較能完整概括使用者生命週期，即Acquisition（獲取）、Activation（啟用）、Retention（留存）、Revenue（收入）、Referral（自傳播）、Recall（召回）。
圍繞這六大方面，可以拓展以下一級指標（只是舉例一些通用指標，具體的一級指標可根據具體業務進行定義）：
3）得到二級指標
二級指標由一級指標衍生而來，為了實現一級指標，企業會採取一些策略，二級指標通常與這些策略有所關聯。可以簡單理解為一級指標的實現方式，用於替換定位一級指標的問題。
二級指標的作用就是將一級指標的漲跌落實到具體的業務部門或者是責任人，透過成分拆解我們可以從一級指標得到對應的二級指標。例如收入這個一級指標，透過成分拆解可以分為廣告收入和內購收入等。
4）得到三級指標
透過二級指標的分析可以找到相應問題的責任方，而三級指標的作用正是指導該責任方去定位具體問題，進而修復問題。
透過對二級指標的路徑拆解即可得到三級指標，一線人員可透過三級指標的具體表現快速做出相應的動作，所以三級指標的要求是儘可能覆蓋每一個關鍵路徑上的關鍵動作。
這裡繼續拿內購收入這個指標舉例，透過路徑拆解，最終促成內購的關鍵行為路徑是：瀏覽商品、加入購物車、提交訂單、支付成功。
按照以上流程不斷查缺補漏確定各一級指標並對其進行逐步拆解，即可搭建出一套行之有效的資料指標體系。為了加深印象，下面看看各級指標的應用實戰案例：
責任方找到了，那就該趕緊定位解決問題啦。
問題就這樣自上而下的逐步拆解直到解決，當然了，現實工作中各級人員都要時刻關注自己負責的那部分指標將問題扼殺在萌芽階段，不要等著領導發現問題找過來再亡羊補牢。總結起來整個指標體系的應用流程如下：
終於到了開干時候，有了目標之後接下來就是將規劃的指標進行埋點落地了。
落地指標就不像設計指標那樣首先著眼於一級指標，而是應該首先著眼於二級指標，因為一級指標是由二級指標組成的，二級指標埋點好了之後一級指標自然而然地可以計算出來。
埋點不是一個人的事情，需要各部門通力合作，下圖就是埋點的整個設計到落地的流程：
不知看完這張圖有沒有一個疑惑，責任方為什麼還要去理解熟悉需求，需求方不是給出指標了嗎，照著去埋點就好了啊。如果你這麼想的話，那你註定只能做一個工具人。
首先各指標跟具體的業務邏輯設計緊密相關的，如果你不去熟悉業務，是無法針對指標進行多維度細化埋點設計的，最終設計出來的埋點方案必定是丟三落四漏洞百出。
再者需求方給出的指標不一定是全面的，需求方往往資料意識不強，無法洞察到當前業務的很多細節是資料可分析的。
所以這就需要資料產品經理熟悉業務懂產品懂使用者，才能一針見血設計出一套有指導性意義的埋點方案，而不是照本畫葫蘆搞出一些冷冰冰的資料看看就好，要記住，每一個埋點都是有深意的，資料也是有靈魂的。
明確了埋點的工作流程，接下來要確定的是選擇自研資料門戶還是使用第三方工具，如：神策、Growing IO、諸葛IO等。這兩者主要有以下區別：
- 自研工作量大，搭建週期長，第三方提供現成的模型，搭建週期短；
- 自研更靈活，相對埋點實施方上報資料更友好，無需過多無謂的邏輯記錄，在後期的指標計算方式上可以隨心所欲，如某些耗時只要打好點，自研就可以透過兩個事件的時間差計算出耗時，而有些第三方則不支援。
總之，自研前期痛苦後期爽，第三方前期爽後期痛苦。從實現難度上來說自研需要的人力物力遠遠大於第三方服務，絕大部分中小公司會選擇第三方服務，下面的埋點介紹就基於第三方服務的方式進行講解。
老規矩，在講解之前先上一張整體的流程圖：
1）埋點規範文件
正如前面所說，指標體系的搭建需要各部門通力合作，一份埋點規範文件既能規範工作流程提高效率，又能明確需求規範減少溝通成本避免理解出現偏差。埋點規範文件包括了工作流程規範、命名規範、需求文件規範等，這些應該在指標體系落地之初就規定好。
當然由於一開始經驗不足並且有的問題在後續的工作中才會暴露出來，初版的規範文件可能並沒有那麼詳細，但是大體框架還是要有的，後續再補充一些細枝末節的東西。
2）拿到需求原型
就是產品功能原型或者活動原型。
3）定義頁面、元素名稱
拿到需求原型後，首先將原型裡面的頁面及頁面中的元素名稱提前定義好，以便後續進行統一使用避免不同指標出現頁面命名不一致的情況。
如果是頁面的話建議全部命名，頁面裡面的元素可能會有點多，可以挑一些關鍵路徑上的重要元素進行命名，其它元素視後續工作需求再進行埋點（當然了有精力的話全部命名進行監控是更好的，畢竟資料是多多益善，避免後續需要用資料發現沒有埋點的情況發生）。
4）定義事件名稱
為什麼要規範事件名稱？我直接舉個例子吧，某天你想檢視使用者的使用路徑，當你使用使用者路徑分析之後發現有大量的展示事件穿插在使用者行為事件中，這時候你是不是很惱火。
如果之前埋點的時候對事件進行規範命名，這時候你只需要在篩選條件中過濾掉事件名字首為展示的事件，就可以輕鬆過濾掉所有跟使用者行為無關的事件。
事件規範命名除了以上好處，還有個好處就是方便需求方使用，使用者可以透過事件名輕鬆知道這個事件具體的含義，提高了使用效率，事件命名可由以下幾部分組成：行為、物件、結果、型別。
各部分解釋：
- 點選 – 點選某個按鈕或元素的一類事件；
- 進入 – 進入某個頁面或功能的一類事件；
- 展示 – 展示某個頁面或元素的一類事件；
- 退出 – 退出某個頁面或功能的一類事件。
事件行為必須填寫，後續可按實際情況增加其他行為。
- 物件：事件行為對應的具體物件可以是頁面，或者是功能，事件物件必須填寫。
- 結果：對該物件進行的行為最終的結果，主要有3類：
- 成功 – 針對該物件進行的行為結果為成功；
- 失敗 – 針對該物件進行的行為結果為失敗；
- 結果 – 針對該物件進行的行為結果為成功或者失敗，此時具體結果儲存在該事件的維度中，事件結果必須填寫。
- 型別：此引數為拓展引數，如展示事件可能展示的是頁面，也可能展示的是彈窗，這時候在事件後面加個頁面字尾或者彈窗字尾，後續使用起來就能很方便的區分事件的具體型別。事件型別為可選引數，視情況而定。
以上就是事件的命名標準，可以從該標準進行如下一些命名：註冊_指標_成功、進入_充值頁面_成功等。
5）梳理指標維度
這時候就要隆重介紹一下前面《指標體系搭建流程圖》中提到的新4W1H分析法了。為什麼叫新4W1H，因為針對傳統的4W1H進行了新的的解釋，在新的釋義上可以更加合理的加上本人在實際工作中總結的經驗。
根據平時的埋點總結，事件維度主要由主題和事件因果幾個大維度組成。主體即使用者、裝置和應用，因果即這個事件的來源和結果。透過增加因果維度可以方便的看到一個事件的來源和去向。
我們先用一張圖來了解下新4W1H分析法是如何定義維度的：
- Who：觸發該事件的主體，是唯一區分使用者的標誌，如果使用者登入了則使用使用者ID（裝置ID也需要記錄），未登入則使用裝置ID；
- When：事件發生的時間，使用UNIX時間戳就好；
- What：描述觸發這個事件的參與主體具體資訊，一般有三個主體，使用者本身、應用、還有裝置。使用第三方服務的話除了使用者資訊需要我們埋點設定，其他的第三方SDK都會自動採集，所以這部分引數不是我們工作的重點；
- Where：事件發生的物理地點，可以用過GPS、LBS、IP來判斷，具體視使用者的授權而定。位置資訊第三方SDK也會自動採集；
- How：事件的具體描述，這一塊才是我們工作的重點，缺乏經驗的話往往會遺漏一些重要的維度，導致後續的分析支援不上。根據個人總結的因果分析法可以將事件的描述分為來源和結果描述，事件的來源去向無非有兩類：多個行為造成同一個結果、一個行為造成不同結果。
例如：進入充值頁面，可能從不同入口進來的；點選充值按鈕，可能會充值成功或者充值失敗。
事件的結果即為對該事件的具體資訊描述。透過因果分析法進入充值頁面到充值成功這一系列行為我們可以做以下事件埋點（以下事件維度只列舉因果分析法相關維度，其它引數視具體業務自由增加）：
透過這樣的埋點，我們就可以很清晰的知道進入充值頁面各個入口的分佈情況，也能知道點選充值按鈕後充值成功和失敗的分佈。
6）明確上報時機
事件的上報時機由事件的定義來具體決定。主要有以下三大類：
- 展示：展示時候上報，需要明確重複展示是否重複上報，像那種自動輪播的banner就不需要重複展示重複上報，因為這樣的重複上報是沒什麼意義的，而使用者反覆滑動導致的重複展示可以重複上報；
- 點選：點選時上報，這個是最簡單的上報時機，一般沒什麼爭議；
- 介面：這個涉及到與後端的介面互動，如前面舉例的購買_金幣_結果事件，上報時機則為充值成功或者失敗時上報，即客戶端拿到後端返回的具體結果時上報。
7）輸出資料需求文件
當上面工作已經做完時，就可以輸出需求文件了，需求文件主要包含以下資訊：
8）錄入指標字典
埋點指標上線後，為了方便業務方使用，可以將各指標按照業務分為不同的主題，方便使用者快速找到需要的指標，具體包含以下資訊：
資料的作用用一句話來概括就是總結過去，預測未來，常見的使用方式如下：
鑑於篇幅問題這裡就不再細說資料的分析應用了，後續有時間再另寫一篇有關資料分析的經驗。不知不覺寫了這麼多，終於把指標設計到落地總結完了，希望大家看完能有所收穫。
本文由 @不語 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議