為什麼網站需要跨網域設定？

當一個網站裡面跨越多個網域，GA4 無法辨識穿梭在這些網域的是同一位使用者，因此需要做「跨網域設定」告訴 GA4 這是同一位使用者。多網域的網站沒有做跨網域時將導致以下問題：

• 廣告標記遺失，無法追蹤廣告成效
• 網站使用者人數虛增

詳細說明如下：當一個網站內包含多個網域，例如從 www.abc.com 點擊站內連結到 www.def.com，兩個網站之間有連結互相來去，並且安裝的都是同一組 GA4 追蹤碼、同一組測量 ID (Measurement ID)。

GA4 會給每個網域的每位訪客 (正確地來說是每個瀏覽器) 指定獨立的客戶 ID (Client ID)，用於辨識使用者。即使裝了同一組 GA4 追蹤碼，當網域名稱改變，GA4 亦會指定一組新的客戶 ID。以上面的網址範例來說，訪客在 www.abc.com 與 www.def.com 的客戶 ID 將會不同，辨識為兩位使用者，導致前面提到的兩個問題：

• 廣告標記遺失，無法追蹤成效

假設廣告到達網頁為 www.abc.com，而轉換、交易在 www.def.com 完成。由於訪客在兩個網域有不同的客戶 ID ，對GA4來說就是兩位不相干的使用者。記錄在www.abc.com的廣告參數 (UTM參數、gclid…等) 也在訪客抵達 www.def.com 時中斷遺失，因而無法紀錄轉換、交易來自哪一檔廣告。

這是非常嚴重的問題，花費廣告預算卻不知道付出的錢為我們帶來多少效益，也無法評估廣告策略是否成功？是否需要優化？因此，對於有廣告投資的網站來說，如果站內有多個網域，設定跨網域非常重要。尤其是串接 GA4 轉換與目標對象的 Google Ads 、SA360、DV360 廣告。

• 網站數據虛增 (使用者、新使用者、工作階段)

前面提到GA4會給每個網域的每位訪客指定獨立的客戶ID，那就表示一位訪客在站內跨網域後被辨識為一位新的使用者，也會開啟新的工作階段，如此一來 GA4 中的部分網站數據就會高於真實，包含使用者、工作階段與新使用者等。

什麼是主網域？

進到「GA4如何設定跨網域」主題前，我們需要先簡單了解什麼是「主網域」。
以本次測試站網址 https://izzy.gtmpractice.com/ 為例，網域要從尾巴往前看，也就是從右邊看到左邊。我們把網址一段一段拆開來看，其中.com為頂級域名，gtmpractice 為二級域名，頂級域名加二級域名為 gtmpractice.com 是為主網域（根網域、網域名稱）；再往前推、在https://之後與二級域名gtmpractice前面的 izzy 則是「子網域」。

這邊主要記得，頂級網域＋二級網域 就是網站的「主網域」。為什麼要特別說明如何分辨主網域呢？理由是「主網域相同時不用設定跨網域」。

假設一個購物網站的商品頁網域是 shop.example.com，會員中心的網域是 member.example.com，而購物流程的網域是 pay.example.com。從網址結構中可以看出三個網域的「主網域」都相同，只差在「子網域」，對 GA4 來說這並不算「跨網域」。

但實際上 GA4 官方還是將網站的主要網域與子網域列入跨網域的清單中，避免出現 self-referral 的資料。稍後會說明如何設定。

如何找出網站包含哪些網域？

因此，在做跨網域設定前，了解網站網域的組成是很重要的工作。這時候又會產生一個問題，「要如何知道網站包含哪些網域？我需要走過網站所有的流程嗎？」答案是不用，在 GA4 中開啟一張空白的探索報表，選用維度「主機名稱」與指標「瀏覽」，時間區間至少選30天，很快可以看到目前網站使用了那些網域，取得「網域清單」。

以 Google 官方的 GA4 示範帳戶為例，網域清單包含：

• shop.googlemerchandisestore.com
• www.googlemerchandisestore.com
• googlemerchandisestore.com
• flood-it.app
  

其中前三個網域的主網域都是 googlemerchandisestore.com ，唯獨最後一個 flood-it.app 主網域不同，因此  googlemerchandisestore.com 與 flood-it.app 就是要設定跨網域的對象。

實務上，所有與主要網址網域不同的網域都需要設定跨網域，因為訪客的行為不可測，不知道訪客會踩到哪個網域，需全方位的確保跨網域設定不掉鍊。

取得網域清單，接下來就可以進到「GA4如何設定跨網域」。

GA4如何設定跨網域？

跨網域設定的位置

管理 ➝ 資料串流 ➝ 點擊主要的網頁串流 ➝ 進行代碼設定 ➝ 設定網域

管理

資料串流

點擊主要的網頁串流

進行代碼設定

設定網域

進入設定畫面

跨網域設定

開始設定前，先介紹本次示範用的三個測試網域：

設定主要網域

進到設定畫面後，首先要設定的就是網站的主要網域。這邊以  izzy.gtmpractice.com 示範，為了涵蓋 gtmpractice.com 所有的子網域，所以比對的類型選擇「包含」，並在網域欄位填入主網域 gtmpractice.com。在此條件下，第三個網站 merkle.gtmpractice.com 就不需要再設定一次，因為它也符合「網域 包含 gtmpractice.com」的設定條件。

步驟：點擊「新增條件」 ➝ 比對類型選擇「包含」  ➝ 網域「gtmpractice.com」

設定其他網域

接下來要設定其他網域 izzydeng.neocities.org。因為 neocities.org 是一個免費網頁空間的平台，我在使用的只有 izzydeng.neocities.org，這邊會填入完整的 izzydeng.neocities.org。

步驟：新增條件 ➝ 比對模式選擇「完全符合」 ➝ 網域填入「izzydeng.neocities.org」

跨網域設定提供的五種比對方式：包含、開頭為、結尾為、完全符合、與規則運算式相符。無論透過這些比對模式靈活的設定跨網域清單，或者土法煉鋼的一個一個填入都是可以的。

最後點擊「儲存」完成跨網域設定。

驗證跨網域設定

如果要驗證跨網域設定是否成功，在網站內進行跨網域的切換時，例如從 a.com 到 b.com，b.com的網址後面會自動加上跨網域參數 _gl ，看到這個參數就代表跨網域設定成功了。

iframe情況

這邊要注意「跨網域」設定無法作用於 iframe 結構的網站，例如有些網站會將活動網站用 iframe 包在主要網站中，內外框網域不同。這種情況通常廣告的到達網頁會設定在主要網站 (外框)，但是轉換會發生在活動網站 (內框)。此時即使做了跨網域設定也不會作用。應該採用 iframe postmessage 方法進行跨域通信，而非跨網域。

以上就是跨網域設定的完整流程與知識，可以符合大部分的網站的跨網域應用。

進階：跨網域與廣告

接下來是進階的部分，這個章節以「GA4 的串流配置對應跨網域，廣告參數是否也能夠跨網域續存」為題目，根據不同的網域與串流的搭配情境分析。

因為網站網域可能根據企業的組織架構與經營方式有很多種形態，例如不同事業體資料串流不同，但最終共用同一個結帳流程的網域；或是一個網站內的網域各自安裝不同的資料串流...等。遇到這些情況該如何應對呢？這部分跟GA4的帳戶、資源、資料串流的架構規劃脫不了關係，根據 GA4 數據的使用需求，甚至必須更改原先已經安裝好的 GA4 追蹤。

補充說明：以下是情境測試的描述與測試結果，測試過程都是使用無痕視窗。過程中同步監看 DebugView 。另外說明實驗記錄中提到的兩個事件：

• first_visit：GA4 用於辨識新使用者的事件，由 GA4 自動偵測觸發。
• session_start：GA4 用於辨識新工作階段開啟的事件，由 GA4 自動偵測觸發。
  
  

情境一：不同主網域，同一個資料串流（非 iframe）

例如活動網站與主要網站的網域不同，這是很常見的情境。廣告的到達網域會是活動網頁，活動網頁會導連到主要網站發生轉換。此時只要將主要網站的網域與活動網站的網域做跨網域設定，就可以將廣告參數從活動網站傳遞到主要網站。

情境二：相同主網域、同一資料串流、跨網域僅設定包含主網域

這個情境是相同主網域但是子網域不同的情境，跨網域的設定中，只設定了包含主網域。需要注意的是，因為主網域相同，從主要網站前往子網域時網址並不會帶上 _gl 參數，但在 DebugView 中可以觀察到沒有出現新的 first_visit 與 session_start事件，代表跨子網域行為發生時，訪客被識別為同一位使用者。

情境三：不同主網域、不同資料串流、互相做跨網域

主要網站與活動網站網域不同，並且各自有一個資料串流。在此情況下彼此設定跨網域是否可以傳遞廣告參數？

答案是「不建議」，即使彼此都有設定跨網域，但只要屬於不同的資料串流，在切換網域的當下會產生新的 session_start 事件，代表兩個串流的資料是分開紀錄。
在跨網域發生的當下網址中包含_gl參數，因此客戶 ID 在兩個網域還是一致，但是工作階段與新使用者事件還是分開計算的。

建議作法：

• 如果有廣告優化目標為跨網域後的轉換，必須將兩個網域整合到同一個資料串流。
• 不能整合的情況下，只能退而求其次將優化目標訂在到達網頁的聲量、新訪客數，或是到達網頁上的點擊行為。避免涉及跨網域轉換讓系統無效優化的情況。
  

情境四：相同主網域、不同資料串流、互相做跨網域

如果我們的網站都是相同的主網域，但是分別安裝在不同的資料串流，廣告參數可不可以傳遞？

這種案例時常見於電商網站，商品頁面與結帳流程的主網域相同，但是子網域不同，並且分別安裝在不同的資料串流，例如前面提到的 shop.example.com 與  pay.example.com。

答案也是「不建議」，只要屬於不同的資料串流，即使主網域相同廣告參數依然有可能會掉。

• 如果有廣告優化目標為跨網域後的轉換，必須將兩個網域整合到同一個資料串流。
• 不能整合的情況下，只能退而求其次將優化目標訂在到達網頁的聲量、新訪客數，或是到達網頁上的點擊行為。避免涉及跨網域轉換讓系統無效優化的情況。
  

結論

只要屬於不同的資料串流，不管主網域是否相同，廣告參數可能會發生遺失。因此對最好的做法是將訪客可能經過的所有網域都放在同一個資料串流底下，並完成跨網域設定，以有效的分析廣告成效，並取得最正確的數據。

有些網站配置上不同單位的資料需要放在不同資料串流，但是訪客轉換行為會在不同網站穿梭，又有重疊的部分，該如何安排呢？這是非常棘手的情況，過去我們可能可以透過舊版 GA 的資料檢視 (Views) 解決這個問題，但是 GA4 免費版並沒有相同的功能，要透過付費版的「子資源」才能做到近似的效果。在免費版 GA4 要兼顧資料查看權限與跨串流廣告優化幾乎不可能。

訪客行為在不同資料串流穿梭的情況，以下是目前已知的作法及其利弊分析：

• 將廣告參數從網址帶到下一個網域

這個做法有許多細節與配套措施需要考量，例如廣告參數的回溯期要設定多久 (Lookback windows)？Googld Ads 廣告需要全面改為手動標記、工作階段數與新使用者還是高於實際的問題...等。

• 一個網站上安裝多組GA4

在過去這個作法看似顧全了所有面向，但隨著使用 GA4 愈久，發現網站安裝多組 GA4 有可能發生數據異常的問題，例如工作階段數、新使用者數異常等。主要是由於安裝多組 GA4 在同一個網頁可能會造成 session_start 與 first_visit 判定的機制失常。缺少 session_start 事件將造成 session 數、與來源媒介判定異常。缺少 first_visit 事件則是某一組GA4的新使用者數會比較低。