作者介紹
@九果
入行大資料8年；
某大廠資料産品經理；
專注于資料産品，并持續學習中；
“資料人創作者聯盟”成員。
01 為什麼要做埋點管理系統？
備注：如果您已經知道為什麼要做埋點管理系統了，可以直接跳去第三節看埋點管理系統的建設過程。如果還沒有很好的了解過埋點管理系統，建議從頭開始讀起，本文章小長，但是一定有幹貨哦，建議好好讀完！
如果你是一名資料分析師，是否有過這樣的經曆，當你需要查詢APP産品埋點資料的時候，你不得不經常找資料産品經理去确認是否已有埋點，埋了哪些字段，是否已有上報資料等，常常這些埋點事件元資訊分散在多個産品經理手上，資訊散亂，分析師使用埋點資料之前溝通成本極高，影響資料使用的效率……
不僅如此，我們還會遇到埋點資料異常，追溯埋點曆史問題過程也是非常的漫長，需要資料産品經理去跟業務産品經理确認埋點需求的版本，然後資料産品經理确認埋點設計需求的批次，然後給到開發，開發同僚再去查找問題……
以上種種問題場景相信大家都經曆過，且一直是困擾着我們的痛點。
埋點場景的痛點我總結為以下5點：
- 埋點需求及埋點設計文檔管理散亂，産品，開發，測試協同溝通效率低下，嚴重影響工作效率
- 埋點事件元資訊管理散亂，常是分布在多個産品經理手上，分析師使用埋點資料時需要查詢埋點需求及埋點事件的元資訊這個過程鍊路長，溝通成本非常高，埋點元資訊使用查詢極其不便利
- 若出現埋點資料異常問題，若開發同僚需要追溯埋點曆史資料，則更是需要有當時的埋點需求批次和埋點設計文檔作為輔助，這時候的埋單需求文檔和埋點元資訊的統一管理，對于曆史問題追溯問題的效率有極其大的幫助。
-
非可視化測試，驗收埋點難度太大。
每次都要跑去資料庫了查詢，對于沒有寫SQL基礎的業務經理來說，驗收埋點資料的效率就會比埃及地下。
- 資料校驗流程混亂，版本管理難度大，開發同學常常要自己開發一個背景管理功能來管理埋點釋出或下線的版本
02 埋點管理系統是什麼？
有沒有比較好的方法解決以上問題呢，答案是有的！就是我們下面要介紹的埋點管理系統。埋點管理系統是做什麼用的？埋點管理系統為啥在資料産品體系中相對少聽到，為什麼業内也沒有非常出名和成熟的産品？
埋點管理系統本質是解決資料采集及資料使用場景問題的業務系統，業務方則是資料産品、資料開發工程師、資料分析師等資料團隊的人員。
在業務尚處于快速發展的階段，資料團隊的上司更多關注的是為業務團隊提供資料産品，而通過給資料團隊提供資料工具來提升資料服務的效率，這個問題一般是在資料團隊的服務能力相對穩定和成熟之後才會去落地。也就是當大家的KPI都是在滿足業務的資料需求的時候，隻要有可替代的方案，上司會更願意暫時用着替代方案去解決這個問痛。
比較常見的例子，資料分析師在業務處于快速發展的階段就大機率隻讓你取數，未必讓你真正的去做業務資料分析的活兒。等資料取數這類需求達到一定的數量，老闆才會想着去開發可視化類的取數工具，幫助資料分析師從大量的資料查詢和報表開發的工作解脫出來，去做更加有價值的業務專題分析的工作。
回到主題，埋點管理系統也常常會等到埋點需求非常多，從埋點需求産出端到埋點需求使用方都感覺到這個合作流程已經影響了整體的工作效率的時候，埋點管理系統才會被老闆想到，這個工具是否可以替代原本的零散和低效的協同模式來提高大家的工作效率。是以，埋點管理系統本身是一個提升資料同僚工作效率的工具。
埋點管理系統能解決問題主要有以下5點：
- 通過統一管理應用産品及埋點設計，解決了埋點需求及埋點設計管理散亂，産品團隊、開發團及測試團隊，資料應用團隊的協同溝通效率低下問題。
- 通過統一管理埋點事件的元資訊，解決了資料應用場景中需要高頻及便利的查詢查詢埋點事件元資訊問題。
- 通過統一的埋點需求管理及事件元資訊管理，解決了開發同僚在遇到埋點資料異常需要追溯曆史埋點。
- 通過可視化抓包，解決了埋點資料驗收的重度依賴資料庫查詢的相對低效的方法。
- 通過可視化對比校驗和釋出／下線能力，解決了開發同僚單獨管理埋點需求的版本及釋出場景問題，并有明确的資料校驗流程，進而間接提升資料品質的管理。
03 如何設計埋點管理系統？
01 業務流程确認
說了埋點管理系統能解決的問題，接下來聊聊埋點管理系統長啥樣，如何才能設計出解決我們以上問題的埋點管理系統。在此之前，我們先了解埋點場景的業務流程：
圖一：埋點業務流程圖1
接下來将按照埋點涉及的角色和流程節點兩個次元一起闡述：
在需求階段：業務團隊跟資料産品團隊提出埋點需求，資料産品團隊會根據使用者的當期及未來的統計需求，确認增加哪些埋點，并通過拆解埋點需求名額，輸出埋點設計文檔；而後，産品團隊跟大資料開發團隊進行埋帶設計需求的評審，評審通過之後再上線開發。
埋點開發階段：開發團隊同僚按照資料産品經理提供的已評審過的埋點設計文檔進行開發；開發自測完成後會提測給測試同僚，測試同僚按照埋點設計文檔進行功能和資料的測試；測試通過後，資料産品經理将進行埋點驗收，産品經理不但要按照埋點設計文檔驗收事件及事件參數的完整性，也要去資料哭驗收埋點資料的準确性。
埋點應用階段：埋點上線後，資料分析團隊就可以直接去按照埋點設計文檔去資料庫查詢提取埋點資料進行分析應用了。這個過程，分析師一般需要先跟産品經理先過一遍新上的埋點設計文檔後再開始使用資料。
埋點回收階段：埋點也是有生命周期的，有開始時間也會有結束時間。若産品已經下線，且後期将長期不再需要使用這些使用者行為資料了，基于海量資料存儲成本和資源浪費力的角度考量，企業會願意将這類埋點下線。一般并不會直接下線，辨別上可以下線的辨別後，一般過3-6個月依然不再被範圍調用，則執行下線。
02 系統功能确認
業務流程确認了，我們就在對應的業務流程上增加産品功能子產品去承載每個業務流程節點的需求，如下圖：
圖二：埋點業務流程圖2
03 系統功能架構
通過埋點業務流程的梳理，得出了多個系統功能子產品，拆解出來的埋點系統功能結構如下圖：
圖三：埋點管理系統功能結構圖
在功能結構圖中提到了應用、埋點需求、事件、屬性等對象，在展開闡述每個功能子產品之前，我們先了解一下埋點管理系統裡涉及到的全部管理對象及對象之間的關系。
圖四：埋點事件模型圖
埋點管理系統一共涉及到四個對象，分别是應用、埋點需求批次、埋點事件、事件屬性。他們之間的關系是自上而下的邏輯關系。比如在系統的埋點需求管理子產品，篩選出一個應用名稱，則對應展示的是選中的應用下面的所有埋點需求清單，選中單個埋點需求批次的時候，對應展現的就是這個批次下面的所有埋點事件。了解到此，下面我将分别展開介紹每個子產品的功能：
1）應用管理
應用管理功能主要是承載業務團隊新增一個APP/小程式／H5／web端等業務産品對象，我們需要在系統裡先建立一個新的埋點産品對象，然後才有後續增加的埋點需求及事件元資訊等。這個子產品包含應用新增、删除、編輯等基礎功能。産品團隊需要負責的埋點産品都可以放在這裡統一管理。
圖五：應用管理清單圖
2）埋點需求管理
埋點需求管理功能主要承載集中管理業務團隊提過來給産品團隊的埋點需求文檔，這裡可以建立需求、編輯需求、下鑽需求、下線需求等。在這裡，需求按照批次來進行管理，每一個埋點需求都有一個唯一的批次号，挂載到對應的應用及版本上，并且點選單個埋點需求批次号，可以直接下鑽到該埋點需求下的全部事件清單。
圖六：埋點需求管理清單圖
3）事件管理
事件管理功能則承載來所有埋點需求拆解出來需要開發的埋點事件元資訊，這裡可以建立事件、編輯事件、下鑽事件、搜尋事件、下線事件等。事件是埋點拆解的最小對象單元，在這裡每個事件都要挂載在對應的埋點需求批次上，系統裡沒有獨立自自己遊蕩的事件。這樣所有的應用、埋點需求批次和事件都有了映射關系。當需要使用埋點資料時，先來埋點管理系統查找埋點需求批次，這種清晰的映射關系在查詢埋點元資訊時提供了高效的途徑。
圖七：埋點需求管理清單圖
4）屬性管理
屬性管理功能子產品承載的是常用的有共性的屬性。一個個獨立的屬性常用屬性，比如用使用者ID、使用者用戶端系統、線上時長等屬性，可以在屬性管理這裡完成注冊。在使用者建立事件時，可以直接引用已注冊完成的屬性綁定到事件上，減少使用者填寫事件屬性資訊時的大量重複填寫工作。
5）埋點校驗
走到這裡，埋點已經開發完成了，到了測試、驗收、上線的環節。這裡的埋點校驗包含兩部分，可視化抓包測試及開發環境和測試環境的資訊對比。完成這兩個環節之後，開發同僚才可以把埋點釋出到正式環境。
可視化抓包測試
可視化抓包功能頁主要提供給産品經理和測試同學可以現場抽樣測試事件資料，檢查上報的屬性是否已經完整，屬性值是否準确。
圖八：埋點資料實時抓包圖
對比與同步：
線上對比和釋出功能頁則是承載了開發童鞋對比生産環境和測試環境埋點元資訊的差異之處，幫助快速确認已經進行了變更處理之處。及支援開發童鞋線上可視化釋出埋點事件，便捷高效。
圖九：埋點需求對比及同步功能圖
6）埋點監控
埋點監控功能承載的則是埋點管理系統全部埋點事件的及任務運作的結果監控。包括展示全部埋點應用統計數、埋點需求統計數、事件統計數、有效線上事件統計數、異常的埋點事件數、未處理的埋點需求／事件數等，是統計和展示整個系統管理對象及對象運作情況的監控功能子產品。友善參與埋點工作的同僚了解整體産品的埋點任務運作情況，和及時發現埋點上報資料的異常情況。也是埋點管理系統的一個必不可少的子產品。
總結
以上從埋點管理系統的定位和解決的痛點問題，及系統的建設過程給大家闡述一遍，希望能幫助大家在對埋點管理系統及建設有個相對完整的認識。
最後，總結幾點系統建設過程中的思考及注意事項分享給大家：
1、埋點管理系統是一個服務于資料團隊但涉及合作團隊較多的系統。在不同公司，可能埋點業務流程不一樣，而我這裡分享的是我經曆過的埋點工作場景中協同效率比較高效的埋點業務流程，希望能提供參考借鑒。
2、埋點需求批次跟應用版本号不完全保持一緻，不要當作是形同對象而互相替代。因為很可能在後期版本增加早期發版的産品功能的埋點。如果當作同一個問題處理，将導緻埋點需求管理能力可擴充性太弱，很快整個系統都陷入了管理瓶頸。
3、埋點管理系統真實可以提升業務、産品、開發、資料分析多個團隊的協同效率，用起來非常爽，能早建設盡早建設。
此處完結。
如果大家對埋點管理系統有其他的經驗分享或者問題，歡迎找我交流～