技術原理#

跨網域追蹤透過在 URL 中添加 _gl 參數來傳遞使用者識別資訊。當使用者從網域 A 點擊連結到網域 B 時，GA4 會自動在連結中加入這個參數，讓網域 B 能夠識別這是同一位使用者，維持 session 的連續性。

1. 主網域與子網域#

當你的網站架構包含主網域與多個子網域時：

• www.example.com.tw
• shop.example.com.tw
• blog.example.com.tw

只要這些站點都安裝同一組 GA4 追蹤碼（相同的 G-XXXXXXXXXX），GA4 會自動整合資料，不需要額外設定跨網域追蹤。

NOTE

GA4 預設會將同一主網域下的所有子網域視為同一個網站，自動處理 cookie 的共享。

2. 單一網站#

如果你只經營單一網站，當然也不需要跨網域設定。

1. 多個不同主網域的整合需求#

當你需要追蹤使用者在以下情境的完整旅程：

• 企業官網（company.com）與購物平台（shop.net）
• 品牌網站（brand-a.com）與品牌網站（brand-b.com）
• 主站（main-site.com）與第三方結帳系統（payment-gateway.com）

2. 必要條件#

要成功實現跨網域追蹤，必須滿足：

• 所有網域都必須安裝同一組 GA4 追蹤碼
• 各網域管理者都同意共享使用者數據
• 正確設定跨網域追蹤參數

為什麼單方面設定無效？#

如果對方網站沒有安裝你的 GA4 追蹤碼，單方面設定跨網域追蹤：

1. 你只能追蹤到出站行為

   • 記錄使用者點擊外部連結的事件
   • 統計離站連結的點擊次數

2. 你無法取得對方網站的資料

   • 無法追蹤使用者在對方網站的行為
   • 無法知道使用者是否完成轉換
   • 無法還原完整的跨網域使用者旅程

3. GA4 報表會出現斷層

   • 使用者旅程在離開你的網站後就中斷
   • 來源/媒介歸因可能不準確

1. 技術層面#

• 所有參與的網域都安裝相同的 GA4 追蹤碼
• 在 GA4 管理介面正確設定跨網域清單
• 確保 _gl 參數能正確傳遞且不被過濾

2. 管理層面#

• 各網域管理者達成數據共享協議
• 明確定義數據使用範圍與權限
• 建立共同的數據治理規範

1. 加裝共用的第三組追蹤碼#

• 保留原有追蹤碼，額外安裝一組共用的 GA4 追蹤碼
• 優點：不影響原有數據收集
• 缺點：增加網站載入負擔，管理複雜度提高

2. 後端數據整合#

• 使用 BigQuery 匯出各自的 GA4 數據
• 透過 API 或 ETL 工具整合分析
• 優點：保持各自數據獨立性
• 缺點：無法使用 GA4 內建的跨網域分析功能

3. 使用 UTM 參數追蹤#

• 在跨網域連結加入 UTM 參數
• 各自在自己的 GA4 中分析流量來源
• 優點：實施簡單，不需技術配合
• 缺點：只能分析流量來源，無法串聯使用者旅程

1. 評估是否真的需要跨網域追蹤#

在決定實施前，先思考：

• 是否真的需要串聯不同網域的使用者旅程？
• 投入的資源與獲得的洞察是否成正比？
• 是否有其他替代方案能達到分析目標？

2. 集團或多品牌網站的規劃#

如果你管理多個品牌網站：

• 建議從一開始就規劃共用的 GA4 架構
• 使用單一 GA4 property 搭配資料串流區分
• 善用 GA4 的篩選器功能分析個別網站表現

3. 外部合作網站的處理#

當無法取得外部網站配合時：

• 專注於分析自身網站的流量與轉換
• 使用事件追蹤記錄出站點擊
• 透過 UTM 參數追蹤合作成效
• 考慮使用其他歸因模型評估合作價值

4. 技術實施注意事項#

如果決定實施跨網域追蹤：

• 確保所有網域使用相同版本的 GA4 追蹤碼
• 測試 _gl 參數是否正確傳遞
• 檢查是否有安全設定或重新導向影響參數傳遞
• 定期驗證跨網域追蹤是否正常運作

Q1: 設定跨網域追蹤後，為什麼還是看到自己網站的推薦來源？#

可能原因：

• 跨網域設定未正確完成
• _gl 參數在傳遞過程中遺失
• 網站有多次重新導向導致參數丟失

Q2: 可以只追蹤特定頁面的跨網域行為嗎？#

可以透過：

• 在特定連結手動加入追蹤參數
• 使用 Google Tag Manager 條件觸發
• 自訂事件追蹤特定的跨網域互動

Q3: 跨網域追蹤會影響網站效能嗎？#

影響極小：

• 只是在 URL 添加參數，不增加額外請求
• GA4 處理邏輯在用戶端執行，不影響伺服器