從做數據產品開始，自己的日常工作就被埋點占據了大部分，到后面做平臺類數據產品之后發現埋點問題依舊占據很多精力且治理困難，寫這篇文章也是跟大家討論討論自己做埋點治理的心得以及深入剖析下為什么埋點質量這么難保障。

做埋點時間長了，越來越覺得埋點并不像自己想象的那么簡單，僅僅是開發在自己要統計的業務場景下寫埋點代碼打包上傳統計數據就完成工作，從最開始的埋點需求規劃再到最后數據上報只要有一個環節有坑就會影響數據準確性，而數據準確性估計是每個數據人工作中必須要面對的難題。

下面簡單聊聊自己遇到的坑，這些或許僅僅是表述了現象，至于導致此現象發生的本質相信就仁者見仁 智者見智了。

01

埋點需求混亂且缺少管控

產品和運營作為埋點需求的常見提出方，當新功能或活動上線時會提很多埋點需求，數據產品在這個環節如果對埋點需求沒有明確的提需規范和把控，就會導致埋點需求爆炸，對于開發和維護成本都是壓力，并且后續做數據分析的時候經常會發現數據不可用或數據不準確，那其實后續排查問題的成本非常大，所以數據產品一定要對埋點需求有全局把控。

1

明確埋點要統計哪些指標：

數據產品在評審埋點需求的時候很重要的一點就是：明確埋點要統計哪些指標。埋點統計是服務于指標的，如果對埋點需求沒有管控放任提需，經過幾個版本的迭代就會發現埋點維護很難，而且這樣也能反推運營和產品思考自己到底關注哪些核心指標，對后期的數據統計和復盤都是有幫助的。

2

明確埋點提需規范：

埋點需求規范的價值是幫助業務方和數據產品拉齊對即將開發的埋點認知一致，所以在設計埋點提需規范時不僅僅要讓業務方標明要統計哪些指標、事件如何規劃、觸發時機，最好能寫出每個自定義參數的觸發時機、參數打在哪個層級、是否需要透傳等，對于剛起步做埋點治理的階段可以先將精力focus在提需規范的設計和落實上，劃重點：埋點提需規范越詳細越好，可以幫忙拉齊各方對埋點的認知。

3

埋點需求評審會及設定需求接口人

埋點需求評審就不具體展開了，大體說就是將業務方、開發、測試、數據產品等組織起來對埋點需求進行評審。我想多說說需求接口人這個角色，進了大廠發現需求接口人很重要，沒有接口人的話僅靠數據產品跟業務對接在大體量和復雜業務場景的公司里是不現實的，所以接口人的定位是埋點需求master甚至是數據需求master，劃重點：建議接口人可以考慮經常對接埋點需求的業務或是有開發背景的業務方，這樣溝通起來會方便一些。

02

埋點設計環節缺少整體性思考

規劃埋點是數據產品的基本工作，但真正能做好埋點規劃很難，我覺得這個環節的痛點在于：很難以全局視角規劃埋點并且具有可擴展性，所以為了后續的可擴展性，我簡單列幾條可參考的tips：

1

埋點設計要具有簡潔性：

這里的簡潔性是指同類場景下的埋點是否能合并成一個埋點規劃，比如“點擊支付按鈕”事件，該事件在很多頁面都可以觸發，那么就可以把這個事件規劃為一個埋點，在不同的頁面點擊時將頁面名稱或頁面ID作為參數傳遞，但這些還是比較初階的埋點設計方案，當很多業務屬性以參數形式傳遞時，如何管理及規劃這些參數，讓數據RD看到埋點日志時很容易就能理解這條埋點攜帶了哪些信息，那么就引出來我要講的下一點：

2

埋點設計要具有規范性：

其實規范性這個詞很寬泛，我們通篇也都在探討如何基于埋點治理的痛點制定規范。上面講到我們如何管理埋點日志里的參數，我覺得可以按照性質和層級給這些參數進行個簡單劃分：

公共參數：每條買點日志都要上報的參數，包含設備信息、上報時間、ip地址等信息（這里不具體講，大家可以參考第三方數據分析工具如神策、GrowingIO等公共參數的采集），那么數據產品對于公共參數的設計和管理體現在要規劃號公共參數并協調各個埋點端上報格式一致，降低數倉解析成本私有參數：也叫自定義參數，每條買點在不同場景、不同操作、不同邏輯下會觸發并傳遞不同參數，此類參數叫做私有參數。

這里的層級指的是埋點日志的json層級，如果能做好json層級的劃分那么對于不同角色的RD可以按照自己關注的參數去解析，大大降低了解釋成本。

公共信息層：如果讀了上面的公共參數，那么會很好理解什么叫公共信息層：顧名思義就是存放公共參數層。

業務信息層：里面存放自定義參數，針對同類或同場景的采集信息可以抽象成一個對象，在對象里存放這些信息，例如上面提到的“點擊支付按鈕”事件，可以把頁面信息存放到一個對象里、位置信息存放到一個對象里，下面舉個巨簡單的栗子：

策略信息層：里面存放為策略服務的參數，之所以把它單獨劃分一層是因為策略多變且靈活，最好還是規劃在同一層級下管理。

透傳信息層：這種后端透傳前端的參數也建議單獨規劃，便于后續做鏈路追蹤等應用當埋點設計形成了規范，那么其實也完成了埋點最難的高度抽象的部分，接下來就是基于抽象好的規范甚至是數據模型來復用到后續的埋點規劃中，抽象的思路可以先關注重點場景：先設計核心指標有關的核心點位或者場景復雜的點位。

3

埋點設計要具有可擴展性：

埋點設計的可擴展性與上面的規范性密不可分，當規范建立好數據產品要思考是否具有較強的擴展性，還有后面規范的新增和變更該如何管理和維護。

要知道埋點不僅僅只是服務于指標統計，想要全面的規劃埋點還要設計分析產品性能、使用體驗的埋點，比如上報啟動時間、崩潰事件、頁面加載時間等事件。

03

埋點開發不規范

這個問題也很有意思，數據產品經常有個疑問：為什么我規劃好了的埋點，實際開發或上線后根本不符合預期。這個環節共設計到兩個角色：數據產品和埋點開發，那么到底是哪一方在溝通理解上出現了問題呢？

數據產品：技術背景較薄弱，針對不同開發環境和生態了解欠缺

埋點開發：了解開發邏輯，對于未明確的細節用慣用邏輯實現大家發現了嗎，當埋點場景復雜時，由于兩個角色的側重點不同很容易會出現gap，有人問有什么好的辦法去規避嗎？其實除了上面講的，只能不同角色補齊自己的短板，還有就是兩方一定要多溝通，埋點開發在埋點評審時要思考不同實現邏輯和異常場景是否會影響埋點上報，在開發埋點之前盡量把問題暴露出來。

04

埋點驗收不夠全面

埋點驗收環節作為埋點上線的最后一道保障，也是很容易踩坑的。具體的現象不多說，只說如何在驗收環節盡量不踩坑：

（1）驗收是否多報

（2）驗收是否少報

（3）驗收是否缺參數上報

（4）驗收上報參數是否符合預期

（5）驗收上報為空日志的比例

（6）驗收上報不符合預期日志的比例

除了上面的驗收重點，驗收方式一定要手動驗證+平臺自動化一起配合，最好能進行一遍回歸測試，多方式進行驗收。

05

欠缺埋點生命周期的管理

做埋點治理和數據治理的小伙伴應該深有體會，當缺少生命周期的管理一味放任熵增，后續治理的成本實在很高，所以埋點生命周期的管理必不可缺。簡單來說要做好后續埋點梳理、埋點瘦身、埋點升級的工作，定期統計一段時間內低頻上報的埋點和這些埋點相關指標、報表的訪問量，以此為依據開展埋點生命周期管理工作。

說了這么多，越寫越覺得想埋點想不踩坑對數據產品的要求實在很高，不僅要有需求管控能力、數據抽象能力，技術背景，還要有多部門協調能力和全局把控能力。所以本文也只能大體講講這些關鍵環節，但估計也是日常困擾大家比較多的問題了。

相信有此經歷的小伙伴們看到文章應該很有共鳴，歡迎留言交流～如果有更好的想法歡迎一起討論學習～

責任編輯：haq