更新時間：2026年6月11號
如果你的網站使用React、Vue、Angular、Next.js、Nuxt等前端框架開發，很可能就是一個單頁應用（Single Page Application，SPA）。
許多人在安裝GA4後發現：
- 使用者明明瀏覽了多個頁面，但GA4只記錄一次page_view事件
- 網址正確，但頁面標題錯誤
- 流量來源異常
- 頁面瀏覽量比實際數據少很多
這些問題大多與SPA的運作方式有關。
本篇將介紹：
- 什麼是SPA（單頁應用）
- 為什麼SPA容易造成GA4追蹤問題
- 如何判斷網站是不是SPA
- 4 種常見的SPA追蹤方案
- 哪一種方法最推薦
什麼是單頁應用（SPA）
單頁應用（Single Page Application，簡稱 SPA）是一種現代網站架構。
與傳統網站不同，SPA不會在每次切換頁面時重新向伺服器請求整個網頁，而是透過JavaScript動態更新頁面內容。
使用者雖然感覺自己正在瀏覽不同頁面，但實際上：
- 網頁並沒有重新載入
- URL可能發生變化
- DOM內容被動態更新
因此網站操作體驗會更流暢，也更接近桌面應用程式。
常見的SPA技術包括React、Vue、Angular、Next.js、Nuxt、Svelte
為什麼SPA容易造成GA4追蹤問題？
GA4預設是依靠頁面重新載入（Page Load）來觸發page_view事件。
但SPA在頁面切換時不會重新載入，因此容易出現以下問題：
- page_view 沒有被記錄：由於頁面沒有重新整理，GA4預設只會在首次載入時送出page_view。之後使用者切換頁面時，GA4不一定會自動記錄新的頁面瀏覽。
- Page URL或Page Title不正確：許多SPA會使用history.pushState()或 history.replaceState() 來修改網址，如果頁面內容尚未完成更新就送出page_view，可能導致Page URL或Page Title錯位。
- 工作階段與引薦來源問題（Rogue referrer）：如果不正確配置，SPA可能導致工作階段資料斷裂或引薦來源資料錯誤，影響使用者旅程分析。
- 事件重複或遺漏：自動追蹤（如加強型評估）可能導致頁面瀏覽事件重複計數，或在某些情況下未能觸發，因此需要特別注意觸發邏輯。
如何判斷網站是不是SPA？
最簡單的方法就是透過GTM預覽模式檢查。
你可以在GTM 的預覽模式裡從A頁面點擊訪問B頁面，在這個過程裡看Tag Assistant有沒有重新加載頁面，如果重新加載，那麼就不是單頁應用，如果沒有重新加載，出現很多的History，就是單頁應用。
Step 1：建立History Change觸發條件
在GTM中點擊「觸發條件」——「新增」——「請選擇觸發條件類型以開始設定…」——「記錄變更」，然後做如下設定：
Step 2：啟用History相關內建變數
在變數裡，將內建變數的有關記錄的變數都勾選：
Step 3：使用GTM預覽模式測試
GTM 中點擊“預覽”，隨意點擊一個頁面，然後看Tag Assistant:
如果出現大量History、gtm.historyChange-v2，代表網站很可能是SPA。
如果每次切換頁面都重新載入，則屬於傳統網站。
注意：有些網站只有部分頁面採用SPA架構，因此建議多測試幾個頁面。
GA4追蹤SPA的4種方法
目前常見做法共有四種：
- 加強型評估
- History Change
- 延遲發送（History Change + dataLayer）
- dataLayer.push（推薦）
方法一：使用GA4加強型評估
這是最簡單的SPA追蹤方式。
GA4已內建支援瀏覽器History API監聽，只需要勾選“頁面根據瀏覽器記錄事件而變更”，当浏览器历史記錄事件发生变化时，自動送出 page_view。
設定方式：在網頁串流詳情裡面點擊增強型評估下面右側的這個圖標：
點擊「隱藏進階設定」，勾選“根據瀏覽器歷史記錄時間判斷的頁面更改”：
這樣就完成設定了。
驗證：在GTM的預覽模式下的History裡API Call裡能看到gtm.historyChange-v2，就表示被追蹤到了。
優點：設定簡單、不需修改程式碼、適合快速部署
缺點：URL和頁面標題不準確、無法控制發送時機、複雜 SPA 容易產生誤差
適用場景：小型SPA 、網址與內容同步更新、不需要高度客製化追蹤
方法二：使用GTM History Change觸發器
如果加強型評估無法滿足需求，可以改用GTM的History Change觸發器。
History Change觸發器監聽瀏覽器的popstate事件或History API的URL變化，从而觸發GA4的page_view事件。
Step 1：建立History Change觸發條件
在GTM中點擊「觸發條件」—「新增」—「選擇一個觸發條件類型以開始設定」——「記錄變更」，命名為History Change，做如下設定：
然後在GTM裡點擊「預覽」，點擊訪問不同的網頁，可以在Tag Assistant裡看到「記錄」：
Step 2：設定資料層變數
點選「記錄」，然後再API呼叫裡面看裡面的訊息，主要找到oldUrl和newUrl：
oldUrl是上一個頁面，也就是Referral，newUrl是目前頁面，需要用資料層變數來取得它。
在GTM中點擊「變數」—「新增」—「選擇一個變數條件類型以開始設定」——「資料層變數」，命名為dlv-oldUrl，做如下設定：
用同樣的方法設定dlv-newUrl。
Step 3：設定代碼：處理不需要載入的頁面
先要設定一個Google Tag，不需要設定觸發條件，在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「Google Anlaytics」——「Google代碼」，命名為GA4 update：
注意：這個代碼不需要觸發條件。
在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「Google Anlaytics」——「Google Analytics：GA4 事件」，命名為GA4-Page View Event，做如下設定：
GA4 update在GA4-Page View Event之前觸發，主要用於更新配置參數：
Step 4：普通頁面加載該如何跟踪
這裡說的普通頁面加載是正常的頁面加載。
如果普通頁面加載沒有觸發「記錄」，那麼你需要配置一個單獨的Google Tag去跟踪，就正常的GA4頁面跟踪就可以，如：
如果普通頁面加載觸發「記錄」，那麼普通頁面就會合併到GA4-Page View Event去觸發跟踪，但我們仍然需要觸發Google Tag，加載基礎配置，但不發送page_view事件，將send_page_view設置為false即可：
優點：比加強型評估更靈活、允許自訂page_location和page_referrer、不需修改網站程式碼
缺點：Page Title 仍可能不準確、無法保證內容已完全渲染
方法三：延遲發送（History Change + dataLayer.push）
此方法是History Change的進階版，可以解決網頁地址和網頁標題不準確的問題。
原理是：頁面載入/History Change延遲500ms，等待頁面打開，然後才執行js取得當前頁面準確的網頁地址和網頁標題，再透過dataLayer.push發送出去。
Step 1：History Change觸發條件
在GTM中點擊「觸發條件」—「新增」—「選擇一個觸發條件類型以開始設定」——「記錄變更」，命名為History Change，做如下設定：
Step 2：設定延時發送
在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「自訂HTML」，命名為SPA-Delayed Send，然後做如下設定
這個配置的作用是History Change的時候，做了延時，確保新頁面打開，獲取準確的網頁標題，然後透過dataLayer.push將其發送資料。
Step 3：設定資料層變數
在GTM中點擊「變數」—「新增」—「選擇一個變數條件類型以開始設定」——「資料層變數」，命名為dlv—pagePath，做如下設定：
用同樣的方法設定dlv—pageTitle和dlv—pageUrl：
Step 4：設定代碼
先要設定一個Google Tag，不需要設定觸發條件，在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「Google Anlaytics」——「Google代碼」，命名為GA4 update：
注意：這個代碼不需要觸發條件。
在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「Google Anlaytics」——「Google Analytics：GA4 事件」，命名為GA4-Page View Event，做如下設定：
GA4 update在GA4-Page View Event之前觸發，主要用於更新配置參數：
Step 4：普通頁面加載該如何跟踪
這裡說的普通頁面加載是正常的頁面加載。
如果普通頁面加載沒有觸發「記錄」，那麼你需要配置一個單獨的Google Tag去跟踪，就正常的GA4頁面跟踪就可以，如：
如果普通頁面加載觸發「記錄」，那麼普通頁面就會合併到GA4-Page View Event去觸發跟踪，但我們仍然需要觸發Google Tag，加載基礎配置，但不發送page_view事件，將send_page_view設置為false即可：
優點：Page Title 和 Page URL 準確度較高
缺點：延遲過長可能造成資料流失、延遲過短可能仍抓到錯誤資料、不同SPA需要不同等待時間
適用情境：無法修改前端程式碼、又需要較準確頁面資訊的情況。
方法四：使用dataLayer.push（最推薦）
這是目前業界最穩定、最準確的 SPA 追蹤方式。
由前端工程師在路由切換完成後主動發送資料，GTM再根據這些事件觸發GA4標籤。
Step 1：前端推送資料
頁面發送的資料結構如下，每個頁面都需要這樣發送，這一步是需要開發人員去實作：
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'Pageview',
'pageUrl': 'https://www.example.com/something/contact-us',
'pagePath': '/something/contact-us',
'pageTitle': 'Contact us'
});
</script>
Step 2：設定資料層變數
在GTM中點擊「變數」—「新增」—「選擇一個變數條件類型以開始設定」——「資料層變數」，命名為dlv—pagePath，做如下設定：
用同樣的方法設定dlv—pageTitle和dlv-pageUrl。
Step 3：設定觸發條件
在GTM中點擊「觸發條件」—「新增」—「選擇一個觸發條件類型以開始設定」——「自訂事件」，命名為Custom Event—Pageview，做如下設定：
Step 4：設定代碼
在GTM中點選「代碼」—「新增」—「選擇一個代碼類型以開始設定」——「Google Anlaytics」——「Google代碼」，命名為GA4 Basic Tracking，做如下設定：
優點：資料最準確、可完全客製化、不受History API限制、可搭配任何SPA框架
缺點：需要工程師配合、開發成本較高
適用場景：所有SPA均適用，推薦使用此方法去追蹤SPA。
SPA追蹤方式比較
| 方法 | 設定難度 | 資料準確度 | 是否需工程師協助 | 推薦程度 |
|---|---|---|---|---|
| 加強型評估 | ★ | ★★ | ❌ | ★★★ |
| History Change | ★★ | ★★★ | ❌ | ★★★★ |
| 延遲發送 | ★★★ | ★★★★ | ❌ | ★★★ |
| dataLayer.push | ★★★★ | ★★★★★ | ✅ | ★★★★★ |
總結
SPA網站最大的挑戰在於頁面切換時不會重新載入，因此GA4預設的page_view機制經常無法正確運作。
選擇追蹤方式時，可以依照網站規模與技術資源評估：
- 簡單SPA：使用GA4加強型評估即可。
- 需要較高準確度：使用GTM History Change。
- 需要正確的Page Title 與 Page URL：可考慮延遲發送方案。
- 正式專案或大型網站：建議由工程師透過dataLayer.push，這也是目前最推薦的SPA追蹤方案。
只要正確完成SPA頁面瀏覽追蹤，GA4才能完整記錄使用者旅程、頁面流向與轉換路徑，避免分析結果失真。