編輯導語：數據埋點是數據產品經理、數據運營以及數據分析師，基於業務需求、產品需求等對用户行為的每一個事件對應的位置進行開發埋點，記錄數據彙總後進行分析，推動產品優化或指導運營。今天，本文作者和大家聊一聊這次數據的誕生：前端埋點。
數據埋點是數據分析的基礎，依據埋點數據中我們可以開展數據清洗、數據歸因、分析模型、AB測試等工作。
如今數據分析可以説是當前最熱門的技能了，不管是產品、運營還是設計都可以明顯感知到各大平台、公眾號都在使勁的推送。各種9.9秒殺課程、1元限時體驗。
這説明了數據分析確實是一個大家都需要掌握的趨勢，但是我們不能忽視數據的生命週期（數據的誕生和沉寂），這次聊下數據的誕生：前端埋點。
一、什麼是埋點？埋點我們可以理解成一個收費站，用户的行為就像開着車在高速路上跑。在沒有做埋點的時候，我們只能知道有人在高速路上跑，但是用户跑的那條高速路，經過了哪些地方，在高速路上遇見了什麼問題我們都不知道。
而做了埋點之後，就像我們在高速路上修建收費站。用户只要途徑收費站，那麼我們都會知曉，這就是埋點。而埋點數據則是用户在經過收費站時，我們要想知道的關於用户的信息。
除此之外我們也常説埋點我們要分代碼埋點、可視化埋點和全量埋點，那麼他們有什麼區別？
1. 代碼埋點我們請了一個施工隊，這個施工隊聽你的指揮，並根據你在高速路上指定的位置建造收費站，這種都是一磚一瓦的施工：
- 優點：可控性高，滿足所有的需求；
- 缺點：研發成本、設計成本高。
我們將需要建造的收費站進行模具化，只需要到指定位置放置模具，對模具直接澆灌水泥，收費站就直接成型。
- 優點：操作方面，佈置快捷；
- 缺點：適應性差，緯度匹配度因“路”而異。
直接組裝衞星發射到天上，實時監控高速路上的用户行為。
- 優點：用户的一舉一動我們都知曉；
- 缺點：數據傳輸量大，數據需要二次清洗，佔用大量實時資源進行數據傳輸。
埋點我喜歡分為前端埋點和後端埋點。前端埋點指的是可視化頁面上的埋點，只要是有可視化操作頁面我們都可以看作是可以進行前端埋點。
後端埋點，指的是在用户看不見也摸不到的後端服務裏進行埋點，比如訂單的生成、額的計算、條件的觸發等。
在前端埋點中，我們主要關注用户行為。用户在頁面上瀏覽了什麼、點擊了什麼。這樣我們可以很好的瞭解頁面內容對於用户感官的影響。
而後端埋點更加看重業務和邏輯，在用户發起行為交互後，對交互數據進行記錄。例如：搜索的內容是什麼,搜索到的結果怎麼樣等，由此得到數據後，我們可以更好優化“策略”。
前端埋點我們常用的就是PV/UV（Page View / User View；頁面瀏覽量 / 用户瀏覽量）。他們兩個區別在於，PV（頁面瀏覽量）關注的是頁面被瀏覽的次數，打開一次計算一次。
UV（用户瀏覽量）關注的是瀏覽用户的數量，記錄打開瀏覽的用户數量。瞭解上面PV/UV的最基本認知之後，我們來討論如何做好PV/UV的記錄？
我們常識中PV/UV就只是給技術提埋點數據需求（文檔、口頭）就完了，其實我們在提PV埋點的時候有很多細節。
一般頁面會存在生命週期，這種生命週期常見有4個階段，以VUE（國內用的比較多的前端研發框架）為例分別是：創建、加載、更新、銷燬，這4個階段分別代表着用户在點擊打開瀏覽網頁到點擊關閉退出網頁。
正常情況下用户進入頁面，先渲染一些簡單的樣式（html和css），隨後便進行數據的加載更新，最後用户點擊關閉退出頁面，如果我們再細分可以分為創建前、創建後、載入前、載入後、更新前、更新後、銷燬前、銷燬後。
在我們進行PV/UV埋點的時候，就算相同的一個緯度（PV/UV）選擇不同的階段進行埋點，得到的結果也會不一樣。正常情況下，技術喜歡把埋點做在加載，更新這2個階段。這樣需要用户基本完整的看見也看才進行埋點數據的存儲（才會觸發埋點）。
但是在特殊情況下，有些用户網絡情況不佳，半天都加載不出頁面，遇見我們常説的白屏，這樣PV的觸發將會有不可控性。
因為我們很難知道因為網絡的問題，他到底觸沒觸發我們的埋點。所以在這樣的情況下，我們可以將PV的觸發放在“創建”這個位置，當頁面創建成功機會進行埋點數據的觸發。
下面是pv埋在不同階段會有不同的特點，但是常態下我們都還是選擇放在更新這個階段：這只是依據頁面的生命週期的鈎子（頁面運行時，前端代碼加載的先後順序）進行説明。可能存在誤差，有需要的可以自行去百度vue生命週期。
UV和PV埋點的方式相同，唯一不同的地方就是UV需要在PV的基礎上通過唯一標示進行篩選。統計有多少個唯一標示而得UV的數量，一般我們常見的唯一標示如下：
- 手機號：用户登錄頁面後依據他綁定的手機號來進行統計，但是如果用户未登錄將無法統計；
- cookie：通過用户瀏覽器上的cookie作為唯一標示，但因為cookie是存在用户瀏覽器中容易被修改；
- localStorage：通過在瀏覽器在本地存儲一個長期唯一標示，但是可以手動清理；
- IP:通過訪問頁面ip地址進行區分，如果ip變更將另行計算；
- seesionStorae：通過存在服務器的信息進行表示，有實效性。
這5個就是我們常用作為UV唯一標示的，他們推薦使用的優先級手機>ip>local>cookie>seesion。
推薦使用手機號是因為，當我們擁有自己的賬户體系的時候，使用手機號作為標示這樣可以更好的和我們自身數據進行關聯。但這樣面臨的問題將是需要用户進行登錄，在一些宣傳h5頁面上，使用登錄將顯得格外繁瑣，因此衍生出使用ip作為唯一標示。
ip我們大家都知道，會跟着你的網絡變化而變化，那麼按道理也是不準的，為什麼反而在local前面了（local：網站在瀏覽器本地存的一個信息，具有唯一性，能手動清理，清理後生成的將不再是原來的）？
因為local雖好，但因為大部分手機瀏覽器不支持，或者是部分支持這樣數據採集又會不全，所以退而求次使用ip。
四、擴展在大多數情況下，大部分公司都沒健全的數據埋點體系，有個pv和uv就不錯了。面對這樣情況我們就去深挖他們的價值，通過對他們的簡單應用，實現對我們大膽猜測的依據。
1. 轉化率通過代碼埋點或是全量埋點，將關鍵業務涉及頁面進行埋點覆蓋，使用下個頁面pv/uv量除上個頁面pv/uv量我們就可以得出頁面之間的轉化率。
比如：有ab兩個頁面，點擊a頁面才會進入b頁面。現有100個pv/uv被a頁面進行統計，當在b頁面時統計時候，出現了120個pv/uv，將這120個pv/uv與a頁面的進行對比，出現有90個pv/uv相互重複（交集），最後用b頁面相互重複的90個pv/uv除以a頁面這100pv/uv，得出他們之間的轉化率為90%（90/100=0.9）。
2. 停留時間如果只是pv/uv其實應用面會很少，那麼我們就需要在頁面的四個階段中做其他的類似pv/uv的埋點，只不過是用户記錄時間。
當頁面創建（用户訪問網站或頁面）時，我們可以將出發pv/uv的時間進行存儲。而當用户正常離開頁面時，我們再次記錄時間，後者減去前者我們就得到了停留時間。
但是需要我們注意的是，用户很少按照我們設計的流程執行。在app中會出現用户直接退出整個應用，這樣會讓數據存在差異。也有用户使用app將頁面常掛手機後台，這樣數據也會出現差異。
同時在小程序（微信小程序）上使用停留時間的埋點，會因為微信小程序的特性無法關閉，後台執行出現差異。所以我們要警惕那些差異性很大的數據，將他們剔除，放置在其他數據中將是一個好方法。
五、前端埋點：互動式除了依據用户瀏覽行為進行自動式觸發的埋點（不絕對）pv/uv外，我們還有一種埋點方式需要用户參與互動。
常見的是用户進行按鈕的點擊和頁面的滑動。我們通過對按鈕計數（pv）和去重（uv），這樣我們可以瞭解這個功能按鈕的使用情況，這樣也就能夠支撐我們進行一些小功能簡單的ab測試。
又或者我們與用户的滑動行為結合起來埋點。技術可以通過監聽用户滑動位置，來決定是否觸發埋點，這也是我們常説的曝光埋點。
曝光埋點：這種埋點一般常用户商品、內容的推薦上。當我們設置推薦的商品或內容在首屏上時，同時用户首次進入頁面，那我們可以根據自身業務選擇使用pv或uv做作他們的曝光量，但是這僅限固定商品和內容。
這樣對於多個商品進行輪播曝光時，會因為商品的輪播機制難以確認單個商品的曝光量，所以一般我們在對於多個商品進行輪播曝光時，暫時都只統計這個輪播模塊的曝光量。
而對於模塊中的商品我們常用曝光轉化率來看。計算方式有點像輪播圖的計算方式，單個商品點擊量（按鈕pv/uv）/整體模塊曝光量（pv/uv）= 單個商品的轉化率。
這種使用頁面的pv/uv來作為計算模塊和商品曝光量的方式，僅限在首屏上固定曝光的模塊。如果計算曝光量的模塊或商品不在首屏上，那麼我們使用這樣但方式是不科學、不可取的。
我們就需要結合用户的滑動屏幕來觸發曝光埋點，當用户滑動到什麼位置，就可以看見這個模塊時，我們才在看見模塊的同時觸發埋點。
這個時候，我們可以考慮是使用觸發次數（pv）還是觸發人次（uv）來進行計算。
六、前端埋點：自動觸發式+互動式埋點的觸發和互動，數據的次數和人次（pv/uv）基本上算前端埋點的兩個核心，將他們兩個結合起來，我們可以擴展很多的分析維度，比如我們常用的購買路徑分析、跳出率等。
這裏我只是簡單的講了我們單純埋個點，每次觸發只是記錄用户信息和次數。其實我們還可以記錄商品信息，這樣我們可以觀察什麼商品更受喜歡。記錄金額，可以瞭解什麼價位更符合用户預期等。
文章到這裏就暫時結束，後面有機會我在和大家談一談後端埋點。
作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）
本文由 @Wcof 原創發佈於人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協議。