一、引言

隨著大數據技術的不斷發展，從IT時代到DT時代，再到AI時代，埋點技術也在不斷升級和改進。從Hadoop技術體系到如今的AI技術體系，埋點的應用場景和價值不斷擴大和提升。在AI時代，埋點的重要性更加突顯，因為AI技術的發展離不開大量的數據支持，而埋點正是收集和存儲數據的關鍵。埋點的價值在于能夠收集數據、存儲數據和分析數據，為數據分析和決策提供有力支持。

在技術升級的同時，埋點的應用也越來越廣泛。從營銷分析、產品優化、運營管理到用戶畫像等多個領域，埋點都有著重要的應用。而在這些應用中，埋點的作用也逐漸從簡單的數據收集轉變為更加智能化和個性化的服務。通過埋點收集的數據，企業可以更好地了解用戶需求、行為和偏好，進而提供更加優質的產品和服務。

總之，埋點是大數據時代不可或缺的核心數據來源，其價值和作用在不斷擴大和提升。在未來的數據時代，埋點將繼續扮演著重要的角色，為數據分析和決策提供有力支持。

二、埋點工具概覽

在埋點研發過程中，埋點工具起到了非常重要的作用。一些常見的埋點工具包括SDK和web請求抓包等輔助工具，可以幫助業務進行埋點以及驗證，有利的工具可以提高埋點的效率，并確保埋點數據的準確性和有效性。

埋點工具集主要包括埋點需求管理工具、埋點驗證工具、埋點數據采集工具和埋點數據查詢四部分。

• 埋點需求管理工具是一個重要的工具，它可以幫助數據產品人員更好地管理埋點需求，對埋點數據進行分析和瀏覽，為后續埋點工作提供支持。
• 埋點驗證工具則是對埋點數據質量進行驗證的工具，主要包括數據抓包和驗證，確保全鏈路數據埋點的數據質量。
• 埋點數據采集工具主要負責將埋點數據進行采集，確保線上數據的正常有效采集。
• 埋點數據查詢則是將采集到的數據進行查詢和分析，幫助企業更好地了解用戶行為和需求，為業務決策提供數據支持。

三、埋點需求管理

知乎埋點需求管理平臺的演進，以簡化埋點設計流程為主線，同時也注重降低設計成本，提高效率和易用性，使其能更好地滿足軟件開發人員和項目管理人員的需求，增強其生產力。

從1.0版本升級到2.0版本，知乎埋點需求管理平臺主要改進在兩方面。一方面，降本增效成為該平臺升級的核心思路。這不僅能幫助開發人員和項目管理人員專注于軟件開發和項目管理本身，減少因繁瑣的埋點設計流程占用時間和精力的困擾，同時，增效功能可以更快地完成埋點設計，提高團隊整體工作效率。另一方面，簡化整個埋點設計流程也是該平臺升級的重要改進之一。1.0版本中，埋點設計流程較為復雜，需要進行多個步驟的配置，給用戶帶來了較高的操作難度和學習成本。2.0版本中，知乎埋點需求管理平臺將多個步驟整合成一個流程，大大簡化了用戶的操作流程，提升了使用體驗。

為了更快捷、高效地完成需求復制，并對不同場景下的埋點差異進行比較，我們提出了一項智能化的功能。該功能可以根據需求，快速生成埋點代碼，并通過流程化的方式，將各個流程中涉及到的埋點需求、內容及時傳遞給相關負責人，以確保整個流程的清晰明了。

四、埋點驗證

經過前期埋點需求設計與開發的緊密合作，現已順利完成該項目的關鍵節點——埋點驗證功能的設計與開發。相較于之前單點抓包自行驗證的方式，此次的升級采用了平臺化的驗證方案，這一改進顯著提升了測試效率，為數據質量的保障奠定了堅實的基礎。

作為知乎埋點功能的1.0版本，本次升級至2.0版本，主要體現在單點抓包自行驗證的方式已經成為過去式，取而代之的是平臺化的驗證方案。這一變革不僅為埋點功能的應用提供了更高效的驗證方式，同時也提升了整個埋點驗證過程的質量，為后續埋點功能的運用奠定了良好的基礎。

數據驗證功能1.0升級到2.0版本主要有以下幾點的改善:

• 技術上從單點架構升級到云原生高可用的保障方案,引入消息隊列中間件，支持無狀態多節點部署，避免單點故障，保障業務系統的高可用。
• 埋點測試可以快速綁定埋點需求，進行埋點測試，并生成相關測試報告。

五、埋點數據采集

1.0版本的采集服務系統整個流程為，由客戶端上報后，埋點數據會先經過服務本地緩沖隊列，再進行線程轉發給消息隊列Kafka。1.0版本經歷了5年的時間，采用python代碼開發，代碼臃腫，數據處理機制延遲較高，隨著時間的推移后續迭代變更風險呈指數級增長，1.0版本的缺點由于本身的架構限制而日益凸顯。

2.0版本采用平臺級別的數據采集方案，仍然以消息中間件作為與數倉溝通的橋梁，但臃腫的數據處理機制全部重構，內部數據兜底策略使用多路消息中間件作為backup，可讓數據輸出直面消息MQ提示整體的處理能力，整個數據鏈路計算耗時縮短為之前的1/15（延時基本保證在30ms以內）。除此之外為了保證迭代的安全性，根據不同的埋點數據處理流程提供單獨的處理器實例，可實現快速的橫向擴展，這樣引入新的數據處理機制時可減少變更風險。

六、埋點數據查詢

埋點數據查詢工具，主要面向人群為運營、分析師、產品角色的同學，供其進行數據查詢分析使用。整體架構是建立在數據服務上的，以Web-API的方式查詢數據服務，數據查詢功能和底層數據模型和存儲進行架構分離，使用上通過配置可以快速生成API，使得效率大幅提升。

為了提升業務的高頻訪問速度和用戶體驗，我們針對不同的需求定制了精簡化的維度設置，例如在product、國家、地區等方面，我們選用了具有強大處理能力的Doris底層架構，以便更加高效地處理海量數據。另外，為了滿足埋點數據產品平臺的高性能查詢需求，我們選擇了基于Hive的Presto引擎作為底層數據查詢引擎，能夠輕松支持大規模的數據離線以及實時查詢任務，提供更快捷、精準的查詢結果。

七、埋點服務

埋點數據查詢基于基礎數據服務，其主要包括三點核心設計：數據集成、邏輯模型以及云原生。

數據服務主要解決如下問題：

• 數據集成，降低異構數據接入成本；針對不同的數據結構和使用特點，會通過數據產出任務導入不同的中間存儲，對外無感知。
• 通過邏輯模型解決接口和物理模型無法復用的問題；可有效避免煙囪式的開發模式；邏輯模型是虛擬的能夠解決掉面對同一物理模型而需要關注不同的列的需求，避免數據重復加工，而且其本身并不產生落盤數據，而是在查詢時動態獲取數據，這樣也使數據通過api對外共享成為了可能。
• 全鏈路關系的打通；有了數據服務后，對外界暴露的數據就可以通過api來實現了，應用發布api以后，我們可以通過物理模型本身的數據血緣所對應的邏輯模型中去打標簽，標簽是根據上層的數據應用涉及的具體頁面接入是生成的，這樣就可以和原本物理模型的數據血緣可以組成全鏈路的數據血緣關系；當上層數據應用接入或者下線時，我們就可以條件或者清除掉對應的標記；這樣不但能解決掉數據加工任務異常時無法根據應用的重要性排列恢復優先級的問題，而且還能解決掉數據下線時不知道哪些業務引用了的難題。 
• 防止基礎表字段變更對上層應用造成影響；底層物理模型變更其實是比較頻繁的事情；因為匯總層的模型也一直在隨著業務需求去做完善和優化，所以基礎的字段增刪以及修改會經常發生，如果沒有數據服務通過接口的方式提供查詢，就會出現字段變更之后需要強推業務修改代碼重新上線，這是非常不合理的，數據服務邏輯模型可以避免掉這個問題，可以通過物理字段和邏輯字段的映射關系達到對用戶訪問透明的效果，這樣就消除了數據訪問字段強依賴的問題。

八、提問環節

Q1: 埋點需求流程中參數設計及上線由哪個角色負責比較合理？

A1: 知乎埋點流程是由整體的數據產品把控的，業務產品進行需求規劃和建立，數據產品根據業務需求進行埋點設計，后續埋點開發、驗證到上線驗收也是由數據產品進行整體閉環掌握。

Q2: 用戶端的行為session，客戶端上報還是服務端上報比較合理？

A2: 在用戶體驗和數據分析方面，用戶Session的設計和實現是至關重要的。通過對Session的不同類型進行深入了解，可以更好地把握用戶在不同頁面和應用場景下的行為特征。同時，SDK方案的優化也可以幫助提高代碼質量，更好地保障行為質量。這些都需要通過精細的端上控制來實現。在具體實現方面，端上對Session的管理是非常關鍵的。在不同的場景下，用戶的行為會呈現出不同的特點，例如在網頁中，用戶的行為通常是點擊、滑動、搜索等操作；而在移動應用中，用戶的行為可能會涉及到應用的啟動、加載、操作等多個環節。因此，我們需要通過深入分析用戶的行為特征，從而對不同類型的Session進行細致的劃分和設計。另外，SDK方案的優化也是提高行為質量的關鍵之一。SDK方案可以通過優化代碼邏輯、提高性能、降低延遲等方式，來幫助我們更好地捕捉用戶行為數據。在這個過程中，我們需要對用戶行為進行分析和預測，以便更好地優化SDK方案，從而提高用戶的滿意度和體驗。總之，對于用戶Session的設計和實現，我們需要充分了解不同場景下用戶的行為特征，通過精細的端上控制和優化SDK方案，來保障用戶行為的質量和數據的準確性。這需要我們不斷探索和創新，以更好地滿足用戶的需求和期望。

Q3: 什么樣的埋點體系才是很好的埋點體系？

A3: 根據公司業務業務需求特性落地，核心包括(1)流程規范性保障，從埋點需求到埋點設計、再到埋點開發和測試和驗收整個流程上保障一致性。(2)全鏈路數據質量保障，通過埋點工具保障埋點設計和埋點生產數據保障一致。

Q4: 業務產品版本，埋點版本和前端功能版本之間的關系是怎么樣的？

A4: 針對埋點版本是有對應的落庫記錄，可以通過不同版本的差異，快速尋找對應的埋點差異。

Q5: 埋點成本如何優化 ？

A5: 埋點版本生命周期管理,針對不同版本，無效埋點進行下線，降低數據產出級別成本;數倉表生命周期管理:按照數倉分層，不同分層對數據使用的周期，進行數據生命周期管理。