埋點作為商業(yè)智能（BI）和人工智能（AI）體系中重要的一環(huán)，是公司提升產(chǎn)品工程質(zhì)量、實施 AB Testing、個性化推薦服務(wù)重要的數(shù)據(jù)來源。在傳統(tǒng)的純 Web 和 Native 開發(fā)的產(chǎn)品中，埋點從技術(shù)的角度來說未必多深奧，但從業(yè)務(wù)的角度來說要做到埋點設(shè)計規(guī)范、流程高效和保證質(zhì)量卻是很難。本文重點介紹一下知乎客戶端的埋點模型、流程和平臺技術(shù)。

客戶端埋點為什么難？

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

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

埋點的流程

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

目前知乎的埋點流程如下圖所示。

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

能力

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

意愿

為了快速推進業(yè)務(wù)的埋點，數(shù)據(jù)平臺組招聘了埋點設(shè)計人員來設(shè)計全公司的打點。這個方法在短期內(nèi)幫助公司的埋點工作順利進行，但是很快隨著業(yè)務(wù)持續(xù)的增長，即使是埋點設(shè)計的老手也無法快速響應(yīng)業(yè)務(wù)的埋點需求，跨業(yè)務(wù)的任務(wù)排期也給業(yè)務(wù)帶來較多的困擾。我們發(fā)現(xiàn)埋點的流程如果做到業(yè)務(wù)閉環(huán)，能讓整個流程變得更為高效和順利。業(yè)務(wù)中哪個角色更有意愿來設(shè)計埋點是流程是否高效的重要因素。以下是業(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)品進行迭代
• 工程師對代碼的細(xì)節(jié)和打點時機最為了解，但是對于數(shù)據(jù)具體的使用不見得很清晰
• 數(shù)據(jù)倉庫接口人負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的生產(chǎn)，和數(shù)據(jù)倉庫團隊對接，對埋點的定義需要有深入的理解綜合考慮各角色的意愿后，我們設(shè)計了「業(yè)務(wù)數(shù)據(jù)負(fù)責(zé)人」這個角色，來整體來負(fù)責(zé)業(yè)務(wù)的數(shù)據(jù)生產(chǎn)工作，主要負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)倉庫需求和埋點設(shè)計。

工具

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

埋點的模型

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

頁面瀏覽

頁面瀏覽的統(tǒng)計，對于 Web 端而言， 因為 URL 非常明確， 統(tǒng)計規(guī)則簡單清新。通常來說，根據(jù)一些正則對 URL 進行分類，即可統(tǒng)計出某類頁面的 PV。

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

行為事件

對于行為事件，知乎選擇了事件模型，完整描述 Who、When、Where、How 和 What 五大要素。

Who、When 和 How

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

When：埋點觸發(fā)的時間。

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

Where

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

What

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

對于業(yè)務(wù)定制化的「What」，最初我們?yōu)閭�性化的需求，設(shè)計了通用的 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ā)版，周期長面對上述打點，對于不是必須由客戶端獲取的數(shù)據(jù)改成由業(yè)務(wù)后端生成 Protocol Buffers 結(jié)構(gòu)，序列化成 string 隨 api 帶回客戶端，客戶端只需將 string 放置到通用的位置即可。數(shù)據(jù)平臺組統(tǒng)一的實時 ETL 程序會反序列化該結(jié)構(gòu)，過程如下圖所示。

對于 What，在埋點設(shè)計上，目前主要遇到以下問題：

• 埋點的 Key 越來越多，字段和業(yè)務(wù)并沒有在系統(tǒng)級別綁定關(guān)系，有些字段多個業(yè)務(wù)在用，枚舉值越來越多，對埋點設(shè)計者造成了較多的信息噪音
• 業(yè)務(wù)依賴了其他業(yè)務(wù)的打點，埋點變更可能導(dǎo)致其他業(yè)務(wù)的核心指標(biāo)受到影響

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

埋點的平臺技術(shù)

埋點管理平臺

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

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

查看埋點

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

創(chuàng)建埋點

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

生成埋點設(shè)計文檔

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

1. 埋點的基本信息：業(yè)務(wù)、等級、應(yīng)用、使用說明、打點時機、測試說明、需求文檔等
2. 埋點對應(yīng)的角色：數(shù)據(jù)負(fù)責(zé)人、開發(fā)、QA
3. 埋點對應(yīng)的字段和字段的取值

提供埋點元信息 API

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

埋點測試平臺

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

• 埋點日志量大，通常很難找到自己想測試的埋點
• 展示一整條日志，系統(tǒng)無法判定埋點是否準(zhǔn)確，全靠肉眼來看
• 無法創(chuàng)建測試用例，不能做回歸測試
• 埋點漏了或者錯了人力尚能發(fā)現(xiàn)，埋點重復(fù)發(fā)送人很難發(fā)現(xiàn)

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

• 可創(chuàng)建埋點測試用例，打通埋點管理平臺，支持多條件篩選埋點
• 支持發(fā)起埋點測試實例，只展示埋點測試用例中的埋點，多余信息單獨展示
• 自動化提示埋點打錯、打漏和打重，前端界面高亮展示，生成測試報告
• 支持手機掃碼連上系統(tǒng)，無需人輸設(shè)備 id

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

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

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

• 對于 Native 和 JS 混合的頁面，該頁面曝光統(tǒng)計
• 對于 JS 頁面內(nèi)部的跳轉(zhuǎn)，頁面曝光的統(tǒng)計
• JS SDK 生成的日志，傳輸?shù)?Native，并發(fā)送給日志收集服務(wù)
• 對于 UTM 系列追蹤鏈，做到跨 Native 和 JS 支持

總  結(jié)

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

團隊介紹

知乎的大數(shù)據(jù)平臺團隊，屬于知乎的技術(shù)中臺，是具有數(shù)據(jù)驅(qū)動基因的公司發(fā)展到一定階段必然會重點打造的團隊。面對業(yè)務(wù)的多元化發(fā)展和精細(xì)化運營，數(shù)據(jù)的需求變得越來越多，大數(shù)據(jù)平臺團隊主要負(fù)責(zé)：

• 搭建公司級可視化分析系統(tǒng)和數(shù)據(jù)服務(wù)
• 維護全端數(shù)據(jù)的采集、集成和數(shù)據(jù)倉庫，對接業(yè)務(wù)系統(tǒng)
• 管理數(shù)據(jù)生命周期，提供一站式的數(shù)據(jù)開發(fā)、元信息管理和任務(wù)調(diào)度平臺
• 提供 AB Testing 實驗平臺，系統(tǒng)化集成實驗分析框架，推動業(yè)務(wù)增長

 

來自：http://www.infoq.com/cn/articles/event-tracking-in-zhihu

 

標(biāo)簽： 大數(shù)據(jù) 大數(shù)據(jù)發(fā)展 大數(shù)據(jù)平臺 代碼 數(shù)據(jù)分析 通信 推廣 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。