編輯導語：幾乎所有的資料分析工作都會提到一個詞——“建立資料名額體系”，雖然這個詞對于大家來說并不陌生，但是如何具體的搭建，很多人還是一頭霧水的。今天，本文作者就和我們好好聊一聊資料名額體系如何從構思到落地。
一、資料名額與體系
1. 什麼是資料名額？
名額是一個可以量化目标事物多少的數值，有時候也稱為度量，如：DNU、留存率等都是名額。
一個名額通常需要從多元度來分析名額構成，這就要求名額與多元度關聯支援多元度分析，如DNU就可以按照不同管道檢視各管道流量大小，也可以按作業系統檢視不同作業系統的人數，這裡的管道、作業系統就是次元。
2. 好的名額體系該是什麼樣的？
名額體系就是将各個名額按照特定的架構組織起來，從不同次元梳理名額，梳理的過程也是對業務本質進行思考的過程。
一個好的名額體系應該有以下兩點性質：
上能指引高層上司把控業務整體方向，下能指導業務人員落地執行業務目标；名額之間要形成閉環互相作用互相影響産生回報，才能稱之為體系，以資料定位問題，再反向作用營運和産品，最終形成資料驅動産品設計及使用者營運的閉環。
二、如何搭建名額體系
名額體系的搭建分為兩大步驟：設計名額體系和落地名額體系，這兩大部分又可以拆成一些小步驟，我們先來看一張名額體系從設計到落地的整體步驟圖，下面再根據這張圖細分拆解其中的每個步驟是怎樣落地的。
1. 如何設計名額體系
1）需求來源
主要需求來源随着産品生命周期而改變。搭建資料名額根據資料現狀分為國中後三個階段。首先要明确的是先有目标方案後再有資料名額，而不是憑空捏造出一些名額體系然後往産品上套。
在資料名額搭建初期以産品戰略目标為主，優先搭建北極星名額的全方位名額監控；中期以業務驅動為主，搭建名額衡量現有業務，業務驅動直接擷取到的名額一般是二級名額，需要整合到名額模型裡面去；到了後期，此時各資料名額已經搭建的差不多了，是時候根據模型查缺補漏，搭建針對産品的名額閉環，通過資料來反向推動産品的疊代優化。2）确定一級名額
一級名額其實就是反映産品在各個重要方面的營運情況怎麼樣，把對使用者的營運當成一個流水線，圍繞着使用者生命周期即可挖掘到一些重要的一級名額并自然而然的形成閉環。
在衆多名額模型中我覺得AARRR模型能很好的概括使用者的生命周期，美中不足的是遺漏了使用者流失這一環節，個人覺得AARRRR比較能完整概括使用者生命周期，即Acquisition（擷取）、Activation（激活）、Retention（留存）、Revenue（收入）、Referral（自傳播）、Recall（召回）。
圍繞這六大方面，可以拓展以下一級名額（隻是舉例一些通用名額，具體的一級名額可根據具體業務進行定義）：
3）得到二級名額
二級名額由一級名額衍生而來，為了實作一級名額，企業會采取一些政策，二級名額通常與這些政策有所關聯。可以簡單了解為一級名額的實作方式，用于替換定位一級名額的問題。
二級名額的作用就是将一級名額的漲跌落實到具體的業務部門或者是責任人，通過成分拆解我們可以從一級名額得到對應的二級名額。例如收入這個一級名額，通過成分拆解可以分為廣告收入和内購收入等。
4）得到三級名額
通過二級名額的分析可以找到相應問題的責任方，而三級名額的作用正是指導該責任方去定位具體問題，進而修複問題。
通過對二級名額的路徑拆解即可得到三級名額，一線人員可通過三級名額的具體表現快速做出相應的動作，是以三級名額的要求是盡可能覆寫每一個關鍵路徑上的關鍵動作。
這裡繼續拿内購收入這個名額舉例，通過路徑拆解，最終促成内購的關鍵行為路徑是：浏覽商品、加入購物車、送出訂單、支付成功。
按照以上流程不斷查缺補漏确定各一級名額并對其進行逐漸拆解，即可搭建出一套行之有效的資料名額體系。為了加深印象，下面看看各級名額的應用實戰案例：
責任方找到了，那就該趕緊定位解決問題啦。
問題就這樣自上而下的逐漸拆解直到解決，當然了，現實工作中各級人員都要時刻關注自己負責的那部分名額将問題扼殺在萌芽階段，不要等着上司發現問題找過來再亡羊補牢。總結起來整個名額體系的應用流程如下：
2. 如何落地名額體系
終于到了開幹時候，有了目标之後接下來就是将規劃的名額進行埋點落地了。
落地名額就不像設計名額那樣首先着眼于一級名額，而是應該首先着眼于二級名額，因為一級名額是由二級名額組成的，二級名額埋點好了之後一級名額自然而然地可以計算出來。
埋點不是一個人的事情，需要各部門通力合作，下圖就是埋點的整個設計到落地的流程：
不知看完這張圖有沒有一個疑惑，責任方為什麼還要去了解熟悉需求，需求方不是給出名額了嗎，照着去埋點就好了啊。如果你這麼想的話，那你注定隻能做一個工具人。
首先各名額跟具體的業務邏輯設計緊密相關的，如果你不去熟悉業務，是無法針對名額進行多元度細化埋點設計的，最終設計出來的埋點方案必定是丢三落四漏洞百出。
再者需求方給出的名額不一定是全面的，需求方往往資料意識不強，無法洞察到目前業務的很多細節是資料可分析的。
是以這就需要資料産品經理熟悉業務懂産品懂使用者，才能一針見血設計出一套有指導性意義的埋點方案，而不是照本畫葫蘆搞出一些冷冰冰的資料看看就好，要記住，每一個埋點都是有深意的，資料也是有靈魂的。
明确了埋點的工作流程，接下來要确定的是選擇自研資料門戶還是使用第三方工具，如：神策、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 協定
舉報/回報