一、背景

在文章云音樂曙光埋點：還原數據理想國中，我們介紹了曙光埋點項目方案，該方案基于多端一致埋點對象樹建設管理，實現了統一自動化埋點和鏈路追蹤，方案高度還原了大前端埋點的理想狀態、具備較強通用性和擴展性。我們圍繞這套埋點方案研發了配套的埋點管理系統，以承載及埋點規則數據管理、埋點設計、埋點研發、埋點測試、埋點上線等功能，本文主要介紹該平臺功能及建設思路。

二、平臺現狀介紹

經過前幾期建設，我們已經實現了一個適配研發流程的、按版本來管理的埋點數據管理平臺，其核心功能為：

• 1、承載埋點研發生命周期
• 2、承載埋點的元數據管理

我們的研發生命周期如下：

平臺在埋點元數據管理設計如下，參考和學習了版本管理工具的功能，并且充分考慮了客戶端的研發流程特點

• 1、客戶端每個大版本需求研發時，BI對埋點需求進行分類，建立需求組。可以理解為基于Master CheckOut出了多個分支。
• 2、BI在各需求組內，按埋點需求設計埋點。設計完成后，平臺會計算出埋點的變更列表，如新增對象、新增血緣關系、修改參數、刪除對象、刪除血緣關系。
• 3、上述變更由BI指派到任務，交由開發處理
• 4、經過一個版本迭代開發后，若任務開發測試完成處于可上線狀態，會被打上版本的TAG，并且發布上線，在Master產生一個新版本；未完成的任務，則可在后續版本迭代開發完畢后再上線。

相比版本控制工具，適配研發流程的版本控制具有以下特點：

• 1、支持部分變更上線：需求內的變更可以自由篩選出來部分上線，可以類比為分支內提交數個文件，可以篩選出幾個文件單獨合入Master
• 2、需要走研發流程才可上線：每個埋點變更都擁有獨立的研發流程控制和校驗。這些流程(設計完成->開發->測試通過)需要走完后，才準許合入Master。
• 3、模型更加復雜：不是簡單的文本，而是復雜的層級對象結構。

三、我們遇到的問題和痛點

在上述研發流程模式的落地過程中，我們發現了以下問題和痛點：

• 1、落地質量問題

漏埋：因為涉及較多埋點事件、埋點參數的組合，在某些組合下，埋點沒有上報。

錯埋：埋點參數缺失或格式不正確。

歸因錯誤：埋點里的歸因字段設置錯誤、不合理。

• 2、落地效率問題

• 大量重復埋點代碼編寫：如果涉及大量對象埋點，埋點工作勢必成為大量重復勞動，影響研發效率。

• 埋點進行增量變更時，無法知道改動了什么：平臺只展示了某個埋點全量信息，并未展示其增量改動（沒有類似版本管理工具的Compare視圖）。

• 3、功能痛點

• 有一些埋點長期停留在研發階段未上線（類比于寫代碼時開發分支落后Master多次提交，沒有去Pull Master獲取最新的主線代碼改動），導致這些埋點很可能是過時的，如果不進行卡點直接上線，就會導致問題

• 埋點數據是按APP+端兩個維度隔離的，但實際運用時存在內嵌情況，如APP端可內嵌WEB端H5頁面的功能，這種情況下，需要把原本隔離的數據進行整合，如把部分WEB埋點樹掛載在APP端樹上。

針對以上問題痛點，平臺在近半年內進行了針對性的解決。

四、埋點質量建設

解決該問題的思路為先解決源頭防止增量質量問題產生，再解決存量質量問題。

1、建設實時埋點校驗功能，從源頭解決埋點質量問題

客戶端埋點開發完成后，需要進行"實時校驗"，從而對被指派的埋點任務進行測試覆蓋，其步驟如下：

• 客戶端連接到實時校驗平臺，平臺根據該任務需求，生成埋點校驗樹
  
• 客戶端上報日志，平臺根據埋點校驗樹進行校驗
  
• 平臺根據測試情況，決定測試是否通過
  

需求范圍內有埋錯：不通過，且可以查看日志看到具體為何不通過，如下圖所示

需求范圍內有漏埋：默認不通過，但事實推進落地中，存在部分分支客戶端難以復現覆蓋的情況，因此我們也支持了勾選某些分支無需測試的功能，如下圖所示

• 若測試為不通過，則將卡點阻塞流程，后續無法正常上線
  

經過實時埋點校驗功能的上線后，我們封堵住了大部分埋點錯誤源頭，達到了較好效果。

2、建設線上埋點稽查功能，發現存量埋點問題并推進解決

稽查功能定位為企業日志的統計分析，解決以下問題：

• 1、分析日志是否按規則正確輸出，檢測出少參數、參數取值錯誤、歸因錯誤等問題，并對這類問題進行歸類，并可進一步鉆取，直至能夠看到原始日志的樣本。
  
• 2、自定義靈活業務統計監控、報表、報警。通過監控、報表中數值變化報警來發現、輔助定位端上發版后一些bug。如：某些點位日志變少、PV/UV比例變化等。
  

為實現上述功能，需要對日志進行采樣分析計算(可以理解為打上各種標簽)，并且將計算結果存儲在能夠支持篩選、統計查詢功能的數據庫中，為典型的OLAP場景，我們選型時，采用了ClickHouse來完成這塊功能，其主要考量點如下圖所示

經過稽查功能上線和推進，我們的線上埋點錯誤數已經下降了95%，并且還在逐漸降低中，達到了較好的效果。

五、埋點效率建設

• 使用模版引擎自動生成代碼 上文提到，埋點時涉及大量重復埋點代碼編寫，我們針對該問題使用模版引擎語言自動生成埋點代碼，且支持適配了安卓、iPhone、Web、RN等多套客戶端，把代碼提前生成好，能自動填寫的部分全部自動填寫，客戶端復制代碼后只需要把代碼模版里剩余部分補全即可，如下圖所示

• 展示埋點DIFF，讓開發更容易理解埋點改動點
  

我們開發了埋點DIFF功能，相比與版本管理軟件中的代碼文本對比，埋點元數據是一種更加復雜的數據結構，因此在服務端計算DIFF和前端界面展示DIFF上相對來說較復雜一些。如下圖所示，我們通過在原有界面上通過背景色來區分變更操作是新增、修改、還是刪除。

六、研發中埋點自動Rebase到最新Master

前文提到，有一些埋點長期停留在研發階段未上線，目前沒有pull master的功能，導致：

• 1、這些未上線埋點元數據很可能是過時的，如果直接上線會導致業務問題。
• 2、無法使用到最新Master下的新增對象，或者還在使用已刪除對象

因此我們對在需求池內未上線的研發階段對象，每次上線后，都自動pull master處理。如下圖所示為一個未上線需求從安卓8.8.11 Rebase到 安卓8.8.12的過程，rebase后可能存在部分變更需要刪除或重新研發。

rebase算法的核心在于計算出Master和本研發分支對比同一個基線的原子改動列表，并嘗試依次合并，并將合并后的變更應用到基線上。其流程圖如下：

其中變更合并時的邏輯如下：

人工沖突解決時，我們采用了上文“展示埋點DIFF”的功能，讓埋點設計人員同時看到兩方改動，并在界面中錄入最終合并結果。

七、埋點跨空間打通

云音樂業務存在多個業務線，他們的“埋點空間”是相互獨立的。但云音樂存在內嵌業務的情況，如云音樂APP下可內嵌LOOK直播APP、以及WEB端的H5頁面等，即使云音樂APP不發版，內嵌的業務的埋點也可能會發生變化。因此需要把內嵌業務對應的的埋點樹“橋接”到當前APP埋點中。針對這種訴求，我們研發了“橋梁”模式，如下圖所示:

• 橋梁為一類特殊對象，用于銜接父子空間，如圖示為銜接云音樂APP和WEB H5兩個獨立的埋點空間，其中云音樂APP是父空間，WEB為子空間
• 橋梁在父空間定義
• 子空間對象可設置掛載在父空間橋梁下
• 父空間展示埋點樹時，只關心到橋梁為止
• 子空間展示埋點樹時，會把橋梁以上所掛載的父空間樹也展示出來
• 內嵌開發完畢后，需要使用父空間APP驗證子空間的帶橋梁埋點是否正確，其SPM為帶父空間的完整路徑

此外由于埋點按版本管理，因此埋點樹若變化，必須要在平臺內產生新版本，因此：

• 子空間發布，父空間不需要發布新版本，因為子空間埋點樹對父空間不可見
• 父空間發布，若涉及橋梁更改，則會改變子空間埋點樹，此時需要在子空間同步發布一個新版本

八、未來規劃

在埋點領域中，除了純客戶端埋點，還有服務端埋點，以及雙端共同完成的混合埋點，常見的混合埋點包括：

• 服務端下發的字段，客戶端需要打到客戶端埋點里
• 客戶端上報的字段，服務端需要打到服務端埋點里

此類需求廣泛存在，但未在本平臺上進行管控，其流程、效率、效果是不可控、不可監控的，后續平臺將把服務端埋點及服務端+客戶端混合埋點也平臺產品化并進行管控。

此外，網易云音樂全鏈路埋點管理平臺前后端、客戶端SDK等組件都將在近期貢獻到開源社區，為業界帶來更大價值。