編輯導讀：數據埋點作為數據分析、數據倉儲等的基礎，在設計數據埋點的時候我們不光要依據前端特性去設計前端的數據埋點，還需要了解后端特性結合業務進行埋點設計。本文作者對此五個維度的分析，希望對你有幫助。

一般只要說到數據埋點通常情況下都是指前端的數據埋點，而并非后端數據埋點。所以往往會忽視后端埋點在整個數據埋點的作用。數據埋點作為數據分析、數據倉儲等的基礎，在設計數據埋點的時候我們不光要依據前端特性去設計前端的數據埋點，還需要了解后端特性結合業務進行埋點設計。

可能對于我們來說，只有前端內容是我們最直觀感受，從而花費大量功夫去處理前端的埋點設計，而對于看不見的后端埋點我們往往忽視。這樣使我們產品設計師（產品經理）對于數據埋點的設計理解局限在了前端交互上，把同樣重要的后端埋點設計直接交給研發leader或是架構師自主設計不管不顧，這是不對的。至此本次我們聊一下后端埋點，以便配合研發leader和架構師開展工作。

一、后端埋點

數據埋點的最終歸宿地都會是數據庫，不管它是前端埋點還是后端埋點他們都會存入MySql或MongoDB的數據庫中（數據庫類型）。

相比較前端埋點在可視化頁面上交互和觸發，后端埋點更多是在對業務數據的請求和記錄上。前后端進行比較，后端埋點在存儲用戶操作數據上會比前端晚一步 ，但在業務流程上又會比前端快一步。是因為當用戶進入頁面操作時，都是在頁面上先進行操作，所有前端埋點的觸發永遠會比后端埋點快一步。但是在業務流程上（例如登錄，訂購等），后端埋點會比前端埋點更快一步，因為業務需要后端會和數據庫進行實時“互動”，在互動結束后才會將結果反饋給前端，再由前端和用戶進行交互。

后端數據埋點不像前端那么多花樣，要去思考用戶路徑和用戶交互，后端埋點更加注重業務沉淀和業務邏輯。后端埋點和前端埋點一樣，也分全量、模塊化和代碼埋點三種。除此之外，后端埋點還有個特殊方式就是日志。全量和模塊化埋點我就不在過多闡述，因為他倆對于產品設計師（產品經理）來說沒有太多的要求，直接溝通研發將對應的SDK或API裝載即可，我們重點說代碼和日志兩種方式。

代碼埋點：我們請了一個施工隊，這個施工隊聽你的指揮，并根據你在高速路上指定的位置建造收費站，這種都是一磚一瓦的施工。

• 優點：可控性高，滿足所有的需求。
• 缺點：研發成本、設計成本高。

可視化（模塊化）埋點：我們將需要建造的收費站進行模具化，只需要到指定位置放置模具，對模具直接澆灌水泥，收費站就直接成型。

• 優點：操作方面，布置快捷
• 缺點：適應性差，緯度匹配度因“路”而異

全量埋點：直接組裝衛星發射到天上，實時監控高速路上的用戶行為。

• 優點：用戶的一舉一動我們都知曉
• 缺點：數據傳輸量大，數據需要二次清洗，占用大量實時資源進行數據傳輸。

二、后端埋點之代碼埋點

和前端埋點相似，代碼方式的埋點可控性高，成本也高。在理解后端埋點設計上，我們可以從前端埋點設計需要考慮的4大生命周期（頁面的創建、加載、更新、銷毀）進行過度理解。

因為后端的操作都在于代碼的請求和運算（請求中），那么我們假設將整個后端埋點按照前端埋點設計的邏輯進行拆分，分別是請求前、請求中、請求后三個部分。

• 請求前：可以了解請求數據的初始狀態情況，是哪位用戶的，他準備買什么商品，在哪里進購買的（坑位：首頁、推薦等）。
• 請求中：依據請求的初始數據去獲取用戶的狀態（是否是會員、是否封禁），商品的狀態（庫存量，價格，詳細信息等）。
• 請求后：知道明確的請求結果，知道支付是否成功，失敗的原因是什么，是庫存不夠，余額不足或是用戶自己取消支付等。

1. 帶入到場景中

用戶點擊支付商品，用戶觸發前段埋點，這時前端向后端請求支付（請求前），后端根據前端請求過來的數據包內容「支付信息、商品信息、用戶信息等」去驗證這些正確性（請求中），隨后將驗證結果打包處理給到前端（請求后），讓前端給用戶繼續交互（流程圖經過縮減主要用于認知，只顯示主要環節所以不必太過于較真）。

2. 細節

一般的驗證可分為兩部分，一種是數據的驗證，后端對傳輸過來的加密參數進行頭部驗證，驗證數據的安全性。以保證這個數據不是非法請求。另一個驗證是業務驗證，驗證傳輸過來數據的準確性。用戶信息對不對，庫存對不對，支付密碼對不對等。

文中的請求是以”前端”的視角在說。因為我們最有感知的請求中也就是我們常說的加載中。

單單關注請求是不足以支撐我們理解后端埋點。因為后端是方法函數之間的調用，所以，我們還需要關注“服務”。例如后端在接參（接收到前端頁面的請求）后，需要將參數中用戶信息拿著用戶中心去做比對，用于驗證用戶的屬性。與此同時將去商品中心驗證商品sku的商品信息，并通過商品信息去查詢正價和銷售價。隨后在去調用活動中心去查詢活動信息，最后再由訂單中心生成訂單等等。

這也是為什么我說單單理解請求不足以支撐我們進行理解后端埋點。在了解這些內容后我們再去理解如何在方法函數中進行埋點，將會事半功倍。

三、為什么要后端埋點，前端行不行？

為什么我們不直接全部將埋點設計在前端，而是去做后端埋點。是因為如果設計通過前端埋點進行，首先不能放在頁面創建，因為頁面才創建顯示出來的時候，用戶還沒進行操作，我們無法確定用戶要辦理什么業務（登錄業務、支付業務、下單業務等），所以這里首先不能進行業務埋點。同時這里基本以圖片加載為主，讓用戶更快了解主題。

其次不能放在頁面加載位置，這樣會多一次埋點請求，網絡好，數據量小用戶還感知不了。如果是淘寶、拼夕夕這種數據量大的C端應用，或是其他高并發的B端軟件，可能因為要多發一次埋點請求，會大大增加用戶的等待時間，造成體驗不流暢。

最后還是不能放在頁面銷毀，用戶突然將頁面關了（網頁：直接關閉瀏覽器、APP：直接清空后臺運行）都會造成埋點還沒請求還沒發出就沒了，讓數據采集不夠完善。

所以不采用前端對業務進行埋點，并且使用后端埋點，在對數據進行采集的時候是一個同步操作，和用戶的業務是同時開展的，因此將不會影響用戶在前端體驗上的任何操作和業務開展。

四、后端埋點之日志埋點

后端埋點除了接口服務的請求進行埋點外，還有一種方法叫日志。在真實的工作環節中，后端代碼埋點的可用性很差。首先，因為后端是操作數據和業務數據數據交互的地方，只要后端不出問題，前端出再多的問題也無傷大雅。這也是往往我們看見很多軟件應用，前端頁面垃圾（樣式垃圾，交互反人類，點擊按鈕沒反饋等），但卻依然對外使用。

其次，說可用性差是因為應用總歸是需要對外或對內使用，會面臨大量數據請求，100個業務請求就需要觸發后端埋點100次，還有可能因為業務的復雜性會調用幾個或十幾個服務，這時我們的數據埋點可能觸發不止100次，而且這些請求都是需要額外的服務器資源去處理。當出現高并發場景時（搶購、秒殺等等），這樣的數據埋點可能會暫用大量的資源，最后從而影響到業務服務讓服務器“暴斃”。面對這樣的情況，也就有了第二次后端埋點的方法，日志埋點。

日志本就是后端代碼框架的一部分組件算是自帶，一般以.log結尾的文件，幾乎就是日志文件，如果不懂我們也可以將日志文件看成TXT、word文檔便于理解(以liunx登錄日志為例，會顯示每次的登錄位置（IP）、登錄時間等）。

首先，我告訴大，幾乎所有的軟件應用的所有運行行為都會產生日志，關鍵在于我們需不需要使用，需不需要對相關日志進行采集保存而已。常見的系統日志會分為五個等級，分別是：

一級DEBUG：研發主要用于日常的調試，所以在調試時隨處可見。

二級INFO（information）：重要結果的輸出，在一些函數方法結果的位置可以看見，主要是用于關鍵結果。

三級WARNING：普通報錯級別，代表不會影響系統的運行，常見賬號密碼錯誤和一些奇奇怪怪的地方。

四級ERROR：重要錯誤級別，代表系統無法繼續運行。

五級CRITICAL：重大錯誤，估計直接服務器爆炸了（幾乎不見）

在以上五個日志級別中，對于三級WARNING、四級ERROR、五級CRITICAL我們不用去管，這個對于我們產品來說用處不大，主要是研發用于定位問題。而二級INFO才是我們主要日志埋點使用。

在后端設計中，日志的使用上極為便捷。因為現在大多數后端都喜歡使用Java作為研發語言，并采用spring boot作為技術棧有十分成熟的日志解決方案這里我就不過的闡述技術上的了（未使用也不急，日志是基本功能，幾乎99%的后端技術棧都有各自的解決方案）。

在日志埋點的設計上盡可能提升日志數據的寬度。何為寬度？寬度是指盡可能窮舉完某個需求或業務所需要日志記錄的數據字段。

例如，在生成訂單的時候日志是否需要，用戶ID、訂單ID、當前金額、商品SKU、平臺ID等等。因為數據的延后行，只有你保存到日志的數據才有記錄，沒有保存的就沒有，所有就算你當前不使用相關數據，但是你的寬度足夠，在后期需要時，也可以從日志中提取出來。

如果寬度不夠，在需要使用某些日志未存儲的數據時，只能修改日志，從零開始。因此，在設計日志寬度的時候，除了從業務入手以外，產品設計師（產品經理）還需要溝通后端研發、后端技術leader和后端架構師進行相互研磨便于完善寬度。

日志的設計要點和上面代碼埋點中講述的場景有異曲同工之妙。唯一不同的是我們不用再去關注什么請求前、請求中和請求后。我們只需要關注的是結果封裝這里。關注各個服務之間的結果，將需要的內容放入日志保存即可。

五、擴展

在我們采用日志作為數據埋點方式的時候會存在一個問題，日志文件里面的數據量會越來越大，這個時候我們每次再去日志中提取數據，會因為數據體量的問題，變得十分緩慢。面對這樣的情況我們可以將日志中部分常用關鍵數據提取出來，用數據庫進行存儲。后期需要使用的時候直接通過數據庫獲取即可，不用采取查閱日志。將日志作為溯源文件即可。

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議。