編輯導讀：資料埋點作為資料分析、資料倉儲等的基礎，在設計資料埋點的時候我們不光要依據前端特性去設計前端的資料埋點，還需要了解後端特性結合業務進行埋點設計。本文作者對此五個維度的分析，希望對你有幫助。
一般只要說到資料埋點通常情況下都是指前端的資料埋點，而並非後端資料埋點。所以往往會忽視後端埋點在整個資料埋點的作用。資料埋點作為資料分析、資料倉儲等的基礎，在設計資料埋點的時候我們不光要依據前端特性去設計前端的資料埋點，還需要了解後端特性結合業務進行埋點設計。
可能對於我們來說，只有前端內容是我們最直觀感受，從而花費大量功夫去處理前端的埋點設計，而對於看不見的後端埋點我們往往忽視。這樣使我們產品設計師（產品經理）對於資料埋點的設計理解侷限在了前端互動上，把同樣重要的後端埋點設計直接交給研發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協議。