GTM 捲動深度追蹤設定：GA4 事件驗證與排錯流程

GTM 捲動深度追蹤是什麼？

GTM（Google Tag Manager）捲動深度追蹤，是用 GTM 在使用者閱讀頁面時，把 25%、50%、75%、90% 等捲動深度送進 GA4，讓內容與行銷團隊能檢查頁面是否真的被讀到。

一句話定義

GTM 捲動深度追蹤的核心，是在 Google Tag Manager 裡建立 Scroll Depth 觸發條件，當使用者捲到指定比例時，就送出一筆 GA4 事件。這類事件不適合拿來直接判斷成交，但很適合用來看內容互動、閱讀完成率與頁面段落表現。

例如一篇報告頁放在 /reports 底下，使用者進站後只看到首屏就離開，和讀到 75% 才離開，對內容品質的意義完全不同。只看瀏覽量會把這兩種行為混在一起，捲動深度可以把差異拆開。

它和 GA4 內建 scroll 事件差在哪

GA4 的增強型評估可以自動記錄 scroll 事件，但它通常只在使用者接近頁面底部時記錄一次，較適合看「有沒有讀到底」，不適合看「中途在哪裡流失」。GTM 多段捲動深度追蹤則可以把 25%、50%、75%、90% 分段送出。

比較項目	GA4 內建 scroll	GTM 多段捲動追蹤
追蹤重點	接近頁面底部	不同閱讀比例
常見比例	約 90%	25%、50%、75%、90%
資料用途	判斷是否讀到底	判斷段落流失與內容吸引力
命名彈性	使用內建事件名稱	可自訂 scroll_depth 與事件參數

適合哪些頁面

GTM 捲動深度追蹤適合內容頁、報告頁、教學頁、長篇 landing page、資源頁與需要評估閱讀品質的頁面。我的判斷是，凡是頁面目的不是單純曝光，而是希望使用者理解內容、比較資訊或往下一步行動，就值得追蹤捲動深度。

短頁面不一定要追蹤太多比例。頁面本身很短時，25% 和 50% 可能幾乎同時觸發，資料反而不夠乾淨。追蹤的重點不是把事件裝滿，而是讓 GA4 裡的資料能回答清楚問題。

設定前先規劃捲動事件表

設定 GTM 前應先規劃事件表，決定追蹤哪些頁面、哪些捲動比例、事件名稱與參數，避免 GTM 已經發布，GA4 卻收到一堆難以分析的事件資料。

建議追蹤比例

一般內容頁建議先用 25%、50%、75%、90%。25% 可看首屏與開頭是否留得住人，50% 可看主要內容是否被讀到，75% 可看深度閱讀，90% 則接近閱讀完成。這四段已經能回答多數內容分析問題。

如果頁面很長，可以再評估是否加入 10% 或 100%。但站在資料維護角度，比例越多不一定越好。比例太細會讓事件數變多，報表判讀變慢，也容易讓團隊把注意力放在細節噪音上。

事件名稱

建議多段捲動深度事件使用 scroll_depth，不要直接沿用 scroll。如果 GA4 增強型評估已經開啟，內建 scroll 可能已經存在，再用同名事件容易讓報表混在一起。

scroll_depth 的好處是語意清楚，看到事件名稱就知道它是自訂的多段捲動追蹤。之後如果要在 GA4 事件設定 裡整理命名規則，也比較不會和內建事件衝突。

事件參數

事件參數要能回答「誰在什麼頁面捲到哪裡」。最低限度建議送出 percent_scrolled、page_location、page_title。如果網站有內容分類，也可以加入 content_group，方便在 GA4 探索報表裡比較不同主題。

參數名稱	建議值	用途
percent_scrolled	25、50、75、90	分析使用者讀到頁面哪個比例
scroll_direction	vertical	標示為垂直捲動
page_title	Page Title	辨識內容標題
page_location	Page URL	辨識實際頁面網址
content_group	reports 或文章分類	比較不同內容群組的閱讀深度

範例表格

事件規劃表可以先用試算表整理，不需要一開始就進 GTM。這張表的價值是讓行銷、資料分析與網站管理者對齊同一套事件設計。

追蹤頁面	比例	事件名稱	參數	送出平台	驗證人	備註
/reports/	25、50、75、90	scroll_depth	percent_scrolled、page_location	GA4	網站管理者	只追蹤報告頁
長篇教學頁	25、50、75、90	scroll_depth	page_title、content_group	GA4	資料分析者	用於探索報表

在 GTM 建立 Scroll Depth 觸發條件

在 GTM 建立 Scroll Depth 觸發條件時，重點是選擇 Vertical Scroll Depths、填入要追蹤的百分比，並限制要套用的頁面範圍，讓捲動深度資料保持乾淨。

建立新 Trigger

1. 進入 Google Tag Manager 容器。
2. 點選 Triggers。
3. 新增一個 Trigger。
4. 命名為 Scroll Depth - Reports - 25 50 75 90。
5. 選擇 Scroll Depth 作為觸發條件類型。

命名時不要只寫「Scroll」。日後容器裡通常會有點擊、表單、頁面瀏覽等事件，名稱太短會讓協作者很難判斷這個 Trigger 的用途。

選 Vertical Scroll Depths

內容頁通常追蹤垂直閱讀行為，所以應勾選 Vertical Scroll Depths。Horizontal Scroll Depths 多半不適用於一般文章或報告頁，除非網站有特殊橫向捲動版型。

這裡的判斷很務實：如果你的頁面是一般上下閱讀，追蹤水平捲動只會增加資料噪音，不會讓 GA4 報表更有用。

設定百分比

在 Percentages 欄位填入 25,50,75,90。GTM 會在使用者捲到這些捲動深度時觸發事件。比例之間用逗號分隔，不需要加百分比符號。

設定完成後，可以先不要急著發布。接下來還要建立 GA4 Event Tag，讓 Trigger 觸發時真的把事件送到 GA4。

All Pages 或 Some Pages

如果只想追蹤特定文章、報告頁或 /reports/ 底下的內容，建議使用 Some Pages。條件可以設定 Page Path contains /reports/，避免全站每個頁面都產生捲動事件。

全站追蹤不是錯，但要有理由。對於首頁、短表單頁、登入頁這類頁面，捲動深度不一定能代表內容品質。把事件限制在需要分析的頁面，通常比一次套全站更可靠。

建立 GA4 Event Tag 並送出捲動深度

GA4 Event Tag 負責把 GTM 的捲動觸發結果送進 GA4；建議使用自訂事件名稱 scroll_depth，並加入 percent_scrolled 等事件參數，避免和內建 scroll 混淆。

選 GA4 Event

在 GTM 的 Tags 裡新增標籤，標籤類型選 GA4 Event。這個標籤會在 Scroll Depth Trigger 觸發後，把事件資料送到 GA4。標籤名稱可以寫成 GA4 Event - scroll_depth - Reports。

標籤名稱要能同時看出平台、事件名稱與頁面範圍。這不是潔癖，是多人維護時很實際的保險。

設定 Measurement ID 或 Configuration Tag

如果容器裡已經有 GA4 Configuration Tag，可以直接沿用。若使用新版 GA4 設定方式，則填入對應的 Measurement ID。重點是確認這個 ID 對應到正確的 GA4 資源。

常見錯誤是測試站和正式站用到不同 GA4 資源，Preview 看起來有 fired，但 DebugView 卻在另一個資源裡。遇到這種狀況，先檢查 Measurement ID，通常比反覆重設 Trigger 更快。

填 event_name

Event Name 建議填 scroll_depth。如果 GA4 的增強型評估已開啟，不建議把多段追蹤也命名為 scroll，否則內建 scroll 與自訂捲動深度會混在同一個事件名稱下。

事件名稱穩定後，不要為了不同頁面再改成 report_scroll、blog_scroll、article_scroll。頁面差異應該交給參數處理，事件名稱維持一致，GA4 分析會更乾淨。

加入事件參數

在 Event Parameters 加入 percent_scrolled，值可使用 GTM 內建變數 Scroll Depth Threshold。再加入 scroll_direction、page_title、page_location，讓 GA4 可以用頁面和比例交叉分析。

Parameter Name	Value	說明
percent_scrolled	{{Scroll Depth Threshold}}	送出 25、50、75、90 等比例
scroll_direction	vertical	標示垂直捲動
page_title	{{Page Title}}	帶入頁面標題
page_location	{{Page URL}}	帶入完整網址

用 Preview、Tag Assistant、GA4 DebugView 驗證

驗證 GTM 捲動深度追蹤要分三段：先用 GTM Preview 看 Trigger 是否觸發，再用 Tag Assistant 看 GA4 Event Tag 是否 fired，最後用 GA4 DebugView 確認事件是否被 GA4 收到。

GTM Preview 看 Trigger

先點 GTM 的 Preview，輸入要測試的頁面網址，開啟預覽模式後在頁面上慢慢往下捲。當捲到 25%、50%、75%、90% 時，左側事件流程應該出現 Scroll Depth 相關事件。

這一步只確認「觸發條件有沒有成立」。如果 Trigger 沒有出現，問題多半在頁面範圍、百分比設定、容器安裝或測試頁太短。

Tag Assistant 看 Tag fired

Trigger 出現後，接著看 GA4 Event Tag 是否 fired。Tag Assistant 裡應能看到 GA4 Event - scroll_depth - Reports 在對應的 Scroll Depth 事件下觸發。

如果 Trigger 有觸發，但 Tag 沒 fired，就檢查 Tag 的 Trigger 是否綁錯、例外條件是否擋住、或標籤設定是否有缺。這一步不要跳過，因為 Trigger 成功不代表 GA4 一定收到資料。

GA4 DebugView 看事件

最後進 GA4 的 DebugView，確認是否看到 scroll_depth 事件，以及 percent_scrolled 是否帶出 25、50、75、90。DebugView 能證明資料已經進到 GA4，這才算完成驗證。

如果 DebugView 沒看到，檢查 Measurement ID、GA4 資源、瀏覽器阻擋、同意模式設定與網路請求。我的經驗是，多數問題不是 Scroll Depth 本身，而是 GA4 標籤送到錯的資源或根本沒有發布。

驗證順序

順序	工具	要確認的事	代表意義
1	GTM Preview	Scroll Depth Trigger 是否出現	觸發條件成立
2	Tag Assistant	GA4 Event Tag 是否 fired	標籤有送出事件
3	GA4 DebugView	GA4 是否收到 scroll_depth	資料進入 GA4

發布版本與命名規範

GTM Preview 成功後還要 Submit 與 Publish，正式網站才會套用設定；版本名稱、發布說明與回復方式要寫清楚，避免日後排查時不知道哪次改動影響了 GA4 資料。

版本名稱怎麼寫

版本名稱建議包含年份、追蹤項目、平台與頁面範圍，例如 2026-gtm-scroll-depth-ga4-reports。這個名稱一眼能看出是 2026 年針對 reports 頁面的 GA4 捲動深度追蹤。

發布說明可以補上比例與事件名稱，例如「新增 /reports/ 頁面 scroll_depth 事件，追蹤 25、50、75、90」。日後 GA4 資料突然變化時，這些紀錄會比記憶可靠。

發布前檢查清單

• Scroll Depth Trigger 已限制正確頁面範圍。
• GA4 Event Tag 使用正確 Measurement ID 或 Configuration Tag。
• Event Name 使用 scroll_depth。
• percent_scrolled 已帶入 Scroll Depth Threshold。
• Preview、Tag Assistant、DebugView 都已驗證。
• 確認沒有和 GA4 內建 scroll 事件混用同名設定。

最容易漏的是 Preview 成功後忘記發布。測試環境成功不等於正式站生效，沒有 Submit / Publish，使用者在正式網站上的捲動不會送進 GA4。

錯了怎麼回復

如果發布後發現事件名稱錯誤、比例設太多或資料送到錯的 GA4 資源，可以在 GTM Versions 裡回復到上一個穩定版本。回復後再重新建立修正版，不要在不確定問題來源時連續改多個設定。

版本回復的價值，是讓正式站先回到可預期狀態。追蹤設定出錯時，最怕一邊修 Trigger、一邊改 Tag、一邊換 GA4 參數，最後無法判斷是哪個改動造成結果。

GA4 裡怎麼看捲動深度資料

GA4 裡可以先用 Realtime 或 DebugView 確認事件，再用 Explore 探索報表把頁面路徑與 percent_scrolled 交叉分析，判斷不同內容的閱讀落差。

Realtime / DebugView

剛完成設定時，先看 Realtime 或 DebugView。這兩個位置適合確認事件是否進入 GA4，但不適合做長期內容判斷，因為它們偏向即時檢查。

DebugView 主要用於測試。正式分析應等資料累積後，再進探索報表或標準報表查看趨勢。不要看到 DebugView 有一兩筆事件，就急著判斷文章表現。

Explore 探索報表

在 GA4 Explore 可以建立自由格式報表，列出事件名稱、頁面路徑、percent_scrolled 與事件數。若 percent_scrolled 要成為可用維度，需依 GA4 的自訂定義設定方式註冊事件參數。

建議維度使用 Page path、Event name、percent_scrolled，指標使用 Event count。這樣可以看到每個頁面在 25%、50%、75%、90% 各有多少事件，分析會比只看總事件數清楚。

用頁面與百分比交叉分析

判讀捲動深度時，不要只看最高比例。若 25% 很高、50% 掉很快，可能是首屏承諾與正文內容不一致，或開頭太慢進入重點。若 75% 很高但轉換低，可能代表內容有人讀，卻缺少清楚的下一步。

對內容頁來說，捲動深度是診斷訊號，不是最後答案。它應該和查詢意圖、段落架構、CTA、站內連結一起看。需要進一步整理 GA4 報表時，可接著檢查 GA4 報表使用方式 與 GA4 資料排查。

GTM 沒有捲動資料怎麼排查？

GTM 沒有捲動資料時，應依序檢查容器是否安裝、Trigger 是否觸發、Tag 是否 fired、版本是否發布、GA4 是否收到，不要一開始就重做整組設定。

容器是否安裝

先確認網站頁面上有正確安裝 GTM 容器程式碼，且容器 ID 和目前編輯的 GTM 容器一致。若容器沒有安裝，後面所有 Trigger 和 Tag 都不會在正式頁面執行。

Trigger 是否觸發

用 Preview 測試頁面，往下捲到設定比例，確認 Scroll Depth Trigger 是否出現。如果沒有出現，檢查頁面是否太短、Some Pages 條件是否太嚴、Page Path 條件是否寫錯。

Tag 是否 fired

Trigger 出現後看 GA4 Event Tag 是否 fired。若 Trigger 有出現但 Tag 沒 fired，代表問題在標籤綁定、例外條件或標籤設定，而不是捲動行為本身。

是否發布

如果 Preview 都正常，但正式網站沒有資料，檢查 GTM 是否已 Submit / Publish。很多追蹤失敗其實不是設定錯，而是版本只停在工作區，沒有真正發布到網站。

GA4 是否收到

最後檢查 GA4 DebugView、Realtime、Measurement ID、自訂事件名稱與事件參數。如果 DebugView 有事件但報表沒有，可能是報表延遲或參數尚未註冊為自訂定義。若需要排查 GA4 基礎安裝，可回頭檢查 GA4 安裝設定。

排查順序	檢查項目	常見問題	下一步
1	GTM 容器	頁面沒有安裝或 ID 錯誤	確認網站原始碼與容器 ID
2	Scroll Depth Trigger	頁面條件不符合或頁面太短	用 Preview 檢查事件流程
3	GA4 Event Tag	Trigger 有觸發但 Tag 沒 fired	檢查標籤綁定與例外條件
4	版本發布	只測試成功但沒有 Publish	發布或回復版本
5	GA4 接收	送錯資源、事件名稱錯誤、參數沒註冊	查 DebugView 與自訂定義

本文不展開的 GTM 主題

這裡的 GTM 指 Google Tag Manager 的捲動深度追蹤，不延伸到其他同縮寫或其他追蹤工具；主題邊界越清楚，GA4 事件設定越不容易偏離目的。

Go-to-market 不是本文主題

GTM 也可能代表 Go-to-market，但這裡不討論市場進入策略、產品上市流程或銷售計畫。搜尋時看到 GTM，需先確認語境是 Google Tag Manager 還是商業策略。

其他行銷像素不展開

其他行銷像素也能透過 Google Tag Manager 管理，但和 GA4 捲動深度追蹤是不同任務。若同時設定太多追蹤，建議分版本處理，避免排錯時混在一起。

Server-side GTM 不展開

Server-side GTM 屬於另一層追蹤架構，適合在有明確資料治理與技術資源時評估。單純要把頁面捲動深度送進 GA4，先完成 Web 容器設定與驗證就夠用。

FAQ

GTM 是什麼？

GTM 是 Google Tag Manager，用來集中管理網站追蹤標籤，不需要每次都直接改網站程式碼。行銷與網站管理者可以透過 GTM 設定 GA4 事件、頁面互動追蹤與其他標籤。

GTM 可以用在行銷追蹤嗎？

可以。GTM 常見用途包含 GA4 事件、再行銷標籤與頁面互動追蹤。這篇只聚焦捲動深度，不延伸到所有行銷追蹤項目，避免設定目標變得太分散。

GTM 可以和 GA4 一起用嗎？

可以。GTM 負責判斷什麼時候觸發事件，GA4 負責接收、整理與呈現報表。捲動深度追蹤就是由 GTM 偵測使用者捲動比例，再把事件送進 GA4。

GA4 不是已經有 scroll 事件，為什麼還要用 GTM？

GA4 增強型評估通常只記錄接近頁面底部的 scroll。若要看 25%、50%、75%、90% 的閱讀落差，就需要用 GTM 自訂多段捲動深度追蹤。

捲動深度應該追蹤幾個百分比？

一般內容頁建議先追蹤 25%、50%、75%、90%。如果頁面很短，比例太多會製造噪音；如果頁面很長，才需要評估是否加入更細的比例。

事件名稱應該用 scroll 還是 scroll_depth？

若 GA4 內建 scroll 已開啟，建議自訂多段追蹤用 scroll_depth，再用 percent_scrolled 當參數。這樣可以避免和內建事件混淆。

GTM Preview 有觸發，但 GA4 沒看到資料怎麼辦？

先確認 GA4 Event Tag 是否 fired，再檢查 Measurement ID、事件名稱、DebugView、瀏覽器阻擋與同意模式。Preview 有觸發只代表 Trigger 成立，不代表 GA4 已收到。

設定完成後一定要發布嗎？

要。Preview 成功只代表測試環境成功，沒有 Submit / Publish，正式網站不會套用新版本。發布前應確認 Trigger、Tag、事件名稱與 DebugView 都已檢查過。

捲動深度可以當成轉換嗎？

通常不建議直接當主要轉換。捲動深度比較適合當內容互動指標，用來輔助判斷閱讀品質、段落吸引力與頁面下一步是否清楚。

GTM 是 Google Tag Manager 還是 Go-to-market？

兩者都可能縮寫成 GTM。這裡的 GTM 指 Google Tag Manager，用於管理網站追蹤標籤與 GA4 事件，不討論 Go-to-market 策略。