編輯導語：埋點是數(shù)據(jù)產品經(jīng)理必備的工作技能之一，對于實際工作十分重要。本文作者介紹了有關數(shù)據(jù)埋點的相關內容，從數(shù)據(jù)采集的流程、埋點方案的類型和選擇等展開分析，一起來學習一下吧，希望對你有幫助。

數(shù)據(jù)是數(shù)據(jù)產品的根基，而埋點是數(shù)據(jù)的起點；如果沒有埋點，那數(shù)據(jù)產品則是無源之水。

可以說埋點是互聯(lián)網(wǎng)行業(yè)里遇到的關鍵且無法繞過的問題。

以下是企業(yè)不同位置的同學內心OS：

• 業(yè)務產品：埋什么，怎么埋？
• 數(shù)據(jù)產品：埋點不規(guī)范，錯埋、漏埋；
• 業(yè)務開發(fā)：開發(fā)成本高，不懂數(shù)據(jù)，代碼冗余；
• 數(shù)據(jù)分析：埋點規(guī)則找不到，數(shù)據(jù)分析成本高。

業(yè)務同學對于埋點是什么都不知道，也不清楚要埋什么；所以往往會做了功能但是沒有做埋點，在需要進行數(shù)據(jù)分析的時候去找數(shù)據(jù)團隊要數(shù)據(jù)，數(shù)據(jù)團隊會反問：“你們埋點了嗎？”

數(shù)據(jù)產品，因為他們對于業(yè)務的認知并不深刻，所以經(jīng)常會出現(xiàn)漏埋、錯埋的情況，導致最后無數(shù)可取的結果。

業(yè)務開發(fā)，本質上他們是解決業(yè)務相關問題，數(shù)據(jù)開發(fā)對他們來說一個比較額外的工作，所以他們的開發(fā)成本會隨著埋點需求而增加，也有可能伴隨項目延期的風險；其次過得的埋點開發(fā)需求也會導致代碼的冗余。

數(shù)據(jù)分析，他們更多地是用數(shù)據(jù)，數(shù)據(jù)埋點的規(guī)則找不到，以至于無法很好的通過數(shù)據(jù)驅動進行分析。

一、數(shù)據(jù)采集的流程是什么？數(shù)據(jù)從何而來呢

• 瀏覽軌跡：用戶在使用我們的產品時候，會在頁面上產生一個行為路徑、交互的動作，比如訪問某個頁面，點擊某個商品等等，那這些數(shù)據(jù)的核心來源就是我們的埋點代碼采集相關行為動作；
• 業(yè)務系統(tǒng)：比如訂單交易、數(shù)據(jù)表等，通過數(shù)據(jù)庫同步的方式，將數(shù)據(jù)同步給下游相關系統(tǒng)進行使用；

外部數(shù)據(jù)的交互：比如API數(shù)據(jù)的傳輸、 數(shù)據(jù)文件的傳輸?shù)?；目前某平臺的大數(shù)據(jù)標簽系統(tǒng)就是通過這種方式傳輸補齊企業(yè)的人群標簽等。而數(shù)據(jù)產品在整個數(shù)據(jù)鏈路上來說，基本可以劃分為以下流程：

首先數(shù)據(jù)采集我們要從不同的端采集不同的數(shù)據(jù)，然后進行數(shù)據(jù)清洗加工處理（ETL），然后匯總到數(shù)據(jù)倉庫中，供用戶分析、用戶畫像、精準營銷等使用；

我們知道數(shù)據(jù)采集、數(shù)據(jù)埋點的重要性后，在實際的業(yè)務功能需求提出的時候，一定是要提相關埋點需求的，那在做數(shù)據(jù)采集我們需要遵循怎么樣的流程呢？

1. 業(yè)務方確認功能，并發(fā)起埋點需求：提交包括所在頁面、觸發(fā)控件、觸發(fā)場景等；
2. 由專門的埋點團隊來進行系統(tǒng)校驗，確保命名規(guī)范、一致性，BI審核埋點申請和統(tǒng)計需求是否合理缺失等；
3. 審核通過后，開發(fā)進行埋點采集框架的設計，開發(fā)埋點，完成埋點后進行測試；
4. 測試預先編寫能夠覆蓋所有場景的業(yè)務場景，測試通過更新需求狀態(tài)；
5. 業(yè)務驗證埋點，數(shù)據(jù)開發(fā)和數(shù)據(jù)分析；

以上環(huán)節(jié)缺一不可，只有規(guī)范的流程，才可以在最后的分析中發(fā)現(xiàn)正確的現(xiàn)狀問題。

二、如何選擇埋點方案呢

現(xiàn)在互聯(lián)網(wǎng)行業(yè)主流的埋點方案主要分為四種：

1. 第一種：代碼埋點，代碼埋點又分為前端埋點和后端埋點；前端埋點是通過前端的代碼埋點來監(jiān)控用戶觸發(fā)某個頁面的數(shù)據(jù)采集

前端埋點的優(yōu)點很明顯，但是缺點也很明顯，由于前端埋點的數(shù)據(jù)是通過延遲上報的機制，比如用戶點擊某個頁面按鈕它不會立刻上報，而是累計到一定的值以后才會按批上班，受限于當前網(wǎng)絡情況，如果遇到網(wǎng)絡堵塞等問題就會數(shù)據(jù)丟包，因此前端埋點丟失率比較高，一般在5%~10%。

而且前端埋點如果有漏埋和錯埋的情況，那就要通過app發(fā)版進行優(yōu)化，而客戶端發(fā)版就要很久的時間。

2. 第二種：服務端埋點：在API的接口里植入埋點代碼段

優(yōu)點是在每次用戶觸發(fā)這次請求，都會觸發(fā)埋點代碼進行數(shù)據(jù)統(tǒng)計，所以無需發(fā)版，及時觸發(fā)及時更新。

缺點是服務端埋點需要依賴服務請求，無法覆蓋所有前端交互，以及對于用戶路徑采集也比較弱。

3. 第三種：全埋點；是目前互聯(lián)網(wǎng)做用戶增資的企業(yè)提出的一種埋點思路，通過埋點SDK接入，針對頁面所有的采集頁面元素的瀏覽和點擊行為做統(tǒng)一的收集，不是按次和需求采集，而是提前全部采集

優(yōu)點是開發(fā)成本高，SDK接入后后期維護成本也低，且埋點流程也很簡單；先采集后定義，在一定程度上能避免漏埋錯埋。

缺點是數(shù)據(jù)的冗余，導致很多數(shù)據(jù)并無用處，且數(shù)據(jù)采集范圍僅僅是頁面可見元素，比如像曝光這種就無法采集到；數(shù)據(jù)準確性也有問題。

4. 第四種：可視化埋點；也是接入埋點SDK，但是并不是隨時隨地采集，而是按需采集，通過可視化圈選觸發(fā)埋點采集

優(yōu)點是操作簡單，且按需埋點不會采集無效數(shù)據(jù)，開發(fā)成本比較低；并且數(shù)據(jù)埋點是可支持撤銷操作的，總體來說比全埋點數(shù)據(jù)量會小很多。

缺點：歷史數(shù)據(jù)是無法恢復的，因為在我們圈選動作之前的數(shù)據(jù)是無法進行采集的；統(tǒng)計范圍僅支持頁面前端的動作，比如曝光也是無法采集到的。

三、了解各種埋點方案以后，如何在實際工作中選擇埋點方案呢

選擇埋點方案的參考主要基于三點：

1. 業(yè)務發(fā)展階段：開發(fā)投入成本、業(yè)務迭代速度
2. 業(yè)務屬性：交互應用類、業(yè)務交易類
3. 分析深度：用戶行為分析、業(yè)務分析、業(yè)務應用

比如我們可以根據(jù)業(yè)務發(fā)展階段來定，比如說現(xiàn)在業(yè)務發(fā)展較快，版本迭代速度快、開發(fā)投入成本高，那我們做客戶端埋點和服務端埋點是不太適合的，因為可能沒過多久版本就更新了，所以全埋點和可視化埋點比較適合；

那對于比較強的業(yè)務數(shù)據(jù)分析場景來說，需加上前端客戶端埋點；以及需要考慮分析深度，如果僅僅是想看用戶前端行為路徑的，那全埋點和可視化埋點就能滿足需求，但是如果分析業(yè)務全流程那一定是需要配合上代碼埋點。

我是比較推薦全埋點+代碼埋點組合，如何服務端能做，優(yōu)先服務端做，這樣數(shù)據(jù)準確度會更高。

四、確定埋點選型后，那我們就要開始具體設計埋點了

事件是埋點里最核心的要素，如果我們要清晰的定位埋點，就要從6個維度進行定義，我們可以總結為who、when、where、what、why、How；這幾個元素就構建了事件的基本要素。

那對于埋點事件主要可分為三類：

1. 交互事件：瀏覽、點擊、收藏、支付、曝光、關閉；
2. 系統(tǒng)事件：APP啟動、APP crash；
3. 業(yè)務狀態(tài)：支付成功、用戶續(xù)期等（這種強依賴服務端的返回）。

通過以上我們基本就可以判斷出我們需要記錄用戶什么行為，采集什么數(shù)據(jù)，for后續(xù)的什么分析了。

寫在最后，在工作生涯中，過往的坑告訴我，一個好的埋點管理平臺是多么的重要。

首先流程線上化，我們往往在一封封埋點的郵件中迷失自我，但是如果是線上申請，那需求申請、處理、接入、驗證、測試就非常方便和快捷，規(guī)避信息溝通中的缺失；

其次可以管理規(guī)范，埋點都統(tǒng)一管理，信息集中管理，方便后期的分析和使用；

最重要的是監(jiān)控實時化，減少漏埋、錯埋的問題。

當然如果沒有埋點管理平臺，確定下規(guī)范的埋點流程，選擇適合當下業(yè)務的埋點方案，我相信你也一定也可以做好埋點以及通過數(shù)據(jù)完成豐富的場景分析！

作者：Goodnight；專注用戶、產品等運營領域。

本文由 @Goodnight. 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協(xié)議