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

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

• SPA與pageview-based網頁追蹤工具
• 記錄變更與虛擬頁面
• 伸縮自如的網頁瀏覽量

關於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在操作過程中，網頁是不會刷新的，自然不會觸發『網頁瀏覽』，所以不管使用者做了多少操作，你都只會記錄到一個頁面。

記錄變更與虛擬頁面

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

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

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

伸縮自如的網頁瀏覽量

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

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

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

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

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

寫在文末:

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