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

做埋點時間長了，越來越覺得埋點并不像自己想象的那么簡單，僅僅是開發(fā)在自己要統(tǒng)計的業(yè)務(wù)場景下寫埋點代碼打包上傳統(tǒng)計數(shù)據(jù)就完成工作，從最開始的埋點需求規(guī)劃再到最后數(shù)據(jù)上報只要有一個環(huán)節(jié)有坑就會影響數(shù)據(jù)準(zhǔn)確性，而數(shù)據(jù)準(zhǔn)確性估計是每個數(shù)據(jù)人工作中必須要面對的難題。

下面簡單聊聊自己遇到的坑，這些或許僅僅是表述了現(xiàn)象，至于導(dǎo)致此現(xiàn)象發(fā)生的本質(zhì)相信就仁者見仁 智者見智了。

01

埋點需求混亂且缺少管控

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

1

明確埋點要統(tǒng)計哪些指標(biāo)：

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

2

明確埋點提需規(guī)范：

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

3

埋點需求評審會及設(shè)定需求接口人

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

02

埋點設(shè)計環(huán)節(jié)缺少整體性思考

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

1

埋點設(shè)計要具有簡潔性：

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

2

埋點設(shè)計要具有規(guī)范性：

其實規(guī)范性這個詞很寬泛，我們通篇也都在探討如何基于埋點治理的痛點制定規(guī)范。上面講到我們?nèi)绾喂芾砺顸c日志里的參數(shù)，我覺得可以按照性質(zhì)和層級給這些參數(shù)進行個簡單劃分：

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

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

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

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

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

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

3

埋點設(shè)計要具有可擴展性：

埋點設(shè)計的可擴展性與上面的規(guī)范性密不可分，當(dāng)規(guī)范建立好數(shù)據(jù)產(chǎn)品要思考是否具有較強的擴展性，還有后面規(guī)范的新增和變更該如何管理和維護。

要知道埋點不僅僅只是服務(wù)于指標(biāo)統(tǒng)計，想要全面的規(guī)劃埋點還要設(shè)計分析產(chǎn)品性能、使用體驗的埋點，比如上報啟動時間、崩潰事件、頁面加載時間等事件。

03

埋點開發(fā)不規(guī)范

這個問題也很有意思，數(shù)據(jù)產(chǎn)品經(jīng)常有個疑問：為什么我規(guī)劃好了的埋點，實際開發(fā)或上線后根本不符合預(yù)期。這個環(huán)節(jié)共設(shè)計到兩個角色：數(shù)據(jù)產(chǎn)品和埋點開發(fā)，那么到底是哪一方在溝通理解上出現(xiàn)了問題呢？

數(shù)據(jù)產(chǎn)品：技術(shù)背景較薄弱，針對不同開發(fā)環(huán)境和生態(tài)了解欠缺

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

04

埋點驗收不夠全面

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

（1）驗收是否多報

（2）驗收是否少報

（3）驗收是否缺參數(shù)上報

（4）驗收上報參數(shù)是否符合預(yù)期

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

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

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

05

欠缺埋點生命周期的管理

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

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

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

責(zé)任編輯：haq