更新時間：2024年12月17號
在GA4中，session_start是非常重要的自動收集的事件之一。
每當GA4判定一個新的工作階段開始時，就會自動產生一次session_start事件。
了解session_start的運作方式，有助於你正確解讀：
- 工作階段
- 流量來源歸因
- 使用者行為分析
- 工作階段數量異常問題
許多常見的GA4問題，例如：
- 工作階段突然暴增
- 工作階段數量異常下降
- 流量來源歸因錯誤
- Direct 流量增加
- session 與session_start數量不一致
背後往往都與session_start有關。
本文將深入介紹session_start的運作原理、重要參數、產生條件，以及實務上常見的異常情況。
什麼是session_start？
session_start是GA4的自動收集的事件。
在GA4中，每個工作階段開始時，都會自動觸發session_start事件，表示新的工作階段已開始。
可以把兩者理解成：
- Session：一次訪問
- session_start：代表這次Session開始的事件
因此，每一個新的工作階段理應都會有一個session_start。
session_start是如何產生的？
GA4主要有有兩種情境會產生session_start：
- 第一次造訪網站：當使用者首次進入網站時，GA4會依序產生：first_visit>session_start>page_view
- 閒置超過30分鐘：若使用者超過30分鐘沒有任何互動，GA4會視為原本的工作階段已結束，當使用者再次與網站互動時，GA4會建立新的工作階段，並重新送出session_start。
我們通過一個示例，來看session_start是如何產生：
第一次透過自然搜尋進站：first_visit>session_start>page_view ，建立第一個工作階段
閒置超過30分鐘，再透過EDM回訪：session_start>page_view ,，建立第二個工作階段
第一次造訪網站時會發生什麼？
例如使用者第一次進入網站，事件通常會依照以下順序發生：
first_visit——>session_start——>page_view
當GA4判斷當前沒工作階段，GA4便會建立了一個新的工作階段，並為該工作階段指派sid和sct兩個重要參數。
許多人會以為sid和sct是session_start事件建立的，但實際上並非如此。
從BigQuery的原始事件可以觀察到，在第一次造訪時，first_visit通常比session_start更早送出，但first_visit已經包含sid和sct。
這表示GA4在建立新工作階段時，就已經產生了sid與sct，然後將這兩個參數附加到屬於該工作階段的所有事件中，而session_start 只是其中一個自動收集的事件。
因此，可以將整個流程理解為：
建立新工作階段（產生sid、sct）——>first_visit——>session_start——>page_view
如果是閒置超過30分鐘的流程，就少了first_visit。
session_start包含哪些重要參數？
session_start包含sid和sct兩個核心參數：
- ga_session_id（簡稱sid）：代表工作階段 ID，用來識別不同的工作階段，並將同一工作階段中的所有事件關聯在一起。其值本質上是工作階段開始時的 Unix 時間戳（秒），理論上可能重複，但會搭配user_pseudo_id一起識別，因此實務上幾乎不會發生衝突
- ga_session_number（簡稱sct）：代表工作階段編號，代表目前是該使用者的第幾個工作階段。例如第一次造訪為 1、第二次造訪為 2，可用來區分首次造訪與後續回訪產生的工作階段
這兩個參數都要儲存在Cookie _ga_<container-id>裡，當之後送出事件時，GA4就會讀取Cookie中的這個資訊，並將它們附加到事件中一起送往GA4，從而實現工作階段與事件的關聯。
當GA4建立新的工作階段時，首個發送給GA4請求會帶有一個_ss參數，表示session_start，如：
之後，同一工作階段內送出的其他事件雖然仍會攜帶sid與sct，但不會再包含 _ss=1。
例如：
| 事件 | _ss |
sid |
sct |
|---|---|---|---|
session_start（第一筆請求） |
✅ | ✅ | ✅ |
page_view |
❌ | ✅ | ✅ |
scroll |
❌ | ✅ | ✅ |
click |
❌ | ✅ | ✅ |
purchase |
❌ | ✅ | ✅ |
因此，只要在Network面板中看到 _ss=1，就代表GA4已建立一個新的工作階段。
session_start與Sessions的關係
很多人會直接認為：session_start = Sessions
事實上，兩者並不完全相同。
GA4並不是直接統計session_start的數量，而是根據工作階段ID去計算工作階段數。
工作階段的計算方式為：根據 user_pseudo_id + ga_session_id 去重後的工作階段數
這也是為什麼在BigQuery中計算Sessions時，通常會使用：
COUNT(DISTINCT CONCAT(user_pseudo_id,'-',ga_session_id))實務上常見情況是：
session_start 通常會比Sessions稍微大一些。
常見問題FAQ
session_start暴增
正常的應該是一個工作階段應該只會有一個session_start，但可能會出現，session_start暴增，每訪問一個頁面，就產生一個session_start，如：
明顯是工作階段建立邏輯發生異常，常見原因：
- 工作階段被重建：某些CMP或Cookie管理工具會自動刪除、重設GA4的Cookie ，導致識別為新用戶，誤判為新的工作階段，發送session_start，可以檢查每次事件發送的ga_session_id是否相同，如果不同就是這個原因，處理方式是將GA4的Cookie添加到CMP的白名單
- 多分頁瀏覽造成：部分瀏覽器環境下，同時開啟大量分頁也可能產生額外session_start
session_start是0？
你可能還會遇到session_start是0，但仍然存在工作階段資料：
常見原因是：跨午夜，如使用者在1月1號晚上訪問網站，直接1月2號才離開，那麼對於1月2號來說，session_start就是0。
session_start，卻沒有page_view？
工作階段只有session_start一個事件，沒的pageview事件
可能原因包括：
- page_view被停用：若關閉自動頁面瀏覽追蹤，可能只看到 session_start。
- page_view標籤未正常觸發：如GTM設定錯誤、 同意模式（Consent Mode）影響或JavaScript錯誤， 導致page_view未成功送出。
- 使用者快速離開或資料遺失：在極少數情況下： session_start已送出， page_view尚未送出， 使用者立即關閉頁面， 也可能造成僅看到session_start。
總結
session_start是GA4工作階段機制的核心事件，每當GA4判定新的工作階段開始時，就會自動產生一次session_start。
當你遇到工作階段異常暴增、流量來源歸因錯誤、Session數量異常等問題時，第一個應該檢查的事件，通常就是session_start。