編輯導讀：數據埋點作為數據分析、數據倉儲等的基礎，在設計數據埋點的時候我們不光要依據前端特性去設計前端的數據埋點，還需要了解後端特性結合業務進行埋點設計。本文作者對此五個維度的分析，希望對你有幫助。
一般只要説到數據埋點通常情況下都是指前端的數據埋點，而並非後端數據埋點。所以往往會忽視後端埋點在整個數據埋點的作用。數據埋點作為數據分析、數據倉儲等的基礎，在設計數據埋點的時候我們不光要依據前端特性去設計前端的數據埋點，還需要了解後端特性結合業務進行埋點設計。
可能對於我們來説，只有前端內容是我們最直觀感受，從而花費大量功夫去處理前端的埋點設計，而對於看不見的後端埋點我們往往忽視。這樣使我們產品設計師（產品經理）對於數據埋點的設計理解侷限在了前端交互上，把同樣重要的後端埋點設計直接交給研發leader或是架構師自主設計不管不顧，這是不對的。至此本次我們聊一下後端埋點，以便配合研發leader和架構師開展工作。
一、後端埋點數據埋點的最終歸宿地都會是數據庫，不管它是前端埋點還是後端埋點他們都會存入MySql或MongoDB的數據庫中（數據庫類型）。
相比較前端埋點在可視化頁面上交互和觸發，後端埋點更多是在對業務數據的請求和記錄上。前後端進行比較，後端埋點在存儲用户操作數據上會比前端晚一步 ，但在業務流程上又會比前端快一步。是因為當用户進入頁面操作時，都是在頁面上先進行操作，所有前端埋點的觸發永遠會比後端埋點快一步。但是在業務流程上（例如登錄，訂購等），後端埋點會比前端埋點更快一步，因為業務需要後端會和數據庫進行實時“互動”，在互動結束後才會將結果反饋給前端，再由前端和用户進行交互。
後端數據埋點不像前端那麼多花樣，要去思考用户路徑和用户交互，後端埋點更加註重業務沉澱和業務邏輯。後端埋點和前端埋點一樣，也分全量、模塊化和代碼埋點三種。除此之外，後端埋點還有個特殊方式就是日誌。全量和模塊化埋點我就不在過多闡述，因為他倆對於產品設計師（產品經理）來説沒有太多的要求，直接溝通研發將對應的SDK或API裝載即可，我們重點説代碼和日誌兩種方式。
代碼埋點：我們請了一個施工隊，這個施工隊聽你的指揮，並根據你在高速路上指定的位置建造收費站，這種都是一磚一瓦的施工。
- 優點：可控性高，滿足所有的需求。
- 缺點：研發成本、設計成本高。
可視化（模塊化）埋點：我們將需要建造的收費站進行模具化，只需要到指定位置放置模具，對模具直接澆灌水泥，收費站就直接成型。
- 優點：操作方面，佈置快捷
- 缺點：適應性差，緯度匹配度因“路”而異
全量埋點：直接組裝衞星發射到天上，實時監控高速路上的用户行為。
- 優點：用户的一舉一動我們都知曉
- 缺點：數據傳輸量大，數據需要二次清洗，佔用大量實時資源進行數據傳輸。
和前端埋點相似，代碼方式的埋點可控性高，成本也高。在理解後端埋點設計上，我們可以從前端埋點設計需要考慮的4大生命週期（頁面的創建、加載、更新、銷燬）進行過度理解。
因為後端的操作都在於代碼的請求和運算（請求中），那麼我們假設將整個後端埋點按照前端埋點設計的邏輯進行拆分，分別是請求前、請求中、請求後三個部分。
- 請求前：可以瞭解請求數據的初始狀態情況，是哪位用户的，他準備買什麼商品，在哪裏進購買的（坑位：首頁、推薦等）。
- 請求中：依據請求的初始數據去獲取用户的狀態（是否是會員、是否封禁），商品的狀態（庫存量，價格，詳細信息等）。
- 請求後：知道明確的請求結果，知道支付是否成功，失敗的原因是什麼，是庫存不夠，餘額不足或是用户自己取消支付等。
用户點擊支付商品，用户觸發前段埋點，這時前端向後端請求支付（請求前），後端根據前端請求過來的數據包內容「支付信息、商品信息、用户信息等」去驗證這些正確性（請求中），隨後將驗證結果打包處理給到前端（請求後），讓前端給用户繼續交互（流程圖經過縮減主要用於認知，只顯示主要環節所以不必太過於較真）。
一般的驗證可分為兩部分，一種是數據的驗證，後端對傳輸過來的加密參數進行頭部驗證，驗證數據的安全性。以保證這個數據不是非法請求。另一個驗證是業務驗證，驗證傳輸過來數據的準確性。用户信息對不對，庫存對不對，支付密碼對不對等。
文中的請求是以”前端”的視角在説。因為我們最有感知的請求中也就是我們常説的加載中。
單單關注請求是不足以支撐我們理解後端埋點。因為後端是方法函數之間的調用，所以，我們還需要關注“服務”。例如後端在接參（接收到前端頁面的請求）後，需要將參數中用户信息拿着用户中心去做比對，用於驗證用户的屬性。與此同時將去商品中心驗證商品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協議。