更新時間：2026年6月5號
問題
假設你有一個網站，並且包含多個子網域：
- example.com
- app.example.com
現在要安裝GA4，是每個子域分別使用一個資料串流，還是只用一個資料串流，或是使用不同資源？
原理分析
要理解這個問題，首先需要了解GA4如何識別使用者（User）與工作階段（Session）。
GA4網頁版主要透過Cookie來識別訪客，其中最重要的是以下兩個 Cookie:
| Cookie 名稱 | 預設到期時間 | 說明 |
|---|---|---|
| _ga | 2 年 | 用於區分使用者。 |
| _ga_<container-id> | 2 年 | 用於維持工作階段狀態。 |
_ga Cookie：用於識別使用者
_ga Cookie 主要儲存 Client ID，用來辨識同一位使用者。
當網站採用：
- example.com
- app.example.com
這類主網域與子網域架構時，GA4 預設會將 _ga Cookie 寫入頂層網域（example.com），如：
因此無論使用者是在：
- example.com
- app.example.com
- blog.example.com
之間切換，通常都能維持相同的使用者識別，不會產生新的使用者。
ga<measurement-id> Cookie：用於維持工作階段
真正需要注意的是：_ga_<measurement-id> Cookie。
此 Cookie 用於保存Session ID、Session Number、Engagement 資訊
而它是與GA4資料串流（Data Stream） 綁定的。
例如：
- G-AAAAAAA 會產生一組 _ga_XXXX
- G-BBBBBBB 會產生另一組 _ga_YYYY
不同資料串流會產生不同的 Session Cookie。
因此當使用者從example.com跳轉到app.example.com
如果兩個網站使用不同資料串流，就可能產生新的工作階段。
方案對比
方案一：每個子網域使用不同資料串流
| 網域 | 資料串流 |
|---|---|
| example.com | Stream A |
| app.example.com | Stream B |
在此架構下：
- ✅ 使用者（User）通常仍可被辨識為同一人
- ❌ 工作階段（Session）容易中斷
可能出現：
- Session 數量膨脹
- 平均工作階段時間失真
- 流程分析中斷
- 轉換路徑不完整
使用者明明只瀏覽一次網站，卻可能被計算成兩個工作階段。
方案二：共用同一個資料串流（推薦）
| 網域 | 資料串流 |
|---|---|
| example.com | Stream A |
| app.example.com | Stream A |
由於使用相同的Measurement ID：
- _ga Cookie 共用
- _ga_<measurement-id> Cookie 也共用
因此：
- ✅ 使用者識別連續
- ✅ 工作階段連續
- ✅ 使用者旅程完整
- ✅ 漏斗分析更準確
例如：首頁（example.com）>登入（app.example.com）>購買（app.example.com）,整個流程都會被視為同一個工作階段。
這也是大部分SaaS平台、電商網站與企業官網的標準做法。
方案三：使用不同GA4（Property）
| 網域 | Property |
|---|---|
| example.com | Property A |
| app.example.com | Property B |
這種情況與使用不同資料串流的結果類似。
因為每個 Property：
- 擁有獨立的 Measurement ID
- 擁有獨立的 Session Cookie
- 擁有獨立的資料模型
因此：
- ❌ 工作階段無法延續
- ❌ 使用者旅程被切割
- ❌ 跨網域分析更加困難
除非有特殊需求，例如：
- 不同事業體
- 不同品牌
- 不同客戶資料隔離
- 法規或權限需求
否則通常不建議拆分成多個Property。
實務建議
對於大部分網站而言，建議採用：同一個GA4 Property + 同一個Web Data Stream，
確保使用者（User）識別一致，工作階段（Session）不中斷，旅程完整，轉換歸因更準確。
