給技術同窗的建議：人人都該懂的埋點知識

導語：什麼是埋點？咱們爲何須要懂埋點？易觀方舟官網項目經理李偉濤，經過自身經驗實例爲你們深刻淺出解析，做爲技術工程師、程序員，也爲了更好推動公司業務產品及項目，在運營市場提出需求以前，咱們也能夠提早作好一份可行性的埋點設計方案。

不少人看到這個一臉懵，埋點究竟是啥玩意兒，這麼技術專業的知識也要強制「人人都該懂」？其實不是，我想說的埋點知識，也是配合運營和市場部門的一項重要工做。

說到埋點，不得不說的就是目前比較火的運營分析工具，市場部門在作產品推廣和產品迭代時，離不開市場對產品的反饋，以往作法是經過作不少的調查問卷，讓客戶給予反饋，這些問卷相比如今的分析工具收集的信息有其侷限性，好比問題屬於提早設計，有誤導用戶之嫌，用戶只是枯燥地執行選項選擇，可能心裏真實的想法並無列在選項之中。

這樣的數據每每達不到收集數據的初衷，用戶真實的想法是什麼？產品功能用戶使用狀況到底如何？使用頻率又是怎麼樣？這些是企業市場部和產品經理最關心的問題。

埋點其實就是運營分析工具收集用戶行爲的一種方式，它能夠將用戶在產品上面的點擊和瀏覽狀況，經過數據可視化直觀展示給市場運營及產品人員。

埋點目前有全埋點、可視化埋點和代碼埋點三種主流方式，全埋點和可視化埋點在操做上面並無很明確的區分，主要區別在於圈選的元素範圍上面，這兩種都是無埋碼實現數據採集。全埋點和可視化埋點比較適合給運營和市場人員使用，界面上簡單圈選就能夠生成一個埋點。使用可視化埋點基本上能夠涵蓋大部分的埋點場景。

可是若是有一些屬性須要計算過以後才上報，好比商品數量和商品總價，那麼就須要咱們技術人員經過代碼埋點來配合實施。

代碼埋點顧名思義，就是經過在源碼裏面寫上一個埋點代碼，而後上報用戶點擊的行爲數據。咱們以易觀方舟官網（https://ark.analysys.cn）爲例：

好比我想了解易觀方舟官網首屏上，那個「體驗Deo」按鈕的點擊狀況，進而瞭解其點擊率和按鈕轉化率，那麼咱們就能夠在這個按鈕上面增長埋點。這裏我主要舉例JS端的埋點，其它端埋點思路一致。

易觀方舟官網（https://ark.analysys.cn）

我在作這個埋點時，會根據「業務類型」+「空間位置」+「頁面地址」這三個緯度來命名這個埋點事件。

• 頁面地址：首頁
• 空間位置：首屏
• 業務類型：體驗Demo的點擊狀況

上面就是一個按鈕點擊的埋點部署，是否是很簡單？其實埋點在代碼執行層面並不難，無非就是在合適的位置放上一段代碼，但是如何設計埋點、哪些埋點須要放，哪些埋點應該上報屬性，哪些埋點又可讓運營人員本身經過可視化完成埋點，這就須要咱們對業務有必定的瞭解，這樣可讓代碼埋點更合理而少作無用功。

設計埋點並不徹底是運營和產品人員的事情，技術也能夠設計一套符合業務場景的埋點方案。在作頁面研發時就能夠將埋點作好，頁面上線就能夠統計數據，也並不須要運營同事聯繫你才作，若是按照業務倒追技術來埋點的流程，一來二去，企業已經丟失了1天的用戶行爲數據，這是很是得不償失。

那麼做爲技術人員，該如何設計埋點方案呢？咱們能夠業務場景和代碼實施兩個方面說：

一、業務場景

繼續以易觀方舟官網爲例，方舟官網體驗demo按鈕最多，基本上每一個頁面都有一個，若是按照上面那行代碼來部署的話，一樣的業務場景，咱們埋了很是多的點，後期統計體驗Demo按鈕點擊狀況時，要將全部的體驗Demo按鈕事件並列統計，這很是不合理。

針對這樣的狀況，咱們應該經過屬性區分，事件名都是同一個，經過一個屬性值來區分不一樣的位置。

這樣咱們將同一個業務場景的事件歸爲一個事件，既能夠全面統計也能夠單一統計。

再舉個例子，咱們常常要統計一個表單的輸入狀況，好比註冊表單裏驗證手機號和發送驗證碼這個場景，通常作法會在驗證碼發送成功以後上報一個「驗證碼驗證成功事件」。

若是咱們考慮的再細緻點，好比輸入手機號和點擊發送驗證碼兩步的漏斗狀況如何？輸入手機號和驗證成功漏斗狀況如何？那麼這裏就不僅僅是一個事件就能夠了。

咱們須要將表單細化到每步操做，好比用戶輸入手機號以後，失去光標時，上報輸入手機號事件，屬性值爲手機號。

咱們將一個事件細化以後，就能夠知道哪些用戶輸入了手機號而且收到了驗證碼，哪些用戶沒有收到驗證碼。

這有個好處就是，假設短信供應商出現了問題，沒有及時發送驗證碼，咱們能夠作後期彌補，整理出沒有發送成功的用戶，再次羣發，以防止客戶流失。

從上面兩個例子，咱們能夠看出有些步驟運營人員是不清楚的，好比手機驗證這個過程，這就須要咱們技術工程師來理解場景，補充運營提供的埋點方案。

二、代碼部署

一個優秀的程序員，會將重複使用的功能進行代碼封裝，埋點也同樣，埋點雖然事件名稱不同，可是邏輯大致一致。

好比易觀方舟官網體驗demo按鈕，每次點擊時咱們會判斷用戶是否登陸，登陸的用戶直接跳轉到具體demo頁，沒有登陸的用戶咱們會引導登陸。

易觀方舟官網這麼多體驗emo按鈕，每一個按鈕都去寫一個判斷那不是會瘋掉嗎？因此咱們將這類操做封裝爲一個函數，而後將每一個按鈕上面帶上他的位置說明，這樣只要觸發這個按鈕，就能夠將位置信息做爲參數形式，傳遞給埋點事件。

上面是一個判斷是否登陸接着執行下一步動做的場景。咱們再來想一個場景，假設咱們是一家電商網站，加入購物車、提交訂單、支付訂單這些事件都是有一個共有屬性那就是商品ID和商品名稱，咱們能夠將這類事件統一封裝爲一個函數，集中處理共用屬性，簡化事件上報操做。

代碼埋點主要針對須要上報具體屬性的事件，好比加入購物車，輸入手機號等等，若是隻是爲了統計按鈕點擊量，那麼可讓運營同事直接使用可視化埋點進行圈選。

埋點這個事情確實很簡單，好比易觀方舟的埋點就一行代碼，主要仍是在場景運用中去思考更好的方案。上面咱們拋出了一些埋點的具體思路，主要仍是爲了將埋點這個工做作得更好。

一個好的埋點設計能節省咱們不少時間，少走不少彎路。還要注意一個點就是，變化是恆久不變的規則，咱們的埋點設計也應該擁抱變化，不要爲了一個業務場景去寫一段代碼，應該和運營同窗一塊兒溝通這場景的目的是什麼，從而聯想更多的場景，將埋點儘量地作細緻。不然隔三差五運營過來找你修改埋點時，你會很是頭大。

記錄埋點信息，將咱們作過的埋點事件ID和備註名稱記錄到表格，方便後期排查埋點問題時使用。有時運營同窗也會問某個按鈕的埋點事件是哪一個，這個時候你的表格就派上了用場，很是方便。易觀方舟能夠動態管理埋點信息、支持線上搜索，這個工做咱們程序員卻是省了不少力氣。

文至尾聲，我也來作個總結。埋點是收集用戶行爲完善咱們產品的重要工做，做爲埋點實施者不僅僅是爲了配合運營去執行埋點，應該融入咱們技術角度的思考，將這個事情作得更完美，保證數據準確的同時，也讓埋點代碼作得夠靈活，同時方便咱們後期維護和修改。

（本文做者：易觀方舟官網項目經理 李偉濤）