　　 一專案背景

　　在數字產品的資料分析實踐中，手動程式碼埋點方式因其精確性和定製化的優勢長期被許多組織採用，但隨著業務快速發展和迭代需求的增加，傳統手動埋點方法的時間消耗、一定的技術門檻和較高的維護成本成為研發角色的負擔。另外，全埋點的埋點方式提供了全面資料捕捉的解決方案，但其帶來的海量資料處理難題和潛在的隱私風險也不容忽視。

　　原有商家後臺透過手動埋點方式實現業務埋點的收集。　　

　　埋點流程從明確需求到上線&驗證共計上圖 5 個步驟，手動程式碼埋點經歷 v1.0 到 v2.0，減少了研發熟悉埋點流程、平臺建節點、埋點 coding 成本，從前期產品隨需求提出埋點訴求，到進入迭代進行需求開發，再到需求正式上線，並生效檢視資料。

　　在偏 B 類產品系統中，前期更關注產品功能實現，手動程式碼埋點的流程週期和成本的問題易導致埋點的覆蓋率不足，在長期功能互動迭代試錯或者精細化最佳化產品體驗時，往往存在缺少及時和豐富的資料支撐來為決策最佳化方向提供保障。導致階段性的體驗較差，甚至極端研發資源浪費等問題。

　　視覺化埋點相對手動埋點流程上得到明顯減少，且具有以下價值：

　　埋點實時生效，資料 T+1 可查、加速資料驅動決策，業務埋點及時率高達 90%+。

　　提升鏈路整體效率，大部分場景下研發手動埋點開發 0 投入，0 溝通。

　　能夠視覺化的看到全量埋點，及時發現差異變更，及時調整，埋點丟失率 0%。

　　 二視覺化埋點方案

　　產品定位

　　視覺化埋點，主要目標服務於產品/運營同學，能夠基於視覺化形式快速進行埋點配置，做到實時生效，同時提供埋點通用能力，如埋點驗證保障埋點準確率。　　

　　對比神策等埋點：

　　視覺化埋點重點針對適配國內，國際，B 端，C 端等不同場景，最大程度相容現有埋點能力，支援多種埋點上報。

　　SDK 和資料採集，支援透過判斷 Query 引數或 UA 資訊，動態引入依賴，如 Facebook、神策、Google、BaseSdk 依賴，載入對應 CDN 的 JS 來進行底層資料上報。

　　本身視覺化能力重點關注簡化埋點編碼過程，同時提供公共埋點能力，如提供資料劫持，載入自定義引數，埋點統一有效性驗證等。

　　需求埋點整體流程圖　　

　　埋點操作流程

　　如下為視覺化埋點功能流程：　　

　　開啟視覺化埋點配置可移動配置皮膚，針對需要埋點的元素進行圈選。

　　頁面圈選指定元素，配置相關名稱、事件、自定義業務屬性、維護人等，儲存至管理後臺資料庫。

　　埋點 SDK 監聽點選、曝光事件，讀取配置資訊，針對指定配置元素進行埋點上報。　　

　　 三商家視覺化埋點的實踐

　　技術實現流程　　

　　埋點定位&圈選方案

　　元素標誌需要全域性唯一且不易受到產品互動變更影響，並在確認受到影響後，需在功能迭代上線前，完成埋點變更。

　　標識結構設計

　　常規的 Xpath 設計，在針對外部結構變更時，很容易導致失效，需要進一步降低外部影響，因此唯一標識方面整體採用自定義 Data-Trackid + 相對路徑的 Xpath 路徑。　　

　　標誌生成&匹配流程

　　首先研發人員在研發時，需提前安裝 VScode 外掛 AddTrackId 埋點外掛『用於生成 Data-Trackid 的 Data-Set 屬性』。

　　安裝完成後，在開發JS、TS、TSX、JSX、Vue 等格式檔案中任意位置，右鍵生成埋點所需 Data-Trackid，即可掃描當前檔案，針對指定 Dom 標籤加上 Data-Trackid 屬性，每個標籤使用新生成 TrackId【控制長度】，第二次儲存時，已有 TrackId 不變，沒有的新增 + 路徑的拼接，轉 MD5。

　　使用者在頁面圈選元素時，會尋找最近的帶 Data-Trackid 的標籤，如果沒有則繼續向上找，最終拼接一個相對的 Xpath 路徑。　　