Site Overlay

那些用GA追蹤SPA網站數據踩過的坑



根據維基百科,SPA(single page application)網站的概念早在2003年就出現了,不過在台灣有比較廣泛討論大概也只是最近幾年的事,但討論內容大多集中於開發者社群中;比較可惜的是少看到產品規劃、營運面相的相關心得。團隊一開始從規劃SPA網站到開發、上線進入日常維運,踩過無數坑,這篇文章從數據追蹤的角度分享一些粗淺的心得,希望未來能幫到一些人。

關於SPA網站是甚麼、技術架構上跟過去的網頁比起來有了哪些突破,這邊就不贅述了,若還不是很熟悉,非常推薦Huli寫的文章,深入淺出解釋了一系列專有名詞,有種在讀前端近代史的感覺。quote一下文章內的總結:”SPA 就是因為想增進使用者體驗,而出現的一種在前端利用 Ajax 達成不換頁的方法”,大家常用的Gmail、Google Map或Spotify (web)都屬於SPA的應用,大概也回不去了(想像每縮放一次地圖整個網頁要重新載一次的感覺)。

我自己管理的產品是屬於to C端的工具型搜尋網站(可以想像成Airbnb那類訂房網站),也是以SPA架構開發,不過以下要討論的事項與網站本身內容沒有太大相關,而是因為SPA本身特性,在數據觀測上容易疏忽的幾件小事(踩坑的時候不會覺得是小事)。


SPA與pageview-based網頁追蹤工具

一般在維運網站產品,要追蹤產品數據大家最常使用的第三方工具應該就是Google Analytics (GA)了吧。GA有個特性,就是裡面的互動追蹤大多是基於頁面瀏覽(pageview, PV)做計算,例如跳出率、離開率,或一般泛稱的『網站流量』。這個特性對於多頁式(muti-page apps, MPA)網站非常方便,要拉流程的漏斗(funnel)、設定轉換目標、觀察不同頁面瀏覽數、跳出狀況都很直觀,只要從網址變化去觀察就好。

但同樣的情形用到SPA網站就會變得比較麻煩;首先一般在埋設GA的起手式,會先在Google Tag Manager(GTM)裡面創建一個由『網頁瀏覽』觸發的代碼,送資料到GA裡,這樣一來使用者不管瀏覽到哪個頁面,都會送PV到GA,就可以計算瀏覽量、停留時間、跳出率、離開率…。但是,SPA在操作過程中,網頁是不會刷新的,自然不會觸發『網頁瀏覽』,所以不管使用者做了多少操作,你都只會記錄到一個頁面。

寂寞的SPA
寂寞的SPA

記錄變更與虛擬頁面

當然這個問題是有方法在GTM解決的,大概可以分成兩種方法;第一種是增加會觸發「網頁瀏覽」的條件:雖然SPA不會重刷頁面,但網址列是會變化的(除非你用POST method傳送資料,這是另一個曾經踩過的坑),只要追蹤網址列變化(GTM裡的觸發條件為「History記錄變更」),發生改變即送出PV就可以解決。

增加觸發條件「紀錄變更」
增加記錄變更觸發條件

但如果今天經營的是內容搜尋網站,使用者搜尋後網址列會帶一堆參數,通通送到報表裡反而難閱讀,這時候就可以使用另一種方法:虛擬頁面(或是你用POST送資料,導致不管網站內容是甚麼網址都一樣的時候)。

虛擬頁面的使用方法,一樣是在GTM新增一個「網頁瀏覽」的代碼,在使用者「輸入完搜尋條件按下送出」時觸發,另外因為我們不想要那些拉拉雜雜的參數,所以另外自己定義這時送出的網頁瀏覽有獨立的URL和title,在網頁內容的報表中,只要page為/vpv/search就表示使用者正在瀏覽查詢結果列表頁,同時也避免帶了一堆參數到GA,最後要看報表還是得全部篩選掉的窘境。

送出虛擬頁面
送出虛擬頁面

使用了這兩種方法,基本上就可以在GA上正常觀測本來記錄不到任何頁面的SPA網站,但同時也會引發另一個問題:GA上的網頁瀏覽數因為我們的一些操作膨脹了。


伸縮自如的網頁瀏覽量

一開始接觸GA時就被前輩提醒不要太在意報表上的PV和跳出率,實際上自己在管理數據的時候,才發現真的很容易操作。上面因應SPA特性額外發送PV的做法,在網站本身流量不變的狀況下,就會讓GA報表上的瀏覽量直接翻倍(調整完虛擬頁面的發送隔天發現流量數據暴漲,還以為我們產品被甚麼網紅推薦)。

伸縮自如的網頁瀏覽量
不靠流量獲取就能產生倍數成長的PV(X)

但並不是說這樣就一定是錯的或是在作弊,因為本來SPA網站在PV-based追蹤工具上先天就比較吃虧,所以才需要靠模擬MPA網站的操作,在合理的情境發送PV。但如何定義合理的發送情境?點開lightbox看操作教學要不要算PV?新增篩選條件要不要算?變更搜尋結果排序呢?

我想這會回到觀測網站數據的目的,是為了讓團隊知道在產品上發生了甚麼、用戶做了甚麼事、我們怎麼優化、從哪一段下手,我覺得要秉持幾個原則:

  1. 對自己誠實,不要拿操作過的數字來跟不同基準的其他產品比較。只跟自己比,或是就乾脆不參考那些數字
  2. 專注在產品本身的商務邏輯上,只關注最重要的指標,追蹤工具上的操作只是為了幫助我們更好觀測數據
  3. 額外發送的觸發條件要盡可能直覺,否則就要靠文件來維護

不過我覺得用文件管理可能在短期有用,長期來說還是會有不少問題,畢竟文件是人在寫的,太瑣碎的更動難免會漏東漏西,「誰埋了這個代碼」、「埋的邏輯是甚麼」、「為什麼數字對不起來」這些問題到時候就會不時出現,就像有人會說與其看古老的工程文件,不如直接翻原始碼(不過目前尚沒有想到甚麼好的解法就是了)。


寫在文末:

  1. 有些公司在第三方網頁追蹤服務可能會選擇AmplitudeMixpanel,我自己只用過後者,與GA相反,是以事件為基礎(event-based),對SPA網站數據觀測會友善很多,但相對採用服務的成本也高不少,先不在本篇文章討論範圍。
  2. 一不小心寫得有點太技術,但實際上又沒有提供甚麼操作教學,如果有人想知道詳細一點的操作請讓我知道,我會找時間寫的。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。