數據埋點:前端頁面PV/UV的觸發和交互
編輯導語:數據埋點是數據產品經理、數據運營以及數據分析師,基于業務需求、產品需求等對用戶行為的每一個事件對應的位置進行開發埋點,記錄數據匯總后進行分析,推動產品優化或指導運營。今天,本文作者和大家聊一聊這次數據的誕生:前端埋點。
數據埋點是數據分析的基礎,依據埋點數據中我們可以開展數據清洗、數據歸因、分析模型、AB測試等工作。
如今數據分析可以說是當前最熱門的技能了,不管是產品、運營還是設計都可以明顯感知到各大平臺、公眾號都在使勁的推送。各種9.9秒殺課程、1元限時體驗。
這說明了數據分析確實是一個大家都需要掌握的趨勢,但是我們不能忽視數據的生命周期(數據的誕生和沉寂),這次聊下數據的誕生:前端埋點。
一、什么是埋點?
埋點我們可以理解成一個收費站,用戶的行為就像開著車在高速路上跑。在沒有做埋點的時候,我們只能知道有人在高速路上跑,但是用戶跑的那條高速路,經過了哪些地方,在高速路上遇見了什么問題我們都不知道。
而做了埋點之后,就像我們在高速路上修建收費站。用戶只要途徑收費站,那么我們都會知曉,這就是埋點。而埋點數據則是用戶在經過收費站時,我們要想知道的關于用戶的信息。
除此之外我們也常說埋點我們要分代碼埋點、可視化埋點和全量埋點,那么他們有什么區別?
1. 代碼埋點
我們請了一個施工隊,這個施工隊聽你的指揮,并根據你在高速路上指定的位置建造收費站,這種都是一磚一瓦的施工:
- 優點:可控性高,滿足所有的需求;
- 缺點:研發成本、設計成本高。
2. 可視化埋點
我們將需要建造的收費站進行模具化,只需要到指定位置放置模具,對模具直接澆灌水泥,收費站就直接成型。
- 優點:操作方面,布置快捷;
- 缺點:適應性差,緯度匹配度因“路”而異。
3. 全量埋點
直接組裝衛星發射到天上,實時監控高速路上的用戶行為。
- 優點:用戶的一舉一動我們都知曉;
- 缺點:數據傳輸量大,數據需要二次清洗,占用大量實時資源進行數據傳輸。
二、埋點類型
埋點我喜歡分為前端埋點和后端埋點。前端埋點指的是可視化頁面上的埋點,只要是有可視化操作頁面我們都可以看作是可以進行前端埋點。
后端埋點,指的是在用戶看不見也摸不到的后端服務里進行埋點,比如訂單的生成、額的計算、條件的觸發等。
在前端埋點中,我們主要關注用戶行為。用戶在頁面上瀏覽了什么、點擊了什么。這樣我們可以很好的了解頁面內容對于用戶感官的影響。
而后端埋點更加看重業務和邏輯,在用戶發起行為交互后,對交互數據進行記錄。例如:搜索的內容是什么,搜索到的結果怎么樣等,由此得到數據后,我們可以更好優化“策略”。
三、前端埋點:自動觸發式
1. PV
前端埋點我們常用的就是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生命周期。
2. UV
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頁面?,F有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協議。
求更新