為什麼我們要這麼做？
常用 GA4 的你是否有注意到，當我們使用維度「網頁位置（Page location）」或是「網頁路徑 + 查詢字串（Page path + query string）」時，會發現明明是同一個頁面，但因為網址後面所帶的參數不同，GA4 會將其判斷為不同的頁面，進而在報表中分開列出，導致閱讀困難。如下圖所示：
以上圖為例，我們可以看到網址末端（「？」之後）都帶著參數名稱「 fbclid 」，當我們將連結貼在 Facebook 粉絲團上時，使用者點擊連結之後，Facebook 會自動加上「 fbclid 」參數來協助進行追蹤，但也因為每個人每次的點擊都會帶上不同的參數， GA4 便將其判斷為不同的頁面，分開列於報表之中。
（一般我們稱這些為「參數」或是「查詢字串（Query String）」，為了配合 GA4 中的維度名稱，接下來的內容中我們都會以「查詢字串」來稱呼。）
過去的 GA3（Universal Analytics）後台中，有提供直接過濾這些「查詢字串」的功能，但在新版的 GA4 中確沒有這個選項，但我們依然可以透過 GTM 來處理這個問題，所以該怎麼做呢？
在開始之前，有幾件事情我們必須要先釐清，讓我們繼續看下去。
本篇重點
為什麼不用維度「網頁路徑與畫面類別」？
如果你心裡冒出這個疑問，非常好，代表你對 GA4 有一定的熟悉程度。
沒有錯，如果使用維度「網頁路徑與畫面類別」，因為不會顯示網址後的「查詢字串（Query String）」，GA4 就不會將同一個頁面分成好幾列，報表閱讀起來也就不會這麼雜亂。
但是，如果今天網站網址所帶的「查詢字串」是有意義的呢？
例如某些網站會在表單提交完成頁面的網址上帶上如「 submit=success 」或是訂單完成頁面帶上「 payment=success 」這類的「查詢字串」，方便使用者透過「篩選」或是「搜尋」的方式來觀察這些頁面的表現。
如果我們使用維度「網頁路徑與畫面類別」，雖然沒有了同一頁被分成好幾列的問題，但也因此無法在「標準報表 – 網頁與畫面 」中進行特定項目的查詢，且也無法看到那些帶有「 submit=success 」或是「 payment=success 」的網址。
或是網站的網址結構是預設即帶有「查詢字串」，例如常見的「 www.abc.com/?p=345 」或是 「 www.abc.com/?p=123 」，來代表不同的頁面，如果我們用維度「網頁路徑與畫面類別」，就無法一目瞭然的在 GA4 報表中區分不同的頁面。
（BTW，在規劃網站網址時，建議避免將「查詢字串」作為必要的網址結構，改用描述性網址。這樣不僅美觀，在 GA4 報表中也會更容易閱讀和理解。）
ㅤ
「篩選器」也無法解決這個問題
當然，看到這邊的你腦海中可能浮現了：「那我可以用篩選器的功能來濾掉那些如 fbclid、gtm_debug 或是 HubSpot 的 hssc 等查詢字串嗎？」
這麼做的話，你會將所有帶有特定「查詢字串」的資料都排除在外，報告的畫面會變得很簡潔沒錯，網址不再帶有這些「查詢字串」，但也因此讓數據變得不準確。
ㅤ
哪些維度會帶上「查詢字串」？哪些不會？
- 使用維度「網頁位置（Page location）」以及「網頁路徑 + 查詢字串（Page path + query string）」，報表也會顯示網址末端帶上的「查詢字串」，因此當你有多個 fbclid 這類型的追蹤參數時，同一個頁面在報表裡就會被分成好幾列。
ㅤ - 使用維度「網頁路徑與畫面類別（Page path and screen class）」，同一個頁面不會被分成好幾頁，但如果網站網址原本就有包含「查詢字串（Query String）」，如「 www.abc.com/?p=345 」或是 「 www.abc.com/?p=123
」，那你將無法分清楚是哪一頁，全部都只會顯示「 www.abc.com 」。
ㅤ - 如果使用維度「網頁參照網址（Page referrer）」，因為其顯示的也是帶上末端「查詢字串」的網址，也同樣會遇到同一個頁面被分成好幾列的問題。
因此面對上述這幾個維度以及情境，我們只能從根源下手，也就是整理這些「進」到 GA4 的資料（網址），直接移除這些不必要的「查詢字串」後，再傳送給 GA4。
ㅤ
如何找到這些「查詢字串」？
如果想知道你的 GA4 裡面記錄了哪些「查訊字串」，可以透過建立「探索報表」，選擇維度「網頁位置（Page location）」或是「網頁路徑 + 查詢字串（Page path + query string）」，並篩選該維度值中包含「？」的結果，就可以過濾出所有帶有「查詢字串」的網址，便可以將類似「fbclid」查詢字串記錄下來，以便後續處理。
接下來，讓我們進入到 GTM 的設定環節。
新增 GTM 變數範本 Trim Query
GTM 左側介面選擇「範本」 > 於右側「變數範本」區塊右上角選擇「搜尋範本庫」> 於右上角搜尋欄位輸入「Trim Query」> 找到後，選擇「Trim Query」 > 點擊右上角「新增至工作區」
點擊後，會跳出權限要求視窗，點擊「新增」就可以。
接著就會在「變數範本」區塊中看到「 Trim Query 」的出現。
建立排除參數的網址變數
GTM 左側介面選擇「變數」 > 右側下拉至「使用者定義的變數」區塊 > 右上角選擇「新增」> 點選「請選擇變數類型以開始設定」> 右邊彈出視窗選擇「 Trim Query 」
在 Trim Query 的設定介面中，於下拉選單中選擇「 Page URL 」，勾選「 Queries 」，最後在下方的列中輸入「查詢字串（Query string）」名稱，有幾個「查詢字串」就輸入幾列，不要寫在同一個列中，完成之後按下儲存。
例如：假設網址是「 www.abc.com/?fbclid=345 」，我們就在列中輸入「fbclid」 即可。
「Trim Query」除了可以移除「查詢字串（Query string）」參數以外，也可以處理「片段（Fragment）」，不過這些操作，都不會影響到網站原本的網址，也就是使用者瀏覽器網址列看到的樣子，我們只是整理的要傳送給 GA4 的網址，讓它不會帶上特定參數而已。
關於網址結構的部分如果尚不了解的朋友，可以參考文章 》認識網址結構。
覆寫 GA4 代碼預設參數
GA4 追蹤代碼本身會自動記錄並發送以下參數：language、page_location、page_referrer、page_title 以及 screen_resolution，接下來我們要做的，就是覆寫 page_location 參數，傳送沒有帶「查詢字串（Query string）」的乾淨網址。
GTM 左側面板選擇「代碼」 > 找到你的 GA4 安裝代碼 > 於事件參數列中，輸入 page_location > 右邊值選擇前面設定的「Trim Query 範本變數」> 完成後按下儲存。
就這麼簡單，接下來我們預期應該要看到，如果網址中帶有「查詢字串」 fbclid 的話，要會被消除後，才傳送給 GA4。
檢查一下
首先使用 GTM 「預覽」功能，並在網址中輸入帶有「fbclid」的網址（我們可以自己假造。）
預期應該要能看到 page_location 所帶的網址，不存在「fbclid」。
確認發送端沒有問題之後，我們也要檢查接收端的 GA4，確保進來的 page_location 沒有帶上 「fbclid」。
都沒有問題之後，便可以將代碼提交了，未來如果有更多需要移除的「查詢字串（Query String）」，只要再到「Trim Query 變數範本」中新增即可。
（你也可以試著移除 gtm_debug ，因為雖然是預覽模式，但其實 GA4 還是會將其紀錄到報表之中，一般我們也會將其移除。）
除了覆寫「GA4 追蹤代碼（Google Tag）」中的 page_location 以外，也記得要到所有「 GA4 事件」中覆寫 page_location 代碼（雖然「GA4 事件」會繼承「 GA4 追蹤代碼」的設定，但保險起見，我們還是可以進行覆寫）
如果你覺得每個「GA4 事件」都要一個一個輸入很麻煩，也可以善用「Google 代碼：事件設定」變數，將覆寫的 page_location 參數加入，未來只要選取就可以，不需要複製貼上或是手動輸入好幾次。
延伸閱讀》設定「Google 代碼：事件設定」變數
總結一下
透過以上步驟，GTM 將自動移除網址中的「查詢字串」，並將清理後的 URL 傳送到 GA4。這樣可以讓 GA4 更正確地識別和統計同一頁面，避免報表因為不同的「查詢字串」而變得混亂，從而提高分析報表的可讀性。
過去 GA3 有提供的功能，沒想到在 GA4 上卻不復存在（最起碼我們寫這篇文章的當下還沒有），不過依然可以透過 GTM 來解決這個，雖然步驟多了一些，但是終究還是讓我們的報表看起來乾淨一點了。
可惜的是，這個設定無法回溯，只有完成設定之後，報表中才會顯示移除「查詢字串」的網址，過去的資料依然會帶有那些你不想要的「查詢字串」。
ㅤ
移除「查詢字串」不會影響原社群媒體的追蹤
另外，雖然前面有講過了，但我們還是在結尾提醒一下，這邊我們做的只是將網址中的「查詢字串」移除後傳送到 GA4 中，並沒有影響到原本各社群平台的追蹤（除非你是用 Server 端 GTM 傳送資料給 Facebook CAPI），也不會影響 GA4 「預設管道群組」的歸因方式，因此不用擔心。
（關於「預設管道群組」的歸因方式，可以參考文章「GA4 預設管道群組中的「Unassigned」是什麼？」的介紹）
ㅤ
千萬不要移除這幾個「查詢字串」
例如 utm_source、utm_medium 以及 utm_campaign 等 utm_ 開頭的「查詢字串」名稱，或是 Google Ad 的 gclid 以及 DV 360 的 dclid，還有用在跨網域追蹤的 _gl，這些都是 GA4 用來判別廣告成效以及來源/媒介的「查詢字串」，如果將它們移除了，那就真的會影響到 GA4 的數據了，這點要特別注意。
延伸閱讀
如果你很喜歡這篇文章並且覺得內容有幫助，又剛有些多餘時間，歡迎你看看其它文章，繼續探索（這坑？這地獄？這片樂土？）
同時，如果對於內容有疑問或是建議，也歡迎你留言或是到社群上找我們，我們都會盡我們所知道的進行回覆：）