客戶端埋點爲什麼難？
埋點的流程
從業務過程中採集埋點，是數據驅動型公司的必要條件。知乎的產品功能評審環節，不僅有 PRD (Product requirement document），還加入了對應的 DRD ( Data requirement document）。對於埋點而言，DRD 需要明確業務目標與埋點缺口之間的關係以及需求的優先級。埋點的需求大多來自於 DRD，整個過程會涉及多個角色，主要包括產品經理、業務數據負責人、開發工程師、測試工程師。
目前知乎的埋點流程如下圖所示。
回顧知乎埋點流程的迭代史，整個流程落地三部曲可以總結爲六個字：能力、意願、工具。
能力
這幾年知乎的業務發展很快，埋點的流程也隨着迭代了很多個版本。在數據平臺組成立之初就研發了全端埋點 SDK 和日誌的接收服務。在有了埋點 SDK 之後，數據平臺組開始在公司推廣埋點工作，在早期是埋點的推動方和設計者，使得公司基本具備了打點的能力。
意願
爲了快速推進業務的埋點，數據平臺組招聘了埋點設計人員來設計全公司的打點。這個方法在短期內幫助公司的埋點工作順利進行，但是很快隨着業務持續的增長，即使是埋點設計的老手也無法快速響應業務的埋點需求，跨業務的任務排期也給業務帶來較多的困擾。我們發現埋點的流程如果做到業務閉環，能讓整個流程變得更爲高效和順利。業務中哪個角色更有意願來設計埋點是流程是否高效的重要因素。以下是業務幾個和數據有關角色的主要工作內容：
- 數據分析師和產品經理主要是數據的使用者，工作內容是發現和解決業務的問題，不斷對產品進行迭代
- 工程師對代碼的細節和打點時機最爲了解，但是對於數據具體的使用不見得很清晰
- 數據倉庫接口人負責業務數據的生產，和數據倉庫團隊對接，對埋點的定義需要有深入的理解綜合考慮各角色的意願後，我們設計了「業務數據負責人」這個角色，來整體來負責業務的數據生產工作，主要負責業務數據倉庫需求和埋點設計。
工具
早期埋點測試只有一個能力有限的小工具，用戶體驗並不夠好，直接將埋點測試作爲客戶端發版流程中的一部分只會整體降低測試工程師的效率。客戶端發版往往會遇到新增的埋點打重、打錯和打漏，老的埋點缺少迴歸測試等等問題，給業務帶來了不少困擾。因此一個易用性高、自動化和智能化的埋點測試平臺成了當時迫在眉睫的事情。在開發完一整套埋點管理和測試系統後，測試工程師將埋點加入了客戶端發版流程，並對全公司埋點做了整體評審，推進業務完善了埋點的元信息，並對核心埋點創建了迴歸測試。在埋點測試平臺有效使用起來之後，埋點的質量相比之前得到了大幅度的提升。
埋點的模型
古語有云：「治大國若烹小鮮」。目前知乎的埋點數量約爲三千個，如果缺少統一的模型來做標準化，每個人設計出來的埋點都不一樣。數據平臺爲此提供公司級通用的埋點模型，既要有公司級別的規範，又要滿足業務個性化的需求。在技術上，我們使用 Protocol Buffers 管理埋點 Schema，統一埋點字段和 enum 類型取值，統一 SDK 發版。
頁面瀏覽
頁面瀏覽的統計，對於 Web 端而言， 因爲 URL 非常明確， 統計規則簡單清新。通常來說，根據一些正則對 URL 進行分類，即可統計出某類頁面的 PV。
對於客戶端而言，統計的方式和 Web 端比較相似。由於客戶端不像 Web 端天然具備 URL，因此需要爲頁面僞造 URL。只要能被定義 URL，那麼 URL 變化了，即可算一次新的 PV。客戶端頁面瀏覽統計中，我們遇到的最難的問題是：頁面是什麼？如果說頁面的跳轉算一次新的曝光，問題在於頁面的功能變化多少算一次頁面的跳轉？一個典型的場景是一個頁面中某子模塊進行了 Tab 間切換時，當前頁面的 PV 該如何統計。目前對於這個問題，知乎目前沒有做統一，由業務自己來定義。
行爲事件
對於行爲事件，知乎選擇了事件模型，完整描述 Who、When、Where、How 和 What 五大要素。
Who、When 和 How
Who：用戶和設備的身份特徵。
When：埋點觸發的時間。
How：埋點發生時，用戶當前的狀態，例如網絡是 4G 還是 Wifi，當前的 AB 實驗命中情況等等。模型中 Who、When、How 由埋點 SDK 自動生成，埋點人員在絕大多數情況下不必關心這三個要素。
Where
準確定位一個事件發生的位置。主要包含以下幾個字段提供埋點設計者來做用戶事件的定位。
What
在事件發生位置上的內容信息，這裏採集的內容由業務決定。 例如點擊的卡片是一個回答還是一個 Live，當前內容的狀態這類需求。
對於業務定製化的「What」，最初我們爲個性化的需求，設計了通用的 ContentInfo，以及特定領域的數據結構。
對於 What，在客戶端開發上，我們主要遇到以下問題：
- 採集需要的數據有時和客戶端功能開發無關，客戶端獲取數據難
- 當數據結構較複雜，客戶端工作量增大
- 打錯和打漏的情況，需要發版，週期長面對上述打點，對於不是必須由客戶端獲取的數據改成由業務後端生成 Protocol Buffers 結構，序列化成 string 隨 api 帶回客戶端，客戶端只需將 string 放置到通用的位置即可。數據平臺組統一的實時 ETL 程序會反序列化該結構，過程如下圖所示。
對於 What，在埋點設計上，目前主要遇到以下問題：
- 埋點的 Key 越來越多，字段和業務並沒有在系統級別綁定關係，有些字段多個業務在用，枚舉值越來越多，對埋點設計者造成了較多的信息噪音
- 業務依賴了其他業務的打點，埋點變更可能導致其他業務的核心指標受到影響
第一個問題我們正在對埋點字段進行治理，將平臺通用字段和業務字段做系統級別的元信息完善。第二個問題，我們目前還在探索中。「他山之石，可以攻玉」，如果大家在這塊有好的實踐經驗，歡迎給文章評論中分享知識。
埋點的平臺技術
埋點管理平臺
當公司的規模生態還很小時，埋點使用 Excel 或者 Wiki 管理對埋點使用上影響不大。當公司業務快速發展，從一個產品變成多個產品，從幾十個埋點變成幾千個埋點，想要精準的用好埋點，就需要開發埋點的管理平臺了。
埋點管理平臺負責管理埋點的元信息，解決了埋點的錄入和查找需求，同時簡化了客戶端埋點的內容， 是知乎埋點流程的重要組成部分。同時在工程上又爲埋點測試平臺，數據採集系統提供埋點的元信息接口。
查看埋點
支持按照多個標籤來查找和過濾埋點。 在創建埋點時，需要花時間錄入這些元信息，從長期來看，收益會非常大。
創建埋點
在創建埋點時，填寫埋點對應的業務元信息和技術元信息，包括埋點對應的測試說明。埋點管理平臺提供埋點的 key，如果需要新增 key 則可向平臺申請。對於 enum 類型的 value，系統會自動補全。
生成埋點設計文檔
埋點設計文檔是工程師開發埋點的依據，是埋點流程中交流需要的重要「媒介」。埋點文檔標準化了埋點的設計，包含埋點的以下信息：
- 埋點的基本信息：業務、等級、應用、使用說明、打點時機、測試說明、需求文檔等
- 埋點對應的角色：數據負責人、開發、QA
- 埋點對應的字段和字段的取值
提供埋點元信息 API
數據採集服務會對採集到的埋點寫入到 Kafka 中，對於各個業務的實時數據消費需求，我們爲每個業務提供了單獨的 Kafka，流量分發模塊會定期讀取埋點管理平臺提供的元信息，將流量實時分發的各業務 Kafka 中。
埋點測試平臺
埋點的質量是數據的生命線，一旦出現問題，則會導致整條大數據鏈路的數據價值出現問題。埋點異常不但影響決策，修復數據同樣會消耗大量的精力和時間，最直接的後果就是雖然數據量越來越大，數據本身卻無法有效的使用。知乎的數據團隊在 2016 年做了一個埋點的小工具，只要輸入測試設備的 id，就可以查看對應的埋點信息。這個工具主要有以下幾個痛點：
- 埋點日誌量大，通常很難找到自己想測試的埋點
- 展示一整條日誌，系統無法判定埋點是否準確，全靠肉眼來看
- 無法創建測試用例，不能做迴歸測試
- 埋點漏了或者錯了人力尚能發現，埋點重複發送人很難發現
面對如上問題，我們重新設計了埋點測試平臺，目標是讓埋點測試更自動化和智能化，主要有以下功能：
- 可創建埋點測試用例，打通埋點管理平臺，支持多條件篩選埋點
- 支持發起埋點測試實例，只展示埋點測試用例中的埋點，多餘信息單獨展示
- 自動化提示埋點打錯、打漏和打重，前端界面高亮展示，生成測試報告
- 支持手機掃碼連上系統，無需人輸設備 id
其他：關於 Hybrid 類型埋點
客戶端內的 H5 生成埋點使用的是 JavaScript SDK，如果直接發送到日誌收集服務，會丟失客戶端的重要屬性。知乎的做法是將 H5 的日誌發送給客戶端，由客戶端處理後發送給日誌接收服務。在知乎我們對 H5 這類統稱 Hybrid，我們自研了 Hybrid 框架，跨端通信和埋點傳輸由框架提供支持，自動化解決和 ZA （Zhihu Analytics Log Server）的通信問題。
Hybrid 框架主要處理以下的問題：
- 對於 Native 和 JS 混合的頁面，該頁面曝光統計
- 對於 JS 頁面內部的跳轉，頁面曝光的統計
- JS SDK 生成的日誌，傳輸到 Native，併發送給日誌收集服務
- 對於 UTM 系列追蹤鏈，做到跨 Native 和 JS 支持
總 結
今天的大數據發展趨勢之快，對於很多公司來說都是挑戰，埋點是數據整個數據鏈路中的起點，是數據的生命之源。隨着知乎的快速發展，業務越來越多，知乎的埋點模型、流程和平臺技術在不斷迭代當中，在應用實踐上還有很大的改進的空間。