導讀：埋點作為商業智能（BI）和人工智能（AI）體系中重要的一環，是公司提升產品工程質量、實施 AB Testing、個性化推薦服務重要的數據來源。在傳統的純 Web 和 Native 開發的產品中，埋點從技術的角度來說未必多深奧，但從業務的角度來說要做到埋點設計規范、流程高效和保證質量卻是很難。本文重點介紹一下知乎客戶端的埋點模型、流程和平臺技術。

客戶端埋點為什么難？

Web 端的埋點可以隨著新代碼上線即時生效，對版本的發車概念相對較弱，即使埋點錯漏，修復成本較低。

對客戶端而言，如果使用 Native 技術開發的功能埋點有問題，則需要等下一個版本才能修復，并且還有版本覆蓋度的問題。修復埋點的這個時間窗口一般都比較長，會對業務的產品快速迭代產生很負面的影響。從業務的角度來說，客戶端在發布功能之前，對于要做的數據分析不見得想得全，無計劃收集非常多的埋點，對于埋點設計人員、客戶端開發、測試人員來說是很大的工作量。反過來說，真正要用數時才發現重要的埋點沒有采集，則會 「點」 到用時方恨少。因此，如何綜合規劃一個版本要采集的埋點，也是頗有挑戰的事情，頗有「養兵千日，用兵一時」的感覺。

埋點的流程

從業務過程中采集埋點，是數據驅動型公司的必要條件。知乎的產品功能評審環節，不僅有 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 支持

總 ?結

今天的大數據發展趨勢之快，對于很多公司來說都是挑戰，埋點是數據整個數據鏈路中的起點，是數據的生命之源。隨著知乎的快速發展，業務越來越多，知乎的埋點模型、流程和平臺技術在不斷迭代當中，在應用實踐上還有很大的改進的空間。

團隊介紹

知乎的大數據平臺團隊，屬于知乎的技術中臺，是具有數據驅動基因的公司發展到一定階段必然會重點打造的團隊。面對業務的多元化發展和精細化運營，數據的需求變得越來越多，大數據平臺團隊主要負責：

• 搭建公司級可視化分析系統和數據服務

• 維護全端數據的采集、集成和數據倉庫，對接業務系統

• 管理數據生命周期，提供一站式的數據開發、元信息管理和任務調度平臺

• 提供 AB Testing 實驗平臺，系統化集成實驗分析框架，推動業務增長

總結

以上是生活随笔為你收集整理的数据埋点太难！知乎的做法有何可借鉴之处？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。