轉(zhuǎn)自知乎

客戶端埋點(diǎn)為什么難片仿？

Web 端的埋點(diǎn)可以隨著新代碼上線即時生效统锤，對版本的發(fā)車概念相對較弱配猫，即使埋點(diǎn)錯漏幅恋，修復(fù)成本較低。

對客戶端而言泵肄，如果使用 Native 技術(shù)開發(fā)的功能埋點(diǎn)有問題捆交，則需要等下一個版本才能修復(fù)淑翼，并且還有版本覆蓋度的問題。修復(fù)埋點(diǎn)的這個時間窗口一般都比較長品追，會對業(yè)務(wù)的產(chǎn)品快速迭代產(chǎn)生很負(fù)面的影響玄括。從業(yè)務(wù)的角度來說，客戶端在發(fā)布功能之前肉瓦，對于要做的數(shù)據(jù)分析不見得想得全遭京，無計(jì)劃收集非常多的埋點(diǎn)，對于埋點(diǎn)設(shè)計(jì)人員泞莉、客戶端開發(fā)哪雕、測試人員來說是很大的工作量。反過來說戒财，真正要用數(shù)時才發(fā)現(xiàn)重要的埋點(diǎn)沒有采集热监，則會 「點(diǎn)」 到用時方恨少。因此饮寞，如何綜合規(guī)劃一個版本要采集的埋點(diǎn)孝扛，也是頗有挑戰(zhàn)的事情，頗有「養(yǎng)兵千日幽崩，用兵一時」的感覺苦始。

埋點(diǎn)的流程

從業(yè)務(wù)過程中采集埋點(diǎn)，是數(shù)據(jù)驅(qū)動型公司的必要條件慌申。知乎的產(chǎn)品功能評審環(huán)節(jié)陌选，不僅有 PRD (Product requirement document），還加入了對應(yīng)的 DRD ( Data requirement document）蹄溉。對于埋點(diǎn)而言咨油，DRD 需要明確業(yè)務(wù)目標(biāo)與埋點(diǎn)缺口之間的關(guān)系以及需求的優(yōu)先級。埋點(diǎn)的需求大多來自于 DRD柒爵，整個過程會涉及多個角色役电，主要包括產(chǎn)品經(jīng)理、業(yè)務(wù)數(shù)據(jù)負(fù)責(zé)人棉胀、開發(fā)工程師法瑟、測試工程師。

目前知乎的埋點(diǎn)流程如下圖所示唁奢。

回顧知乎埋點(diǎn)流程的迭代史霎挟，整個流程落地三部曲可以總結(jié)為六個字：能力、意愿麻掸、工具酥夭。

能力

這幾年知乎的業(yè)務(wù)發(fā)展很快，埋點(diǎn)的流程也隨著迭代了很多個版本。在數(shù)據(jù)平臺組成立之初就研發(fā)了全端埋點(diǎn) SDK 和日志的接收服務(wù)熬北。在有了埋點(diǎn) SDK 之后千所，數(shù)據(jù)平臺組開始在公司推廣埋點(diǎn)工作，在早期是埋點(diǎn)的推動方和設(shè)計(jì)者蒜埋，使得公司基本具備了打點(diǎn)的能力淫痰。

意愿

為了快速推進(jìn)業(yè)務(wù)的埋點(diǎn)，數(shù)據(jù)平臺組招聘了埋點(diǎn)設(shè)計(jì)人員來設(shè)計(jì)全公司的打點(diǎn)整份。這個方法在短期內(nèi)幫助公司的埋點(diǎn)工作順利進(jìn)行待错，但是很快隨著業(yè)務(wù)持續(xù)的增長，即使是埋點(diǎn)設(shè)計(jì)的老手也無法快速響應(yīng)業(yè)務(wù)的埋點(diǎn)需求烈评，跨業(yè)務(wù)的任務(wù)排期也給業(yè)務(wù)帶來較多的困擾火俄。我們發(fā)現(xiàn)埋點(diǎn)的流程如果做到業(yè)務(wù)閉環(huán)，能讓整個流程變得更為高效和順利讲冠。業(yè)務(wù)中哪個角色更有意愿來設(shè)計(jì)埋點(diǎn)是流程是否高效的重要因素瓜客。以下是業(yè)務(wù)幾個和數(shù)據(jù)有關(guān)角色的主要工作內(nèi)容：

數(shù)據(jù)分析師和產(chǎn)品經(jīng)理主要是數(shù)據(jù)的使用者，工作內(nèi)容是發(fā)現(xiàn)和解決業(yè)務(wù)的問題竿开，不斷對產(chǎn)品進(jìn)行迭代

工程師對代碼的細(xì)節(jié)和打點(diǎn)時機(jī)最為了解谱仪，但是對于數(shù)據(jù)具體的使用不見得很清晰

數(shù)據(jù)倉庫接口人負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的生產(chǎn)，和數(shù)據(jù)倉庫團(tuán)隊(duì)對接否彩，對埋點(diǎn)的定義需要有深入的理解綜合考慮各角色的意愿后疯攒，我們設(shè)計(jì)了「業(yè)務(wù)數(shù)據(jù)負(fù)責(zé)人」這個角色，來整體來負(fù)責(zé)業(yè)務(wù)的數(shù)據(jù)生產(chǎn)工作列荔，主要負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)倉庫需求和埋點(diǎn)設(shè)計(jì)敬尺。

工具

早期埋點(diǎn)測試只有一個能力有限的小工具，用戶體驗(yàn)并不夠好贴浙，直接將埋點(diǎn)測試作為客戶端發(fā)版流程中的一部分只會整體降低測試工程師的效率砂吞。客戶端發(fā)版往往會遇到新增的埋點(diǎn)打重崎溃、打錯和打漏蜻直，老的埋點(diǎn)缺少回歸測試等等問題，給業(yè)務(wù)帶來了不少困擾笨奠。因此一個易用性高袭蝗、自動化和智能化的埋點(diǎn)測試平臺成了當(dāng)時迫在眉睫的事情唤殴。在開發(fā)完一整套埋點(diǎn)管理和測試系統(tǒng)后般婆，測試工程師將埋點(diǎn)加入了客戶端發(fā)版流程，并對全公司埋點(diǎn)做了整體評審朵逝，推進(jìn)業(yè)務(wù)完善了埋點(diǎn)的元信息蔚袍，并對核心埋點(diǎn)創(chuàng)建了回歸測試。在埋點(diǎn)測試平臺有效使用起來之后，埋點(diǎn)的質(zhì)量相比之前得到了大幅度的提升啤咽。

埋點(diǎn)的模型

古語有云：「治大國若烹小鮮」晋辆。目前知乎的埋點(diǎn)數(shù)量約為三千個，如果缺少統(tǒng)一的模型來做標(biāo)準(zhǔn)化宇整，每個人設(shè)計(jì)出來的埋點(diǎn)都不一樣瓶佳。數(shù)據(jù)平臺為此提供公司級通用的埋點(diǎn)模型，既要有公司級別的規(guī)范鳞青，又要滿足業(yè)務(wù)個性化的需求霸饲。在技術(shù)上，我們使用 Protocol Buffers 管理埋點(diǎn) Schema臂拓，統(tǒng)一埋點(diǎn)字段和 enum 類型取值厚脉，統(tǒng)一 SDK 發(fā)版。

頁面瀏覽

頁面瀏覽的統(tǒng)計(jì)胶惰，對于 Web 端而言傻工， 因?yàn)?URL 非常明確， 統(tǒng)計(jì)規(guī)則簡單清新孵滞。通常來說中捆，根據(jù)一些正則對 URL 進(jìn)行分類，即可統(tǒng)計(jì)出某類頁面的 PV坊饶。

對于客戶端而言轨香，統(tǒng)計(jì)的方式和 Web 端比較相似。由于客戶端不像 Web 端天然具備 URL幼东，因此需要為頁面?zhèn)卧?URL臂容。只要能被定義 URL，那么 URL 變化了根蟹，即可算一次新的 PV脓杉。客戶端頁面瀏覽統(tǒng)計(jì)中简逮，我們遇到的最難的問題是：頁面是什么球散？如果說頁面的跳轉(zhuǎn)算一次新的曝光，問題在于頁面的功能變化多少算一次頁面的跳轉(zhuǎn)散庶？一個典型的場景是一個頁面中某子模塊進(jìn)行了 Tab 間切換時蕉堰，當(dāng)前頁面的 PV 該如何統(tǒng)計(jì)。目前對于這個問題悲龟，知乎目前沒有做統(tǒng)一屋讶，由業(yè)務(wù)自己來定義。

行為事件

對于行為事件须教，知乎選擇了事件模型皿渗，完整描述 Who斩芭、When、Where乐疆、How 和 What 五大要素划乖。

Who、When 和 How

Who：用戶和設(shè)備的身份特征挤土。

When：埋點(diǎn)觸發(fā)的時間琴庵。

How：埋點(diǎn)發(fā)生時，用戶當(dāng)前的狀態(tài)仰美，例如網(wǎng)絡(luò)是 4G 還是 Wifi细卧，當(dāng)前的 AB 實(shí)驗(yàn)命中情況等等。模型中 Who筒占、When贪庙、How 由埋點(diǎn) SDK 自動生成，埋點(diǎn)人員在絕大多數(shù)情況下不必關(guān)心這三個要素翰苫。

Where

準(zhǔn)確定位一個事件發(fā)生的位置止邮。主要包含以下幾個字段提供埋點(diǎn)設(shè)計(jì)者來做用戶事件的定位。

What

在事件發(fā)生位置上的內(nèi)容信息奏窑，這里采集的內(nèi)容由業(yè)務(wù)決定导披。 例如點(diǎn)擊的卡片是一個回答還是一個 Live，當(dāng)前內(nèi)容的狀態(tài)這類需求埃唯。

對于業(yè)務(wù)定制化的「What」撩匕，最初我們?yōu)閭€性化的需求，設(shè)計(jì)了通用的 ContentInfo墨叛，以及特定領(lǐng)域的數(shù)據(jù)結(jié)構(gòu)止毕。

對于 What，在客戶端開發(fā)上漠趁，我們主要遇到以下問題：

采集需要的數(shù)據(jù)有時和客戶端功能開發(fā)無關(guān)扁凛，客戶端獲取數(shù)據(jù)難

當(dāng)數(shù)據(jù)結(jié)構(gòu)較復(fù)雜，客戶端工作量增大

打錯和打漏的情況闯传，需要發(fā)版谨朝，周期長面對上述打點(diǎn)，對于不是必須由客戶端獲取的數(shù)據(jù)改成由業(yè)務(wù)后端生成 Protocol Buffers 結(jié)構(gòu)甥绿，序列化成 string 隨 api 帶回客戶端字币，客戶端只需將 string 放置到通用的位置即可。數(shù)據(jù)平臺組統(tǒng)一的實(shí)時 ETL 程序會反序列化該結(jié)構(gòu)共缕，過程如下圖所示洗出。

對于 What，在埋點(diǎn)設(shè)計(jì)上骄呼，目前主要遇到以下問題：

埋點(diǎn)的 Key 越來越多共苛，字段和業(yè)務(wù)并沒有在系統(tǒng)級別綁定關(guān)系，有些字段多個業(yè)務(wù)在用蜓萄，枚舉值越來越多隅茎，對埋點(diǎn)設(shè)計(jì)者造成了較多的信息噪音

業(yè)務(wù)依賴了其他業(yè)務(wù)的打點(diǎn)，埋點(diǎn)變更可能導(dǎo)致其他業(yè)務(wù)的核心指標(biāo)受到影響

第一個問題我們正在對埋點(diǎn)字段進(jìn)行治理嫉沽，將平臺通用字段和業(yè)務(wù)字段做系統(tǒng)級別的元信息完善辟犀。第二個問題，我們目前還在探索中绸硕√镁梗「他山之石，可以攻玉」玻佩，如果大家在這塊有好的實(shí)踐經(jīng)驗(yàn)出嘹，歡迎給文章評論中分享知識。

埋點(diǎn)的平臺技術(shù)

埋點(diǎn)管理平臺

當(dāng)公司的規(guī)模生態(tài)還很小時咬崔，埋點(diǎn)使用 Excel 或者 Wiki 管理對埋點(diǎn)使用上影響不大税稼。當(dāng)公司業(yè)務(wù)快速發(fā)展，從一個產(chǎn)品變成多個產(chǎn)品垮斯，從幾十個埋點(diǎn)變成幾千個埋點(diǎn)郎仆，想要精準(zhǔn)的用好埋點(diǎn)，就需要開發(fā)埋點(diǎn)的管理平臺了兜蠕。

埋點(diǎn)管理平臺負(fù)責(zé)管理埋點(diǎn)的元信息扰肌，解決了埋點(diǎn)的錄入和查找需求，同時簡化了客戶端埋點(diǎn)的內(nèi)容熊杨， 是知乎埋點(diǎn)流程的重要組成部分曙旭。同時在工程上又為埋點(diǎn)測試平臺，數(shù)據(jù)采集系統(tǒng)提供埋點(diǎn)的元信息接口晶府。

?查看埋點(diǎn)

支持按照多個標(biāo)簽來查找和過濾埋點(diǎn)夷狰。 在創(chuàng)建埋點(diǎn)時，需要花時間錄入這些元信息郊霎，從長期來看沼头，收益會非常大。

need-to-insert-img

?創(chuàng)建埋點(diǎn)

在創(chuàng)建埋點(diǎn)時书劝，填寫埋點(diǎn)對應(yīng)的業(yè)務(wù)元信息和技術(shù)元信息进倍，包括埋點(diǎn)對應(yīng)的測試說明。埋點(diǎn)管理平臺提供埋點(diǎn)的 key购对，如果需要新增 key 則可向平臺申請谍婉。對于 enum 類型的 value，系統(tǒng)會自動補(bǔ)全杭措。

?生成埋點(diǎn)設(shè)計(jì)文檔

埋點(diǎn)設(shè)計(jì)文檔是工程師開發(fā)埋點(diǎn)的依據(jù)，是埋點(diǎn)流程中交流需要的重要「媒介」楷扬。埋點(diǎn)文檔標(biāo)準(zhǔn)化了埋點(diǎn)的設(shè)計(jì)，包含埋點(diǎn)的以下信息：

埋點(diǎn)的基本信息：業(yè)務(wù)贴见、等級烘苹、應(yīng)用、使用說明片部、打點(diǎn)時機(jī)镣衡、測試說明、需求文檔等

埋點(diǎn)對應(yīng)的角色：數(shù)據(jù)負(fù)責(zé)人档悠、開發(fā)廊鸥、QA

埋點(diǎn)對應(yīng)的字段和字段的取值

?提供埋點(diǎn)元信息 API

數(shù)據(jù)采集服務(wù)會對采集到的埋點(diǎn)寫入到 Kafka 中，對于各個業(yè)務(wù)的實(shí)時數(shù)據(jù)消費(fèi)需求辖所，我們?yōu)槊總€業(yè)務(wù)提供了單獨(dú)的 Kafka惰说，流量分發(fā)模塊會定期讀取埋點(diǎn)管理平臺提供的元信息，將流量實(shí)時分發(fā)的各業(yè)務(wù) Kafka 中缘回。

need-to-insert-img

埋點(diǎn)測試平臺

埋點(diǎn)的質(zhì)量是數(shù)據(jù)的生命線助被，一旦出現(xiàn)問題，則會導(dǎo)致整條大數(shù)據(jù)鏈路的數(shù)據(jù)價值出現(xiàn)問題切诀。埋點(diǎn)異常不但影響決策揩环，修復(fù)數(shù)據(jù)同樣會消耗大量的精力和時間，最直接的后果就是雖然數(shù)據(jù)量越來越大幅虑，數(shù)據(jù)本身卻無法有效的使用丰滑。知乎的數(shù)據(jù)團(tuán)隊(duì)在 2016 年做了一個埋點(diǎn)的小工具，只要輸入測試設(shè)備的 id倒庵，就可以查看對應(yīng)的埋點(diǎn)信息褒墨。這個工具主要有以下幾個痛點(diǎn)：

埋點(diǎn)日志量大，通常很難找到自己想測試的埋點(diǎn)

展示一整條日志擎宝，系統(tǒng)無法判定埋點(diǎn)是否準(zhǔn)確郁妈，全靠肉眼來看

無法創(chuàng)建測試用例，不能做回歸測試

埋點(diǎn)漏了或者錯了人力尚能發(fā)現(xiàn)绍申，埋點(diǎn)重復(fù)發(fā)送人很難發(fā)現(xiàn)

面對如上問題噩咪，我們重新設(shè)計(jì)了埋點(diǎn)測試平臺，目標(biāo)是讓埋點(diǎn)測試更自動化和智能化极阅，主要有以下功能：

可創(chuàng)建埋點(diǎn)測試用例胃碾，打通埋點(diǎn)管理平臺，支持多條件篩選埋點(diǎn)

支持發(fā)起埋點(diǎn)測試實(shí)例筋搏，只展示埋點(diǎn)測試用例中的埋點(diǎn)仆百，多余信息單獨(dú)展示

自動化提示埋點(diǎn)打錯、打漏和打重奔脐，前端界面高亮展示俄周，生成測試報(bào)告

支持手機(jī)掃碼連上系統(tǒng)吁讨，無需人輸設(shè)備 id

其他：關(guān)于 Hybrid 類型埋點(diǎn)

客戶端內(nèi)的 H5 生成埋點(diǎn)使用的是 JavaScript SDK，如果直接發(fā)送到日志收集服務(wù)峦朗，會丟失客戶端的重要屬性建丧。知乎的做法是將 H5 的日志發(fā)送給客戶端，由客戶端處理后發(fā)送給日志接收服務(wù)甚垦。在知乎我們對 H5 這類統(tǒng)稱 Hybrid茶鹃，我們自研了 Hybrid 框架涣雕，跨端通信和埋點(diǎn)傳輸由框架提供支持艰亮，自動化解決和 ZA （Zhihu Analytics Log Server）的通信問題。

Hybrid 框架主要處理以下的問題：

對于 Native 和 JS 混合的頁面挣郭，該頁面曝光統(tǒng)計(jì)

對于 JS 頁面內(nèi)部的跳轉(zhuǎn)迄埃，頁面曝光的統(tǒng)計(jì)

JS SDK 生成的日志，傳輸?shù)?Native兑障，并發(fā)送給日志收集服務(wù)

對于 UTM 系列追蹤鏈侄非，做到跨 Native 和 JS 支持

總 ?結(jié)

今天的大數(shù)據(jù)發(fā)展趨勢之快，對于很多公司來說都是挑戰(zhàn)流译，埋點(diǎn)是數(shù)據(jù)整個數(shù)據(jù)鏈路中的起點(diǎn)逞怨，是數(shù)據(jù)的生命之源。隨著知乎的快速發(fā)展福澡，業(yè)務(wù)越來越多叠赦，知乎的埋點(diǎn)模型、流程和平臺技術(shù)在不斷迭代當(dāng)中革砸，在應(yīng)用實(shí)踐上還有很大的改進(jìn)的空間除秀。