圖片來源：https://unsplash.com

本文作者：漁夫

背景

進入移動網際網路的下半場，以使用者行為資料分析驅動的演算法個性化推薦和人工精細化運營已成為各個產品必不可缺的配置，資料成為各產品的核心競爭力之一，各廠均開始致力於建設自己的資料倉儲和資料中臺。其中埋點作為網際網路產品的主要資料來源起著至關重要的作用，從下圖可見是整個資料鏈路的起源，決定了整個資料體系的質量和能力。然而埋點因其生產消費鏈路太長，表現不對使用者直接可見，過程中資訊傳遞和沉澱困難等原因，使得埋點往往存在問題多發現晚保障成本高等特點；且隨著業務發展到不同階段，對於資料埋點的能力訴求亦會變化，但往往後續治理也是非常困難。

雲音樂作為一個典型複雜內容產品，包含了多種內容介質（歌曲/播客/視訊/動態/評論/直播/歌房 等），多種組織形式（歌單/播單/專輯/話題/雲圈 等），多種使用者身份（音樂人/達人/普通使用者/主播 等），以及非常多內容分發場景（推薦流/搜尋/榜單/專區 等），具備了一個典型內容產品對分發效率敏感的特點，因此在整體流量/內容/使用者等多個域內都具有非常複雜的使用者消費資料和行為分析訴求。這對端上標準化和全面埋點提出了極高的挑戰，產品決策/BI分析/數倉開發/演算法推薦等諸多方面均需要有一套整體高效穩定標準化的埋點設計來支撐。然而過往歷史中，因方案建設不佳歷史包袱重，埋點一直是業務突出痛點，存在如下圖幾個方面問題。

基於此背景，筆者聯合網易杭州研究院及雲音樂內諸多部門成立曙光埋點專案，設計方案推動共建優化落地，目前已基本完成核心建設並在搜尋、播客、首頁推薦等核心業務上完成落地和資料改造，剩平臺的資料迴歸稽查能力、搭建打通以及若干易用性優化，以及更多的業務落地治理在22年收尾。

業界調研

要實現埋點提效提質，需要在埋點定位標準、埋點時機口徑、引數設定收集等方面進行良好設計提升資訊準確表達降低出錯可能，並且需要在各個環節開發各種工具和平臺去賦能，綜合觀察了業界各家的解決，整體在如下方面各有側重。

在坑位定位方面，鑑於大前端的DOM樹佈局渲染模型，很容易聯想到用坑位節點自身在樹上的位置去進行描述。基於此，Mixpanel、GrowingIO、神策、以及網易的HubbleData 等選擇了x-path描述法，因x-path全自動埋點量大及無更多業務引數，均結合端自動截圖，IDE和平臺結合，進行更多的坑位圈選引數設定；以及採用一些描述優化手段降低層級、型別和位置變化對ID的敏感程度。但始終無法從根本上解決定位描述的穩定標準化和不同端的一致性描述問題，方案難以應用到核心的業務報表，以及線上演算法使用上。

騰訊、美團、位元組、快手等建設結合坑位示意圖、引數管理進行面向坑位的埋點精確管理，定位描述由平臺隨機生成或策劃按預設規範輸入，埋點引數均由開發面向坑位手動設定無層級上下文彙總收集，並結合IDE外掛打通開發和測試賦能進行提效（可參考：位元組跳動大規模埋點資料治理最佳實踐）。其中美團在內部的動態佈局上與x-path找到了不錯的結合點，打通實現坑位圈選定位(x-path)和模型對應的引數配置，建設MTFlexbox上的視覺化自動埋點，實現了埋點的完全策劃/BI自助化。

阿里通過四段式SPM(站點.頁面.頁面區塊.區塊內點位)和SCM(投放系統ID.投放演算法ID.投放演算法版本ID.投放人群ID) 進行位置和內容的標準化描述，開發亦是面向坑位進行坑位進行標識和引數設定，無層級上下文彙總收集，在埋點上各端均做了AOP實現自動化，並通過截圖影像編碼打通平臺進行更多業務引數的視覺化配置。網易嚴選亦採用了與阿里相似的方案。

可以看到各個大廠在主流大產品中均未採用類x-path的定位描述自生成以及上下文引數依據彙總收集方面的建設。而云音樂早先亦採用相似的管理方案，坑位的定位描述採用過平臺隨機生成以及四段式SPM。但是由於雲音樂本身複雜內容社群型產品存在的大量資源分發組織形式，以及內部工程化建設背景，如下圖所示，一個歌單和動態均會在諸多場景和模組分割槽中出現，而採用業界現有的各種管理辦法，即使端上歌單卡片元件是統一複用的，但是其埋點亦需隨著場景組合情況的增加和呈現極大程度的擴張，使得埋點開發在工作量和質量以及標準化方面均一直很痛。

基於內容型產品本身業務和架構特點(後續會輸出文章進行專門講解和分析，敬請關注)，要徹底解決問題滿足業務需求，依然需要考慮類x-path型的頁面層級上下文自定位自彙總的方案，只是我們需要通過一定手段去解決業界一直未能有效處理的準確穩定一致性難題。

其中在上下文引數的自彙總收集方面：西瓜視訊基於責任鏈模式，在業務層進行了相關父子層級引數的彙總收集，不過會對業務存在較強的侵入性，且不徹底。騰訊PCG資料中臺的大同埋點平臺亦結合DOM樹的UI層級進行各級引數的自動收集和彙總格式化，但是大同管理平臺本身做得較差，且採集SDK的方案不夠徹底泛化，能力有限維護困難，未徹底走向虛擬物件樹建設這條路。

曙光方案

在曙光埋點中，考慮到x-path的位置描述其實存在較多無資料意義的層級且這些層級又往往隨著端上同學的樣式重構修改而變化(往往會有容器層級的新增或型別修改)，而在實際埋點中往往僅需要關注的是包含若干層級的資源卡片、模組頻道容器、互動元件等，如果可以僅將這些層級標註出來並進行自彙總，那麼定位的描述如果產品設計層面未發生需求變動的情況下，就是穩定易懂且可多端一致的(畢竟不同端上產品設計是一致的)。基於此，引入瞭如下所示的埋點物件概念，在整個DOM樹中，通過oid去標識所需要的物件層級(圖示意用，實際層級比畫出的更多，僅紅色-頁面和藍色-元素的層級進行oid標記)，藉助DOM樹的結構，自然形成了一個稀疏的埋點物件樹。

整個曙光埋點的基本思想就是要在端上(客戶端&跨端&前端)構建頁面的埋點物件樹並保持同步更新，實現頁面和元素曝光的自動埋點，以及通過使用者行為API的Hook實現點選的自動埋點。

如上圖示意，曙光建設了業務無感的自動埋點SDK，自動生成和更新頁面的物件樹，實現曝光和點選事件的自動化埋點，在坑位埋點生成時從對應節點往上查詢到根物件節點，收集樹支上所有節點業務設定的引數，即可自動生成坑位的標準化位置SPM和內容SCM描述；在此基礎上SDK內有序記錄了相關埋點事件，識別出途中使用者操作行為，直接在埋點生成時按約定格式生成和記錄refer引數，以進行高效準確的行為歸因。同時亦可以看出，該方案對於元件化的內容型架構特別友好，對於卡片在不同場景再複用再組織的情況，卡片本身是無需再重複埋點的。方案中涉及的相關引數標準和埋點結構約定如下，列出了主要關鍵引數及含義。

在此基礎上，建設相應埋點平臺來進行埋點需求管理、引數等後設資料管理、以及埋點測試和稽查校驗等，整體形成了如下流程：

回到上文的痛點分析，配合SDK和平臺，以及基於曙光埋點的後續UI自動化等的能力建設，我們針對於各個痛點的解決思路可以總結如下：

曙光SDK

曙光SDK是整個方案實現的核心，其整體包含內容如下，當前已完成Android，IOS，WEB，RN四端的支援：

為了更好標準化，我們將標準的事件限定成曝光和點選兩個大事件，再通過物件的spm和scm去區分詳細的事件業務含義。比如，老的埋點方案中(一般業界也多采用這類定義)，端上的關注事件會定義EventCode為"focus"，在曙光中會直接定義成可以發生關注行為的元素點選操作(一般會採用相同oid==btn_focus來統一定義)，故整體上點選事件的表現力是比較充分的。而曝光上，我們區分了頁面和元素，頁面的曝光和反曝光會觸發對應節點往下的元素曝光檢測，且頁面節點依據其所處層級不同有根頁面和子頁面區分，但業務開發無需關心，只需API設定elementOID和pageOID。基於此，SDK的基本核心功能就是在各端通過SDK去實現頁面/元素曝光和點選事件的自動埋點，並自動記錄和關聯使用者行為。目前在Android、IOS、WEB三端的SDK處理流程如下圖所示。

圖中關鍵流程：通過系統AOP觸發樹更新，在主執行緒依據頁面實際DOM樹的遍歷過濾出OID節點生成虛擬樹，將樹更新事件推送給曙光工作執行緒去進行檢視的可見遮擋交叉判斷以進行曝光埋點的自動生成，進而在工作執行緒依據樹結構進行埋點節點的樹枝回溯收集相關節點的引數進行架構化；同時在工作執行緒中維護了使用者行為鏈路的refer引數（由頁面曝光、元素點選、使用者自定義和插入refer組成），這些refer引數會在埋點中被直接帶上，供資料側消費歸因。

圖中綠色圓圈為開放給業務開發使用的API，其包含了節點的引數設定、主動觸發重新整理（部分極特殊情況頁面更新未被AOP的業務可自行觸發）、自定義埋點事件、未AOP的Refer插入等四部分，整體操作很輕量，最主要的節點引數設定API與各端給View設定顯示資料的實際可保持一致，且各層只需關注自己的引數，所處的父級模組、頁面等資訊由SDK在埋點回溯時自動收集。

當然這是理想狀態下的主流程，在整體方案中在前端和客戶端均會存在特殊情況需要去抹平，如圖中粉色背景的方塊中，在生成vTree的過程中，為了儘可能達到多端一致，以及滿足業務資料需求的情況，我們支援了邏輯掛載來將一個節點脫離本身View父子關係建立新的父子關係（如上圖左，點選歌曲更多開啟的浮層可能是一個獨立Window，與歌單頁和內部的元素無父子關係；但是在資料分析上，會希望看到浮層內的各個點選可以看到歌單頁以及對應歌曲卡片的資訊，這時候可以選擇將浮層物件邏輯掛載到歌單卡片或者歌單頁物件下），以及虛擬層級以支援對原本不存在的View父子層級增加一個可分析的資料層級（如上圖右，對於模組內的各個歌單和歌曲卡片以及頭部的更多、播放按鈕的埋點事件，會需要知道所屬的模組資訊，但端上可能並不存在整個模組的層級--圖中紅色虛線，只是頭部和下方橫向滾動列表在整體列表上的拼接假象，對於端開發同學為了減少UI層級這種情況是比較常見的，此時可以通過增加一層與虛線紅框對應的虛擬模組節點來快速達到目的）。

SDK內對於View的曝光可見性也做了較為完備的擴充套件支援和判斷，業務可以通過API去修改View的實際Frame(顯示Rect，以便支援半透實際背後可見等情況)。同時，在曝光檢測中，也以節點的可見區域和樹結構，做了嚴格的遮擋對比判斷，整體原則和流程如上圖所示。

如上為Android、IOS、WEB三端的整體情況，其中WEB端的方案基於DOM而非VDOM操作，可以適配各種不同前端技術棧。對於RN類Native渲染的跨端平臺，其在JS端保持與WEB端相同的Component配置API，然後客戶端通過ViewManager擴充套件屬性，將相關節點配置對應到Native側的實際View節點即可，其他流程與原生是一致。另外，對於Flutter，Android端的Compose這類渲染框架，亦可在其實際佈局節點樹上找到切入點，構建出對應的埋點物件樹結構，更多端後續會繼續支援，同時SDK計劃今年開源，更多細節屆時再披露。

Android端BaseViewManager中擴充套件：
@ReactProp(name = "eventTracing")
public void setEventTracing(@Nonnull T view, @Nullable ReadableMap eventTracing) {
  // 呼叫客戶端側曙光埋點SDK的節點設定API
}

IOS端RCTViewManager中擴充套件：
RCT_CUSTOM_VIEW_PROPERTY(eventTracing, NSDictionary *, RCTView) {
  // 呼叫客戶端側曙光埋點SDK的節點設定API
}

除了SDK的核心功能之外，曙光專案還開發了一個工具，以支援各端直接進行物件和層級檢視，輔助開發測試，並且隨著方案的落地和標準數倉的開發，後續亦可在端上直接做資料視覺化，整體效果如下，具體細節不再贅述。

EasyInsight

EasyInsight是曙光建設的埋點管理平臺，在資料埋點的事前中後均起著非常重要的作用，平臺的整體包含的功能簡介如下圖所示，其中已經完成的為需求管理和引數管理，以及測試稽查中的需求測試部分。有關回歸稽查、動態取參、以及後續更多擴充套件開發寫此文時尚在進行中。

事前其承載埋點後設資料管理，埋點需求提出、埋點設計、評審和任務分配。

事中開發同學依據物件詳情頁裡的引數需求，依據層級(血緣)關係判斷合適的層級和元件進行埋點引數設定，平臺在物件層面維護了有關物件和SPM所需的各種公參私參，對相關引數的取值情況進行配置，並通過父物件的維護構建起一個個複用下頁面的物件樹，同時還提供了血緣樹的完整視角，更顯直觀。

事後平臺提供了需求維度的自動化測試工具，以及版本能力的整合灰度和線上資料稽查功能，開發可快速自行驗證後上線。需求測試中，開發通過二維碼掃描與平臺socket連線，保障埋點資料的實時性，並與平臺上維護的物件關係和引數配置生成的埋點規範進行對比驗證。而回歸稽查功能要更復雜，尤其對於客戶端大量需求整合集中發版的情況，我們做了不少工作結合內部的研發管理工具與EasyInsight打通，關聯版本相關任務的程式碼合併狀態，在平臺找到合適的版本與其產生的埋點ODS分流後進行撞庫校驗。測試和稽查的結果均有完整的報告和IM通知輸出。

EasyInsight除了埋點開發過程管理外，埋點上線後其上沉澱的後設資料和物件資訊，亦是後續數倉開發、BI分析、演算法使用的主要內容；同時相關的視覺化敏捷資料分析能力亦在建設中，基於整體資料埋點的高度標準化，常見的多維、漏斗、留存、路徑等分析訴求，可以簡單快速拖拖拽拽進行配置檢視。

資料治理

曙光埋點建設時，雲音樂已經存在了諸多版本的埋點資料，多種口徑和規範並存，整體的資料使用較混亂，在方案落地時深感不進行全面的改造和梳理對齊，新的埋點體系建設得再好如果僅是覆蓋新需求不管老埋點，各種業務報表以及業務和演算法任務混用時，亦是無法保障準確性的。因此，新方案建設，新埋點開發落地，老埋點梳理對比驗證三條腿缺一不可，均納入了曙光專案的範疇內。過程中牽動資料開發、策劃、BI、演算法以及各個業務服務端開發進行了詳細的舊使用梳理，並也以此為契機將雲音樂的數倉能力豐富標化建厚。

整體的新老資料相容方案如下圖，由於埋點的改造不是集中投入一次改完，是隨著業務迭代持續進行，故需要對老埋點進行口徑的二次梳理(將老的非標化的埋點依據各種引數條件通過UDF對映成一個偽spm)，依據新老spm對映通過中間表相容新老資料，將原本下游直接從ods直接分流使用(圖中紅線)的任務切換到統一的中間表或相容流量表上。

相容表的流量切換，EasyInsight也提供了工具化支援，如下圖所示：

後記

曙光在完成埋點落地和資料治理的同時，雲音樂也已經基於曙光多端一致明確的oid和spm，解決了業界基於x-path和Accessibility的各種UI自動化方案未曾根本解決的物件準確快速查詢和用例穩定性差及執行效率低問題，建設了全新的自動化方案取得了很不錯的效果（後續會再寫一篇文章總結下大前端的各種自動化方案的建設思路和痛點以及基於曙光的自動化方案，敬請關注）。同時，以曙光為基礎的更為完備的安全風控策略，新AB系統，以及視覺化分析能力，也在啟動進行中。曙光埋點起於埋點但意在更多，這也是如開頭腦圖所示最初立項所預期的。

資料埋點治理是一個極辛苦且困難的事情，如同在給一輛高速行駛的火車換輪子，在任何一個公司做起來都不會輕鬆，有幸在雲音樂得到了老闆的支援，跨團隊圈了幾位很不錯的小夥伴，在相對投入很小的情況下用不長的時間就做到了很不錯的完成度。期間困難重重，專案團隊同學們幾度沒了信心，不過最終都挺過來了。隨著核心業務的落地和業務的切換反饋，各方對其也投入了越多越多的重視和期待。回望來路感恩滿滿，能夠將心裡長期設想的資料埋點理想國還原出來，是一件人生幸事。

本文釋出自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們 grp.music-fe(at)corp.netease.com！