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

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

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

一、后端埋點

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

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

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

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

• 優(yōu)點：可控性高，滿足所有的需求。
• 缺點：研發(fā)成本、設(shè)計成本高。

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

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

全量埋點：直接組裝衛(wèi)星發(fā)射到天上，實時監(jiān)控高速路上的用戶行為。

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

二、后端埋點之代碼埋點

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

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

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

1. 帶入到場景中

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

2. 細(xì)節(jié)

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

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

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

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

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

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

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

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

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

四、后端埋點之日志埋點

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

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

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

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

一級DEBUG：研發(fā)主要用于日常的調(diào)試，所以在調(diào)試時隨處可見。

二級INFO（information）：重要結(jié)果的輸出，在一些函數(shù)方法結(jié)果的位置可以看見，主要是用于關(guān)鍵結(jié)果。

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

四級ERROR：重要錯誤級別，代表系統(tǒng)無法繼續(xù)運行。

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

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

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

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

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

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

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

五、擴展

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

作者：wcof，在努力做產(chǎn)品不做產(chǎn)品經(jīng)理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。