談談埋點質量管理

如今互聯網人對於數據的使用可畏常態化，雖然有的是日常工作，有的只是幾次需求，但無論對與數據有多少依賴，在數據的使用或解讀上，以下情況大家應該都會遇到一二。

• 團隊來了一位新同學，想分析某個功能的數據情況，但感覺無從下手。便問老員工這個功能對應的埋點、那個頁面對應的參數，得到的不是口口相傳就是看着聊天記錄中的文檔地址。面對着黑壓壓一片的埋點信息，內心估計已經開始神獸奔騰了；
• 新版本上線後進行效果分析，發現埋點出現紕漏，此時若是重要數據，需要緊急找人發版，時間緊張又擔驚受怕；若此時是一般數據，開發同學的回覆大概率是：“和下個版一起迭代”，時隔半年一年再進行分析，這段數據波動的原因估計也沒人能説清了；
• 測試同學拿着協作的埋點文檔，測試過程中發現不是字段對應錯誤就是信息維護不全，解讀起來麻煩不説，如果碰到大版本還需要進行埋點回歸，不僅測試過程中工作量大，還有漏測的風險。

埋點數據作為日常數據最重要的三大來源之一（包括業務數據和對外合作數據），其重要性不言而喻。上能影響推薦、AB實驗、數據分析的準確；下能影響倉庫的結構設計和日常維護成本。當前數據更是作為資產被各家公司所重視。想象一下到年終盤點時，面對一團“剪不斷，理還亂”的數據，會是一種什麼心情。

筆者通過對最近接手的埋點質量項目的一些經驗總結，希望通過這篇文章給大家分享一下心得體會。

一、埋點質量問題有哪些？

埋點過程整體鏈路環節較長，囊括的角色也相對較多。出了問題排查難度大，週期長，而且涉及團隊配合問題也不好把控，下面我們來總結一下哪些環節容易出問題導致埋點質量問題。

如果在數據產出階段不進行把控，等到了應用階段就會出現數據不完整、數據重複、數據不一致、數據不匹配等數據問題。所以解決埋點質量問題要做到“預防為主、防治結合、綜合治理”的方針，下面我們來看下如何進行埋點質量管理。

二、如何進行埋點質量管理？

要開展埋點質量的管理，筆者認為可以從以下三個角度開始執行：意識、制度&流程、工具。

1. 意識

這裏所謂的意識更多的是一種價值觀、信念或者説是一種行為“動機”，是每個同學做事對自我要求的一項軟性標準，類似於“道德”。

可能讀到這大家覺得有些浮誇，怎麼管理個埋點都上升到道德層面了。彆着急，繼續往下看。

對於執行層，無論是分析師或埋點產品必須要對出自自己手中的需求要負責，時刻意識到，埋點需求是整條數據鏈路的源頭，並且用户實時發生數據擁有着不可回溯性。如果要是從源頭開始“錯、缺、亂”，那後續的環節不僅增加了成本，同時這部分數據也“白白流失”了。

而對於高層管理者，在任職期間要適當地給予數據治理一些側重，無論是在人力上還是時間上。

讓自己或自己的上級領導提升一些基礎建設的意識，磨刀不一定會誤砍柴功。用產品進行向上管理固然重要，畢竟是一個看的見、用得到並且能“體會”價值的載體。如果只在乎表面光鮮，那背後的“千瘡百孔”要何時才能有機會修補。

任何一個組織創建時都需要有一個文化或者信念，在做事的時候可以時刻提醒自己。所以在質量管理的第一個重要角度是意識。

2. 制度&流程

上面講述了意識層面上的統一，下面開始説的就是行為上的規範。所謂無規矩不成方圓，任何一件事有一個良好的規範去執行，那出錯的概率就會比每個人自由發揮低很多。

這裏所説的制度包括兩個方面：角色流程和採集規範。

1）角色流程

埋點從需求產出開始要經歷埋點開發、數據上報、數據採集、數據清洗、數據入庫最終到業務應用，涉及的人員包括埋點產品&分析師、開發、測試、採集工程師、倉庫工程師等。

各個環節能有機組合就需要一個良好的配合制度，既能保證工作有條不紊，同時又避免了權責混亂導致的問題無法及時響應。

2）採集規範

① 文檔規範

文檔規範要求負責埋點的同學列清相關需求點，包括：所需要的事件信息、統計位置、打點邏輯、上報時機。甚至還可能有失敗後如何處理、失敗原因、變更歷史等相關內容，細化的需求文檔有利於降低其他環節同學的理解偏差，也便於埋點使用時瞭解前因後果及錯誤信息。

② 接入規範

是指業務開發同學在使用埋點組件時要嚴格遵守組件方提供SDK的使用規則，例如通用事件內擴展字段的埋點位置、上報時機等。切不可根據“自我經驗”進行更改優化。

③ 命名規範

命名規範適用於埋點信息的命名，包括事件ID、事件參數以及實際的參數值，做到以下原則：

1. 方便解讀；
2. 不要有特殊字符，不要採用系統關鍵字或預置關鍵字進行命名；
3. 字段不易過長；
4. 版本前後字段映射統一等。

無法挨個維護的的參數值可以採用SPM或SCM模型來制定採集規範。

SPM叫超級位置模型，最早是受到土地户籍制度啓發而設計的位置系統，目的應用於頁面的統計、追蹤頁面的來源等場景，通常在埋點時作為埋點參數上報到數據後台。其編碼形式採用A.B.C.D四層級進行組合，分別代表了業務、頁面、頁面區塊、區塊內的點位。

我們以小紅書的商城首頁舉例：

業務：商城（shop_center）

頁面：首頁（home_page）

頁面區塊：變美季（beauty）

區塊內點位：3

SPM模型命名澳大利亞·秋冬必備神級修復的位置內容就可以寫成：shop_center.home_page.beauty.3

在統計數據時可以通過該參數知道這個模塊的位置的流量大小情況。

SCM叫超級內容模型，用來標識唯一一塊內容的模型，在埋點時SCM模型的數據作為埋點參數上報到數據後台，其編碼形式和SPM一樣也是通過A.B.C.D四個層級進行編碼，只不過四個層級記錄的信息與SPM有所差別，分別是：內容來源、投放算法、算法版本以及對應的人羣。

還以上面的內容為例：

內容來源（content_source）:shop

投放算法（algorithm）：cf

算法版本（version）：3.3

對應人羣（crowd）：woman

該條內容：澳大利亞·秋冬必備神級修復的內容情況如：shop.cf.3.3.woman

可以統計不同位置下該條內容所展示的信息和流量情況SPM和SCM作為兩種不同的編碼規範，我覺得可以根據自己的需要進行相關的改良，比如更改層級或更改定義等。

3. 工具

1) 埋點模型

埋點模型採用的是事件模型，事件模型描述了一個人做某件事情所需要的幾個重點要素：時間（when）、地點（where）、人物（who）、途徑（how）、結果（what）。

例如：小明4月3號早上9點用小米手機在京東買了一個iPhone12，轉譯到埋點語言就是：

以上設備信息均為虛擬信息，僅作參考

實現以上信息採集的埋點方式當前行業內有：代碼埋點、無埋點。

① 代碼埋點

代碼埋點是根據具體埋點需求進行數據採集的方式，這也是用户行為數據最早的採集方式。

代碼埋點可支持客户端埋點和服務端埋點。客户端埋點主要採集用户行為，服務端埋點更多采集的是業務數據。

優點：

1. 埋點可以做到按需採集、減少無效的信息上報；
2. 事件觸發方式可以自定義，降低端上的資源消耗。

缺點：

1. 新增埋點週期較長，需要跟隨版本迭代；
2. 管理成本較高，造成系統代碼“冗餘”；
3. 採集數據有“缺失”，只能獲取到上線之後的數據。

② 無埋點

無埋點是識別端上各區塊元素，對其進行全面的採集。

優點：

1. 新版本上線也可看到歷史數據；
2. 前端埋點成本低，管理成本低；
3. 埋點範圍覆蓋相對較廣。

缺點：

1. 數據冗餘過剩；
2. 對應用開發的元素命名和開發規範要求嚴格；
3. 不能進行自定義數據的採集；
4. 服務端壓力較大。

為了埋點數據全&準的兩個準則，一般可以採取兩種方式組合的方式。重點業務、非重點頁面採用代碼埋點，重點頁面非重點業務採用無埋點。合理分配兩種埋點策略做到不丟不漏在合理的維護成本範圍內，儘可能多而全的採集。

2）埋點平台

雖然有了意識上的“統一“、制度上的規範，但我相信依舊有一些團隊在沿用公用文檔維護埋點信息。

文檔化維護方式在信息量小的時候問題還不凸顯，但當面對成百上千的埋點就會出現埋點信息維護不全、查找困難、測試同學面對“海量”的上報數據頭暈眼花極容易漏測、實際上報與需求不符無法及時發現等問題。

所以埋點質量的最後一個環節就需要通過平台化來進行輔助管理，主要管理的方向有以下幾個方向：

1. 元數據管理完善、可溯源，提升查詢效率；
2. 自動化測試+人工校驗、降低漏測風險；
3. 質量監控，提升對錯誤埋點的發現效率；
4. 引入埋點流程、輔助進行“團隊管理”。

① 元數據的完善

元數據管理主要包含以下內容：事件基礎信息、業務組織架構、當前開發狀態、操作日誌及變動日誌。

1. 事件基礎信息：事件ID&名稱、參數ID&名稱、參數值ID&名稱，統計口徑、上報時機、版本、需求地址等。
2. 業務組織架構：事件歸屬的頁面、功能層級結構等信息。
3. 當前開發狀態：該事件所處的流轉狀態，包括：需求中、需求完成、開發中、開發完成、測試中、測試上線、灰度、正式上線。
4. 操作日誌及變動日誌：記錄系統上所有人員對於元數據的操作日誌以及該事件歷史版本變動日誌等。

有了完備的元數據信息，還需要提供完善的篩選和查找機制，讓埋點使用人員可以方便管理和查詢。

同時平台可以根據埋點組件規範和埋點信息自動生成一段代碼給到業務開發同學，即降低了代碼埋點的開發成本，也降低了出錯的概率。

② 自動化測試

對於測試而言，有了完善元數據後埋點平台可以提供：

• 自動化的測試功能：可以根據實際上報的數據明細自動比對元數據模塊下維護的信息內容，在每次測試任務中都會自動提醒哪些事件不符合規範，極大的提高了測試效率，加上後期的人工校驗，也會降低漏測的概率。
• 規範的數據展示方式以及詳細的信息記錄：傳統的測試方式一邊需要對着文檔、一邊需要看着一條巨長的上報數據來找到需要比對的信息來確認埋點是否準確。平台完全可以結構化上報數據，隱藏無關維度信息，並根據上報內容關鍵字（事件或參數信息）自動去元數據內進行數據查詢，埋點同學每次測試任務只需要瞭解版本需求範圍即可。

③ 質量監控

即使測試通過了，埋點數據就一定讓人放心了麼？肯定不是的。上線後面對大樣本使用，用户App什麼樣的機型都有，甚至會被篡改一些信息。

為了能讓最終上報的數據減少錯誤，埋點平台可以提供質量管理模塊，具體監控策略可以根據數據質量評估標準通用的5項準則：完整性、及時性、唯一性、穩定性、準確性進行設定。

④ 引入埋點流程輔助

管理整個埋點平台使用流程，可以根據上面2.制度&流程的角色流程進行劃分和管理。上線前每個環節由相關負責人員進行確認，多層確認機制可以保證埋點信息的完善和準確，也為後續管理上帶來了極大的便利性。埋點平台功能框架參考如下：

三、寫在最後

數據質量問題在業務發展到一定階段都會遇到，就像升職以後需要管理團隊一樣，不同級別面臨的問題不一樣，所需要採用的手段也不一樣。

希望本篇文章可以讓那些即將面臨這個問題或已經身在其中的小夥伴能有一部分可借鑑的地方。因篇幅問題，涉及SDK、埋點設計以及平台搭建的部分都沒法詳細展開描述，如果對此感興趣或有疑問的同學歡迎一起交流。

作者：一個數據人的自留地；公眾號：一個數據人的自留地

本文由@一個數據人的自留地 授權發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議。