前言

GA4 鼓勵大家將資源與 BigQuery 做串接，以利數據即時性或是製作精美的儀表板。大家會做的一定是比較在 BigQuery 中 query 完的結果與 GA4 報表的數據是否相符，在比較的過程中，發現一個異常現象，分享給大家。

異常現象如下 :

同一個用戶(user_pseudo_id 相同)在「不同日期」下的 GA 會話 ID（ga_session_id）出現重複。

正常情況，每次用戶訪問網站且有產生一個新的工作階段時，都會產生一個獨一無二的會話 ID，但發現到 BigQuery 數據中，每日約0.1%的情況，明明已經結束了工作階段(事件時間間隔30分鐘以上)，新產生的事件，所配到的 ga_session_id 會與上一個工作階段的 ga_session_id 值相同。

Google Support 回覆

這一異常現象的成因被追溯到 Google Config 的控制機制。Google Config 負責管理 GA4 會話 ID 的生成和 session_start 事件的記錄。經檢查某些用戶（例如用戶編號 1241956253.170009864）的事件，發現在特定日期（如 11 月 2 日）並未記錄 session_start 事件。

此現象與Google  Config 未能正確觸發，導致會話 ID(ga_session_id) 沒有更新，進而將事件錯誤地關聯到過時的會話 ID (ga_session_id) 上，扭曲了 GA 報告數據。由於此問題偶發且比例低，難以重現，使得對客戶實施的故障排除遇到了限制。

結論

GA 會話 ID (ga_session_id) 在極少數情況下會出現異常重複，但這不應影響對大多數數據。

補充 SQL 計算互動工作階段

在 BigQuery 中計算網站& APP「互動工作階段」SQL

web 計算「互動工作階段」

WHEN (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'session_engaged') = '1' THEN

CONCAT(user_pseudo_id, CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING))END) AS engaged_sessions

APP 計算「互動工作階段」

WHEN (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'engaged_session_event') = 1 THEN

CONCAT(user_pseudo_id, CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING))END) AS engaged_sessions