透過埋點，讓數據說話：埋點基本知識

要分析Web/App上的用戶行為，埋點是不可避免的過程，正確埋點的重要性，基本上所有的PM或者數據人員都需要了解。

然而在工作過程中，我發現許多產品經理、營運人員對埋點的認知不太充足(甚至跟業務數據混淆在一起)，趁著工作空擋時間，把基本知識梳理了一下。

因為埋點本身從技術實現並不困難，但是整個埋點過程可以說複雜又繁瑣，有很多細節、流程要考慮。例如Web/H5/App數據如何統一？信息是要在前端還後端採集？這麼多點位如何管理？如何降低數據丟包？

身為埋點數據“使用方”的角色，希望最大程度的讓本文的描述語言易懂。技術部分，參考了許多網上的文章，也諮詢了身邊前端開發朋友，以保證觀念正確。如果有疏忽之處，還請大家糾正。

什麼是埋點

大數據應用一般會有採集、加工、存儲、計算及可視化這幾個環節。其中採集做為源頭，在確保全面、準確、及時的前提下，最終加工出來的指標才是有價值的。埋點（學名叫事件追蹤，英文名event tracking)，即是一種重要的數據採集手段。

每一個需要監測的用戶與頁面交互的行為，都被稱為一個監測點。為了讓這些監測點上的行為數據被我們收集到，我們必須在這些監測點上部署代碼，這樣的程序代碼，在網站上叫監測代碼，在app中叫SDK（Software Development Kit）。

無論要監測網站，還是要監測app，都必須加上這類代碼，不加代碼就收集不到數據。手工一個一個添加代碼的過程，被形象化的稱為埋點。

從技術上說，就是在APP或者web產品中植入一段代碼，監控用戶行為事件（例如某個頁面的曝光）。用戶一旦觸發了該事件，就會上傳埋點代碼中定義的、需要上傳的有關該事件的信息。

從業務價值來理解，埋點是產品經理、數據分析師，基於業務需求或產品需求對用戶在應用內產生行為的每一個事件對應的頁面和位置做監測，以便相關人員追踪用戶行為，推動產品優化或指導運營的一項工程。應用方向包含：

了解用戶行為，比如用戶的使用習慣，用戶的決策路徑，用戶的注意力分佈
掌握產品動向，比如產品用戶量，產品所處的生命週期，目前的數據表現
支持產品決策，比如新功能的上線，舊功能的迭代優化

埋點數據的採集的方式

具體的步驟一般是，產品經理在提需求，需要在某個頁面的某個事件進行埋點，在這個過程中，產品會對該頁面和事件按照一套規則進行編碼，同時產品經理也會將這一埋點需要上傳的參數告知開發。工程師明確需求後就會進行開發。

這代碼若是放在前端，則稱為前端埋點、放在後端則稱為後端埋點。因為前端行為比較豐富，主要多是前端為主(或是前後端並存)。

以前端頁面曝光事件為例：

開發埋點專用SDK，簡化開發效率-半自動埋點與全埋點

不論是前端埋點還是後端埋點，都需要工程師將一個一個專用的監測代碼加在每一個監測點上，這過程被形象的稱作手動埋點。為了要保證這些代碼跟監測點一一對應，不能錯加或者漏加，這是一個繁瑣的工作。

半自動埋點就是為了解決這種問題。

比如100個埋點中，可能80個埋點都是曝光事件，這類非常相似的埋點完全可以用一套手段去解決。

即把部分人工的工作進行標準化，開發成專用的SDK，前端工程師只要通過sdk提供的接口來開發，就可以不需要考量會話管理、日誌上報機制、內部業務特殊處理、參數的生命週期等等，只需要關注：

SDK的初始化配置
事件怎麼標示、需要哪些參數、如何觸發

再進一步抽像，能不能用一個監測代碼，就能對網頁上或者app上有明確的位置的監測點都進行自動的監測呢？也就是，不管需不需要，將所有的點都埋了。

這種技術稱為全埋點(或是無埋點)。

無埋點這個名詞，雖然看起來沒有了埋點這個動作，但本質上是一樣的，都是透過SDK實現的。

並不是說不要添加代碼，而是不需要開發人員添加額外代碼。可以理解為是代碼幫開發者完成了『處處埋點』的繁瑣工作，這種SDK不需調用，已經直接嵌入在Web/App中。

但也因為全埋點是由一套SDK對應一套數據上傳方式，需要盡可能通用，以便能適用更多場景，相對的，具有個性的業務場景就被犧牲了，一般只能對頁面曝光、關閉，控件點擊這種通用事件進行全自動埋點。

埋點沒有最完美，只有最適合的方式

不同埋點方式各自有自己的優勢和劣勢，因此有著不同的適用場景。面對不同的場景，我們需要明確埋點的目的是什麼，並綜合企業資源，技術架構，產品特性等多方面考慮。

是探索、監控、還是深度業務分析？
需要採集的事件多嗎？
實現這個目標擁有的資源是什麼？

如何描述用戶的一次行為？事件模型

事件模型，由 Who、When、Where和 What 組成。

Who:用戶和設備的身份，例如訪客標識，設備指紋，登錄ID
When:當事件發生時間，上報時間
Where:設備環境，網絡環境，業務環境
What:什麼事件標識，事件參數

其中Who、When由埋點SDK自動，埋點人員基本不必關心這要素。

Ｗhere中的業務環境跟what ，則容易受到不同業務的理解而產生不同標記方式，如果每個業務都自定義定義標識方式，那麼每次分析工作都需要重新開發，無法重複邏輯，這將極大的浪費開發資源，因此需要制定統一的規範

業務環境位置規範，根據公司、不同APP的設計方式，可能有不同規範，一般會分成1.頁面、2.模塊 3.組件 4.展位/頻道，原則上需定義到最小的元素。以有讚跟美團為例：

而what通常由業務方決定，但是有可能枚舉值越來越多，對埋點設計者跟使用者多少造成了混淆。

設計舉例：

事件類型(event_type)：點擊(click)、瀏覽(display)、停留、收藏…
事件標示(event_sign)：pay、call…
事件名稱(event_name)：立即支付、撥打電話…(事件標示中文名)
頁面類型(page_type)：訂單支付頁、Landingpage_001
頁面id(page_id)：頁面唯一編碼

埋點數據亂？日誌加工與數倉建設

原始日誌數據收集上來後，還處於非常精簡的狀態，需要進一步加工成日誌中間層，主要有以下幾個環節：

批量上報的日誌拆分
日誌模型的格式化處理
信息的二次加工和維度擴展，如IP、http_agent的解析等
異常流量的清洗
會話信息的補充，如落地頁、二跳頁、停留時長的計算

日誌數據儲存及管理，則是數倉面臨挑戰，有賴數倉工程師建模與數據平台性能。挑戰比如：

數據量大，每天幾百億條的日誌，數倉模型要使用成本低、查詢性能較好
採集的客戶端種類多、日誌種類多，數倉建模過程中維度建設複雜、數據整合複雜

管好埋點-埋點管理平台

埋點業務的早期，通常比較單純，埋點方案&質量問題可以記錄在Excel、共享文檔中。但若是項目快速增加，此方式則存在弊端：

登記格式不統一
事件查找不便，不知道已有哪些事件
迭代更新事件未合併，同時存在多份信息
開發進度、測試進度無法監控
埋點質量問題無法快速對接

其中，常見的質量問題包含：

事件重複&丟失：重複是由於SDK自身或者前端開發疏忽的問題，導致相同事件重複發送；丟失可能是設備、網絡原因，或者是開發者漏埋導致。
事件參數錯誤：參數未傳、值類型不對、值內容不對。
事件斷流：前端在做改造升級的時候，可能導致事件上報不規範，或者誤下線

為了降低上述問題，管理大量埋點往往也需要埋点管理平台，不論UI怎麼設計，核心功能應包含以下幾點：

提供埋點信息的錄入功能。
展示並可查詢某埋點的詳細信息。例如物理編碼信息和對應的業務含義信息，埋點的上線版本和時間，埋點管理員責任人，埋點信息儲存的數倉表名稱以及必要的埋點數據結構體（對個性化埋點可能出現的上傳數據中新加字段的解釋）。
輔助功能。如埋點數據量的監控，埋點信息預覽，埋點數據通用分析及可視化展示等。

交互圖可以參考：【用户行为采集】（三）埋点管理系统及神策分析-埋点管理

數據質量的好壞，直接影響分析，因此埋點上線前的測試也是一個重要的環節

埋點代碼是否引入
事件參數是否缺失、點位以及相關事件參數是否正常加入埋點
數據能否正常上報
日誌格式是否是否符合要求
通用業務參數是否收集完整
業務、頁面、組件、事件是否登記

埋點開發是一個跨部門的流程

前面的描述，提到的角色包含了前端、後端、數據、產品經理等，可見埋點這個事情是一個多團隊協作的事情，所以流程很重要，不然會發生不必要的分歧。

數據分析師和產品經理主要是數據的使用者，工作內容是發現和解決業務的問題，不斷對產品進行迭代
前端工程師對代碼的細節和打點時機的最多了解，但是對於數據具體的使用不見得很清晰
數據團隊，對埋點的規範進行管理，以及日誌清洗、數倉模型等。

一般來說，需求由分析師或是由業務方產品經理提出，業務方產品經理設計埋點配置文檔，交由前端工程師進行埋點開發，再交給測試與數據組開發進行埋點驗收，通過後再交付數據到分析師這進行數據任務開發與分析。

參考資料：