想看埋點數據？產品經理有必要了解的埋點知識

本文是數據埋點知識系列的第二篇文章，主要分享關於埋點數據的採集、傳輸、加工、存儲、應用和管理等內容。

正如上篇文章所提的，埋點是互聯網公司獲取數據信息的重要方式。數據的全流程一般涉及到採集、傳輸、加工、存儲、應用等過程。下面就將按照這個順序，對埋點全流程進行說明。最後，加入了一個埋點系統設計者對埋點管理過程的理解，期待同行的交流~

上文提到了埋點信息採集的方式，那麼具體埋點信息採集的過程是怎麼樣的呢？

以H5網頁某頁面曝光埋點為例子，先講一下網頁頁面展現的流程。框圖如下：

具體細節如下：

• 用戶點擊或輸入某頁面鏈接。
• APP客戶端或瀏覽器向伺服器發送HTTP請求。該請求內容一般包括請求的URL、請求方法、請求報頭（一些必要的內容例如用戶cookie等）、請求內容。
• 伺服器接受HTTP請求，進行解析，並將內容返回給客戶端或瀏覽器。返回內容一般包括返回狀態（是否成功，例如著名的404就是在這裡進行添加的），返回具體內容（請求的網頁中包含的內容如圖片等），返回報頭（cookie等）
• 客戶端或瀏覽器對返回內容進行解析，並把內容展示給用戶。

這樣就完成了一個頁面的曝光展示。如果對該曝光事件加上埋點，前兩步是沒有影響的，在第三步：伺服器在返回HTTP內容時，會加入一段與埋點相關的腳本代碼（如上文埋點方式部分所說，這段代碼可能是手動埋點寫入的，也可能是半自動或全自動埋點方式寫入的）。

客戶端或瀏覽器解析到這部分內容時，會向埋點日誌接收伺服器（以下簡稱埋點伺服器）發送一個請求。這個請求中即帶有我們通過埋點想獲得的寶貴的數據信息。埋點伺服器接受到請求后，會返回一個已接收的信息給客戶端。同時，埋點伺服器會將這些信息傳輸到後續環節。如下圖：

這裡再說一下和數據準確性有關的內容。在客戶端向埋點伺服器發送信息的過程中，可能存在丟包，即數據發送失敗信息沒有傳輸過去的情況。該發送過程一般通過POST格式，發送JSON串信息，具體方式分兩種：一種是單條發送；一種是在本地打包成zip包，積累一定量后發送。兩種方式中，zip的丟包情況更嚴重些。所以PM在看數據時候，也應當清楚，數據會有一定誤差。（據作者實踐經驗，單條POST格式數據誤差一般不超過2%）

埋點數據產生之後，被埋點伺服器接收，有些時候會進行解析操作，然後會通過消息訂閱通道例如kafka之類進行消息的分發，進入離線或實時的儲存中，用於後續的計算和分析。

加工和存儲過程：

加工：經過加工存儲這一步后，埋點數據基本可以從收集到的原材料狀態變為可以為業務服務的有用數據了。上文提到，埋點數據都是一條一條，是用戶觸發埋點對應事件時上傳的。

這些數據可能包括：用戶會話id，用戶id，當前頁面編碼，當前事件編碼，觸發時間，用戶設備id，ip信息等，這些零散的信息需要通過加工處理進行聚合，變成更加通用常用的數據，便於後續調用。

例如一些通用的處理：針對APP首頁曝光事件，選取當日首頁曝光事件上傳的數據條數，對用戶id去重並加和即可以得到當日的UV。

存儲：對於離線存儲來說，埋點原始數據會以表（類似excel表）的形式存儲於數據倉庫的原始數據層，經過上述處理過的數據，會以另外一張表的形式存儲於數據倉庫的匯總層。如果數據倉庫建設比較完善，通用的業務數據，直接從匯總層甚至更上層的應用層中取即可，而不必再去取原始層的埋點數據，省去了每次計算的工作量。

任何需要用戶行為數據的場景，可能都能用到埋點信息。埋點數據可以用來計算頁面的UV/PV、控制項的點擊PV/UV等基礎數據，按照不同維度進一步加工可得APP的日活月活；也可以計算頁面停留時間，流失率等；更為複雜一些，通過當前事件和上一事件間的關係（需要在埋點中定義），可以繪製出用戶的行為路徑圖，計算漏斗轉化率等等。

這些業務上的應用實現：

• 大一點的公司可能有自己的可視化工具，直連到數據倉庫應用層中已經加工聚合過的埋點數據並進行可視化展示；
• 有些公司可能需要BI人員使用tableau等可視化工具，寫SQL跑數據去處理數據倉庫中較為原始的埋點數據，然後得以展現。

如果是後者，需要BI人員的排期，則周期會比較長。

對於實時的數據源，還有開源的grafana、kibana等可視化工具可以利用進行展示，但使用門檻較高，PM等非技術人員上手比較困難。

埋點管理過程：

最原始的埋點管理方式是用文檔或表格記錄下來埋點的編碼命名、業務含義及其他必備信息，在埋點業務方內部共享即可。

但當公司的產品越做越多越做越大，相應的埋點就會越多（多達成千甚至上萬）。對互聯網規模企業，管理大量埋點往往也需要配套的工具：埋點信息管理系統。

埋點信息管理系統主要有的功能：

• 提供埋點信息的錄入功能。
• 記錄各埋點是否存在，進行埋點層級管理。因為埋點較多，往往需要按照APP-頁面-控制項的層級進行分類、記錄和查詢。
• 展示並可查詢某埋點的詳細信息。例如物理編碼信息和對應的業務含義信息，埋點的上線版本和時間，埋點管理員責任人，埋點信息儲存的數倉表名稱以及必要的埋點數據結構體（對個性化埋點可能出現的上傳數據中新加欄位的解釋）。
• 輔助功能。如埋點數據量的監控，埋點信息預覽，埋點數據通用分析及可視化展示等。

埋點管理是建立在埋點生成、傳輸、儲存等過程的基礎之上的。管理的重點和難點，在於大量埋點物理編碼（命名編碼）和業務含義的對應。這個對應是將不可讀的英文編碼欄位和易於理解的漢語業務含義連接起來的過程。對應可能是一對多，多對一，甚至多對多的。

1.對應過程在手動埋點中，反應在PM與開發溝通及開發具體埋點行為中。首先PM需要根據業務含義，選擇要埋的點並取或生成一個物理編碼；之後開發按照這個對應關係，將物理編碼寫入到業務含義對應的頁面或事件上。這個過程是抽象且容易出錯的。

2.對應過程在全自動埋點中，反應在PM和開發溝通並「認領」自動埋點的行為中。PM需要向開發了解，已經存在的某物理編碼代表的是什麼意思即其業務含義是什麼，然後將這兩者關聯。往往還需要將IOS和安卓兩個不同的物理編碼關聯到同一業務含義上，因為這兩個物理編碼實際就是同一頁面或控制項。這個過程，也是抽象易錯的。

抽象易錯，主要是因為需要憑腦中想象將兩種文字編碼級的內容進行關聯。上文提到的可視化埋點則可通過直觀的APP展現，顯示出物理編碼及業務含義，解決抽象的問題。伴隨著產品迭代埋點數目增長，似乎有效的可視化埋點是大公司做埋點管理有必要嘗試的方向。

相關閱讀：

想看埋點數據？產品經理有必要了解的埋點知識（1）

本文由 @Chase 原創發佈於人人都是產品經理。未經許可，禁止轉載