商家視覺化埋點探索和實踐｜得物技術

　　 一 專案背景

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

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

　　埋點流程從明確需求到上線&驗證共計上圖 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 路徑。　　

　　元素圈選方案

　　參考開源的 Dom-Inspector，圈選的本質就是在使用者滑鼠移動的時候，在元素上層出現一個同樣大小的浮層，以便使用者識別。

　　獲取使用者滑鼠移動和滑鼠移動處的元素，在 Body 上監聽 MouseMove 事件並取其 Target 即可獲取目標元素，接下來只需要獲取元素的 content 大小、padding、margin 大小及元素的位置，然後根據其位置掛載浮層。

　　資料採集SDK容器　　

　　依賴載入

　　視覺化埋點為適配國內，國際，B 端，C 端等不同場景，最大程度相容現有埋點能力，支援多種埋點上報 SDK 和資料採集，透過判斷 Query 引數或 UA 資訊，來透過動態引入依賴，如 Facebook、神策、Google、BaseSdk 依賴，載入對應 CDN 的 JS。

　　配置讀取&資料上報

　　讀取配置：視覺化埋點是通用型埋點，不依賴具體埋點程式碼，根據當前產品所做埋點配置資訊，透過匹配當前系統和頁面 URL，按照對應規則，獲取到當前頁面的配置 JSON，進行載入。

　　資料劫持：透過劫持 Fetch 等物件，獲取頁面請求資料，支援使用者自定義配置上報的業務引數。

　　頁面級別通用業務引數維護：研發在管理後臺維護頁面級別通用業務引數，透過 InjectCommon 方法將如訂單 ID、類目 ID 等埋點需要關注的業務引數注入至 JSON 中，產品、運營透過選擇業務引數即可進行埋點。

　　埋點上報

　　透過監聽頁面級別事件，判斷是否為對應埋點元素，命中後，進行使用對應載入的 SDK 進行資料上報。

　　埋點驗證更新

　　產品需求變，容易造成原有埋點失效，導致埋點覆蓋率下降，目前支援三類方式進行埋點驗。

　　手動埋點驗證，埋點資料異常告警，埋點巡檢任務。

　　手動埋點驗證　　

　　埋點資料異常告警

　　視覺化埋點管理平臺，透過 CronJob 定時任務檢查節點資料是否正常同步，若有節點異常則發訊息給相關建立人。　　

　　埋點巡檢任務

　　透過 Pupptter 記錄使用者行為，每天定時執行使用者行為記錄，檢驗節點是否丟失，若有丟失則發訊息給相關建立人。　　

　　 四 總結&規劃

　　目前平臺的監控、巡檢體系用於保證資料準確性，避免資料丟失和異常，造成業務誤判。埋點流程還存在一定可最佳化的空間，如：

　　埋點 SDK 存在一定耦合，未來功能粒度將拆的更細，做到各司其職。

　　監控體系的可配置化能力，將支援針對特定人群和資料維度進行指定配置化等。

　　最佳化 C 端視覺化能力，提升 C 端視覺化埋點體驗。

　　平臺的重點都是為業務服務，助力業務各類指標能力是平臺價值最大化的優秀實踐。