數據産品經理具體要學什麼?編輯導語：埋點是數據産品經理必備的工作技能之一，對于實際工作十分重要本文作者介紹了有關數據埋點的相關内容，從數據采集的流程、埋點方案的類型和選擇等展開分析，一起來學習一下吧，希望對你有幫助，今天小編就來說說關于數據産品經理具體要學什麼?下面更多詳細答案一起來看看吧!

數據産品經理具體要學什麼

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

數據是數據産品的根基，而埋點是數據的起點；如果沒有埋點，那數據産品則是無源之水。

可以說埋點是互聯網行業裡遇到的關鍵且無法繞過的問題。

以下是企業不同位置的同學内心OS：

業務産品：埋什麼，怎麼埋？

數據産品：埋點不規範，錯埋、漏埋；

業務開發：開發成本高，不懂數據，代碼冗餘；

數據分析：埋點規則找不到，數據分析成本高。

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

數據産品，因為他們對于業務的認知并不深刻，所以經常會出現漏埋、錯埋的情況，導緻最後無數可取的結果。

業務開發，本質上他們是解決業務相關問題，數據開發對他們來說一個比較額外的工作，所以他們的開發成本會随着埋點需求而增加，也有可能伴随項目延期的風險；其次過得的埋點開發需求也會導緻代碼的冗餘。

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

浏覽軌迹：用戶在使用我們的産品時候，會在頁面上産生一個行為路徑、交互的動作，比如訪問某個頁面，點擊某個商品等等，那這些數據的核心來源就是我們的埋點代碼采集相關行為動作；

業務系統：比如訂單交易、數據表等，通過數據庫同步的方式，将數據同步給下遊相關系統進行使用；

外部數據的交互：比如API數據的傳輸、 數據文件的傳輸等；目前某平台的大數據标簽系統就是通過這種方式傳輸補齊企業的人群标簽等。

而數據産品在整個數據鍊路上來說，基本可以劃分為以下流程：

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

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

業務方确認功能，并發起埋點需求：提交包括所在頁面、觸發控件、觸發場景等；

由專門的埋點團隊來進行系統校驗，确保命名規範、一緻性，BI審核埋點申請和統計需求是否合理缺失等；

審核通過後，開發進行埋點采集框架的設計，開發埋點，完成埋點後進行測試；

測試預先編寫能夠覆蓋所有場景的業務場景，測試通過更新需求狀态；

業務驗證埋點，數據開發和數據分析；

以上環節缺一不可，隻有規範的流程，才可以在最後的分析中發現正确的現狀問題。

現在互聯網行業主流的埋點方案主要分為四種：

1. 第一種：代碼埋點，代碼埋點又分為前端埋點和後端埋點；前端埋點是通過前端的代碼埋點來監控用戶觸發某個頁面的數據采集

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

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

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

優點是在每次用戶觸發這次請求，都會觸發埋點代碼進行數據統計，所以無需發版，及時觸發及時更新。

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

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

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

缺點是數據的冗餘，導緻很多數據并無用處，且數據采集範圍僅僅是頁面可見元素，比如像曝光這種就無法采集到；數據準确性也有問題。

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

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

缺點：曆史數據是無法恢複的，因為在我們圈選動作之前的數據是無法進行采集的；統計範圍僅支持頁面前端的動作，比如曝光也是無法采集到的。

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

業務發展階段：開發投入成本、業務疊代速度

業務屬性：交互應用類、業務交易類

分析深度：用戶行為分析、業務分析、業務應用

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

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

我是比較推薦全埋點 代碼埋點組合，如何服務端能做，優先服務端做，這樣數據準确度會更高。

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

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

交互事件：浏覽、點擊、收藏、支付、曝光、關閉；

系統事件：APP啟動、APP crash；

業務狀态：支付成功、用戶續期等（這種強依賴服務端的返回）。

通過以上我們基本就可以判斷出我們需要記錄用戶什麼行為，采集什麼數據，for後續的什麼分析了。

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

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

其次可以管理規範，埋點都統一管理，信息集中管理，方便後期的分析和使用；

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

當然如果沒有埋點管理平台，确定下規範的埋點流程，選擇适合當下業務的埋點方案，我相信你也一定也可以做好埋點以及通過數據完成豐富的場景分析！

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

本文由 @Goodnight. 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!