導讀

　　本文核心內容聚焦為什么要埋點治理、埋點治理的方法論和實踐、奇點一站式埋點管理平臺的建設和創新功能。讀者可以從全局角度深入了解埋點、埋點治理的整體思路和實踐方法，落地的埋點工具和創新功能都有較高的實用參考價值。遵循埋點治理的方法論，本文作者團隊已在實踐中取得優異成效，在同行業內有突出的創新功能，未來也將繼續建設數智化經營能力，持續打造更好的服務。

　　01埋點治理背景

　　在今年的敏捷團隊建設中，我通過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

　　1.1 埋點數據的價值

　　隨著線上流量紅利高峰逐漸達到瓶頸，在精細化運營、數智化運營的大背景下，越來越多的公司開始認識到數據的重要性，并將其打造成為公司的核心資產，以數據為中心驅動業務發展。而 埋點數據 作為企業內部最重要的兩大來源（埋點數據、業務數據）之一，其重要性不言而喻。

　　埋點是一種常用的數據采集方法。基于業務需求或產品需求，在應用頁面中植入數據采集代碼，監聽用戶各種行為事件（頁面瀏覽、關閉，元素曝光、點擊等），然后將采集的數據上報至服務端，服務端分別下發到大數據平臺和搜索、推薦等各業務系統。通過分析數據，追蹤用戶行為和應用使用情況，推動產品優化或指導運營；通過實時地獲取用戶點擊、瀏覽、停留等行為作為關鍵特征提供給搜索、推薦、廣告等系統，來提升智能分發的轉化和用戶體驗。

　　埋點數據上能影響業務運營數據分析、智能推薦、AB實驗的準確性，下能影響數據倉庫結構設計和數據采集團隊的維護成本。

　　1.2 業內主流埋點方式的對比

　　從技術層面上，埋點分為代碼埋點、可視化埋點、無埋點/全埋點。目前國內主要的第三方數據分析服務商和大型公司內部普遍支持。代碼埋點又衍生出了聲明式埋點、無痕埋點、服務端埋點等豐富的埋點方式。

　　通過多種埋點方式組合，可以在不同場景業務中靈活使用。比如在頁面中元素或頁面事件使用前端代碼埋點；在Debug鏈路長的搜推代碼中使用服務端埋點；產品運營等非研發使用可視化埋點。

　　1.3 為什么要治理埋點數據

　　然而隨著業務的迭代變更，部分埋點數據失去效用。為了確保數據的質量、效率、安全、標準及易用性，需要對埋點數據進行治理。不僅是存量數據的治理，新增數據更是要保證從源頭開始就是正確的。在埋點數據的生命周期內，每個環節制定原則性的管理方法和具體的落地措施。一個穩定的治理鏈路是埋點治理的基石。

　　從平臺視角來看，埋點治理要解決的問題如下：

　　質量問題： 最重要，大部分公司的數據部門啟動數據治理的起因就是數據質量存在問題。例如數倉的及時性、準確性、規范性，以及數據應用指標的邏輯一致性等。

　　成本問題： 互聯網行業數據膨脹速度非常快，大型互聯網公司在大數據基礎設施上的成本投入占比非常高，而且隨著數據量的增加，成本也將繼續攀升。

　　效率問題： 在數據開發和數據管理過程中都會遇到一些影響效率的問題，多是靠“盲目”地推人力在做。

　　安全問題： 業務部門特別關注用戶數據，一旦泄露，對業務的影響非常之大，甚至能左右整個業務的生死。

　　標準問題： 當公司業務部門比較多的時候，各業務部門、開發團隊的數據標準不一致，數據打通和整合過程中存在很多問題。

　　從業務視角來看，埋點治理要解決的問題如下：

　　埋點數據“全”： 因整體協助鏈條非常長，許多時候在需要做數據分析時，才發現頁面有部分功能漏報埋點，產品需求未涉及等。

　　埋點數據“準”： 需求開發測試階段，往往重點關注業務邏輯，對于埋點上報這些輔助異步流程，設計評估不準確。會存在因驗證不充分而導致數據不準確的情況。

　　埋點數據“快”： 推薦算法主要依賴數據驅動，埋點數據需要及時上報并反饋，推薦等智能應用系統才能根據用戶當前行為給出精準的策略決策。

　　埋點數據“統一”： 智能場景往往要通過多個業務線交叉數據作為輸入特征或算法畫像，每個業務線如沒有統一標準規范，數據處理計算邏輯復雜且迭代維護成本很高。

　　埋點數據“鏈路長”： 埋點數據從生產到使用，涉及運營、產品、研發、測試、數據分析師或算法工程師多個環節（如下圖），問題溝通排查鏈路長。

　　埋點數據“歷史長”： 頁面埋點隨需求迭代更新較快，歷史埋點設計文檔缺少統一管理，不利于長期維護。

　　02 埋點治理實踐

　　理解，首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板后進行模板加載，加載階段會將產物轉換為視圖樹的結構，轉換完成后將通過表達式引擎解析表達式并取得正確的值，通過事件解析引擎解析用戶自定義事件并完成事件的綁定，完成解析賦值以及事件綁定后進行視圖的渲染，最終將目標頁面展示到屏幕

　　為解決上述問題，幾經探索總結經驗后，本文作者團隊為埋點治理制定了全面的標準制度。遵循相應的制度，使得埋點治理工作有序有效開展。

　　2.1 制定全鏈路標準

　　作者團隊制定了一套覆蓋數據生產到使用，全鏈路的數據標準方法，從埋點數據定義、采集、驗證、指標定義到數據生命周期管理都建立了相應環節的標準化的研發規范，發布了《埋點流程規范標準》。

　　2.2 制定埋點流程規范

　　作者團隊制定了完整的埋點上報規范規程，并郵件通知各部門產研按流程，照規范上報數據。上報流程為埋點方案設計、埋點方案配置、埋點開發/測試、數據存儲/服務、數據應用五個環節，每個環節都要通過必要的步驟才可繼續向下執行。

　　2.3建設一站式埋點管理平臺

　　奇點埋點管理平臺是科技內部統一的埋點平臺，覆蓋埋點數據定義、采集、生產、驗證、基礎指標應用、數據質量監控治理等埋點全生命周期。做到了埋點元數據統一管理，埋點信息查詢簡易化、埋點上報驗證一鍵化、埋點數據質量追蹤可視化。

　　2.4成立組織保執行

　　通過和數據技術產品部門合作，在兩個部門領導的支持下，作者團隊成立了埋點治理盤古項目及埋點數據管理委員會。平臺研發部團隊是采集埋點數據工具的產研方，數據倉庫體系是由數據技術部負責建設，所以以這兩個團隊作為核心，并由這兩個團隊負責聯合各個業務線團隊，一起完成數據治理各個環節工作和流程的保障。

　　奇點團隊作為埋點數據采集和管理的主力，負責數據采集SDK，數據上報、清洗、存儲、查詢，埋點管理平臺等。

　　2.5宣導埋點和數據文化

　　過去由于數據文化的缺失，很多業務方意識不到規范埋點的重要性。未正確錄入頁面埋點信息、使用低版本采集SDK，造成了大量不符合標準的數據。組織培訓會和埋點規范宣講，推動數據合理規范上報，也是埋點治理的重點工作之一。

　　03 埋點治理階段性成果

　　理解，首先 MCube 會依據模板緩存狀態判斷是否需要網絡獲取最新模板，當獲取到模板后進行模板加載，加載階段會將產物轉換為視圖樹的結構，轉換完成后將通過表達式引擎解析表達式并取得正確的值，通過事件解析引擎解析用戶自定義事件并完成事件的綁定，完成解析賦值以及事件綁定后進行視圖的渲染，最終將目標頁面展示到屏幕。

　　作者團隊提供的數據采集服務范圍除了京東科技下金融科技、京東云、數字城市等全部業務線外，還擴展到了京東物流等兄弟部門。

　　奇點針對金融業務深耕多年，對數據的安全性、穩定性、實時性有多種保障方案，已是業務運營過程中不可或缺的重要環節。奇點管理平臺現已實現埋點管理、數據分析一體化。在埋點數據上報查詢、數據監控、數據計算可視化展示等各個環節都有相應的管理工具。

　　3.1埋點驗證工具

　　過去驗證上報數據是否準確，需要測試人員申請數據庫表權限，然后手寫SQL查詢數據。為此作者團隊做了埋點驗證工具，既可以掃碼查看本機實時數據、查看所有上報實時數據，也可以一鍵檢測上報數據是否符合規范。該工具為測試人員節省了大量時間，也為埋點治理，推動用戶規范錄入起了輔助作用。奇點服務端使用Lua腳本并發處理，而不是傳統的Web服務，處理請求速度更快，減少了服務器資源使用。實時數據存放在ES中，相比MYSQL數據庫能容納更多的數據量，查詢速度更快。

　　3.2埋點驗證工具

　　作者團隊在客戶端數據上報、服務端數據轉換、數據發送、落倉等每步都加入了監控，保證整條鏈路數據質量。監控定時檢查計算數據上報的成功率、緩存率、丟失率，數據加工清洗后的留存率、落倉率等，一旦數據浮動超過設定的閾值，會自動發告警郵件給奇點研發人員。有了數據監控，能及時發現、高效處理數據量問題，降低數據損失，節省人力，極大提升了數據質量。

　　3.3實時數據一站式看板

　　過去作者團隊只關注埋點范圍的研發業務，平臺升級后，用戶錄入埋點信息后可通過看板即時查看PV、UV、點擊率等指標實時數據。對于用戶來說，省去了從各種庫表取數分析的步驟；對于埋點治理來說，不但降本增效，推動用戶規范錄入頁面信息，而且指標計算結果比各個業務方自己分析更加準確。

　　04奇點埋點對比行業創新功能

　　4.1埋點可視化展示

　　查看某個頁面的埋點信息，通常采用分頁列表的方式，詳細數據要跳轉到看板瀏覽。這種方式雖然羅列出了頁面所有埋點，但是每個埋點的錄入人不同，埋點多了之后具體每個埋點表示什么含義其他人并不清楚。

　　為此作者團隊研發了埋點可視化工具，完美解決了上述問題。只要輸入頁面URL，選擇合適的設備大小，頁面哪些元素有埋點就呈現出來。每個坑位的埋點ID，點擊曝光的數據只要點擊一下浮框即可見。埋點可視化工具還支持查看實時上報的日志和匯總的實時數據。

　　埋點可視化展示通過數據采集腳本-奇點 JS SDK 自動加載可視化插件實現，使用postMessage 和addEventListener(message)，實現埋點可視化工具和所查看頁面的數據雙向發送與接收，從而實時展示埋點數據和埋點日志。為減少加載SDK的頁面開銷，作者團隊做了優化處理，只有在可視化工具中打開頁面才會加載該插件。

　　4.2 H5與原生App全鏈路數據打通

　　類似京東金融這樣使用Native和WEB技術開發的混合應用，之前H5頁面和原生頁面的數據，使用了不同的SDK采集，用戶在兩端頁面間跳轉，數據是斷裂的，只能分開統計，不能從整體上統計分析用戶行為。采用歸因統計的方法能關聯部分兩端的數據，但會導致數據統計不準確，不但增加數據分析人力、物力成本，不可靠的數據還會使運營無法精準投放廣告，從而影響最終收益；

　　如今奇點團隊實現了H5頁面和原生頁面數據打通，包括以下打通點：

　　訪次打通: 訪次是指用戶在當前設備中累計訪問次數，在京東金融 App 中，用戶每次重新打開或者切后臺超過 2 分鐘后，訪問的次數就會加1。可以根據訪次來統計用戶活躍度。

　　訪序打通: 訪序是指用戶在當前訪次內，頁面的訪問順序，H5和原生頁面打通后，頁面的訪序是連續的，可以更精準的查看用戶訪問頁面路徑。

　　來源埋點: 來源埋點是指上一個頁面用戶點擊點最后一個埋點ID。根據來源埋點，可以精準定位上一個頁面觸發點。數據打通后，可以確定當前頁面的熱點來源。

　　首訪埋點: 首訪埋點是指用戶打開App時首次點擊的坑位埋點，根據首訪埋點可以定位到進入某一 H5 或原生頁面起始點。

　　上一個頁面 URL 或原生頁面 CTP: 為了精準分析用戶行為軌跡，奇點會采集上一個頁面 URL 或原生頁面CTP，數據打通后，會形成閉環，即使是后退操作也會記錄后退的前一個頁面，從而可以更好的進行路徑分析、頁面可達分析、用戶丟失率分析。

　　其他采集字段打通: 為了統一口徑，統一指標，打通的字段還包含以下字段：設備 ID、手機品牌、手機型號、App 名稱、App 版本。

　　兩端打通前：

　　兩端打通后：

　　數據打通的收益是巨大的，下面是一個實際使用案例-小金庫頁面流量來源歸因分析：

　　4.3 頁面ID自動匹配上報

　　過去統計PV時，根據訪問頁面的URL作為唯一標識，這個URL需要在奇點管理平臺錄入后方可進行計算。然而這種方式存在很大的缺陷。當遇到以下場景，根據哪個URL來計算，邊界并不清晰。

　　URL中帶參數，例如/path1/path2?param=value。不同參數可能代表同一個頁面，也可能是不同的頁面；動態路由，例如/path1/path2/:path3/，某個path是動態的，如果這個path是數字ID，是無法在奇點管理平臺全部錄入的；Hash路由，例如/path1/path2/#/route1 / route2。如今前端單頁面盛行，不同業務方做出的網站大相徑庭，hash值不同，有的希望統計成一個頁面，也有想統計成不同的頁面；以上場景混合的情況。

　　針對此問題，作者團隊提出了使用pageId代替URL的方案。即業務方在奇點管理平臺錄入時指定URL的哪部分是動態的還是固定的，并生成唯一頁面的ID。在訪問頁面時，當前頁面的鏈接與錄入的動態規則做計算，找到最匹配的pageId后上報數據，最終使用pageId做數據統計，極大的提高了指標計算正確率。

　　為保證此方案的穩健性，作者團隊也做了很多細節把控。比如為防止拉取CDN pageId JSON文件失敗，增加了重試機制，在未獲取到文件時先將上報數據緩存在本地。比如沒有匹配成功的URL另做打標處理。還有監控站點更新頁面，同步生成最新的配置關系等等。

　　05未來規劃

　　在埋點數據治理方向，奇點團隊聯合數據團隊通過一系列方案實現自動化治理埋點數據。例如對不規范數據打標，使數據不進入數據分析模型層；各端統一使用頁面唯一ID的上報方式；不規范錄入信息的頁面自動認領到頁面站點下；向未錄入頁面的用戶定向推送郵件等方式持續提升數據質量。

　　在平臺能力建設方向，首先從精細化運營角度還要持續建設可視化埋點及與頁面活動搭建平臺打通提供組件化埋點能力，提升埋點開發效率。其次從埋點生命周期管理角度，奇點平臺提供的埋點設計管理、代碼掃描、埋點驗證、埋點指標看板一系列工具要更好流程化整合，提升產、運、研等各方的協同效率。最后從智能化建設角度，對于流量數據看板增加智能分析、智能預測能力，提升數據應用效率。通過埋點數據作為基石，賦能業務場景，更好地服務支撐公司整體的數智化經營能力建設。

  今天的分享就到這里了，想了解更多關于開京東店鋪的流程和費用、京東網店購買等內容，敬請關注火蝠電商代運營官網。