實驗原因

GA4 的工作階段來源媒介報表中存在 (not set) 資料。一般來說，若訪客拜訪的到達網址沒有帶廣告參數時，這些流量應該會被分配到 (direct) / (none)，這使得報表中存在 (not set) 的資料令人難以理解。🤔

※ 尚未完成處理的資料也會以 (not set) 的型式出現在報表中，因此這次實驗的資料以超過 48 小時的資料為主。

實驗假設

每當使用者於前景開啟應用程式，或是瀏覽網頁/畫面，而且當下沒有其他有效的工作階段時 (例如先前的工作階段已逾時)，Analytics (分析) 就會視為已啟動新的工作階段。 - Analytics(分析)說明

若自訂事件的觸發早於 page_view 時，是否為導致工作階段來源媒介顯示為 (not set) 的可能原因之一？

實驗設計

這個實驗需要讓 自訂事件 早於 page_view 觸發，要在 GTM 裡面加一個自訂事件 first_event，並且讓 first_event 在 容器載入 (Container load)(網頁瀏覽) ^註1 的階段觸發；並且，更改 GA4 的 page_view 觸發時機「延後」到視窗已載入 (Window load)。如此一來，就可以實現自訂事件 first_event 早於 page_view 觸發的實驗情境。

1. GTM 設定：在GA4設定觸發前，先觸發一個自訂事件 first_event (不是 first_visit 喔！🤣)
2. 發佈 GTM 工作區
3. 使用帶 utm 參數的網址進入網站
4. 在 BigQuery 確認事件觸發順序
5. 在GA4 報表確定來源媒介

註一：網頁瀏覽觸發條件載入的順序

實驗過程 （驗證工具：GA4 預設報表與 BigQuery）

1. GTM：在GA4設定觸發前，先觸發一個事件 first_event

• 在 GTM 中，新增一個 GA4 自訂事件代碼：first_event，它的觸發時機為「所有網頁 (Container load)」。
• 將 GA4 設定代碼觸發時機延後到 「視窗已載入 Window load」。
• 避免干擾實驗，暫停其他代碼觸發。
• 發佈工作區。

2. 使用帶 utm 參數的網址拜訪網站

• utm_source: 20230406
• utm_medium: test
• utm_campaign: evt_bf_pv

3. 查看 BigQuery 中的結果

• 事件觸發順序： first_visit  >  session_start  >  first_event  >  page_view
• 確定 first_event 在 page_view 前觸發
• first_event 與 page_view 均正確帶上 utm 參數

4. 在 GA4 查看工作階段來源媒介分配的結果

• 流量歸因給來源媒介： 20230406 / test
• 事件都有被歸因到廣告參數：evt_bf_pv

結論

經過這次實驗的結果發現，即使自訂事件發生在工作階段的第一個 page_view 之前：

• 廣告參數 (utm 參數) 還是活得好好的，不會變成 (not set)
• 工作階段與使用者可以被整合為同一個。
• 自訂事件與預設事件均可以被歸因。

認定廣告來源的事件並不限定 page_view 事件。工作階段開啟時，自訂事件早於 page_view 觸發並不影響廣告參數被蒐集。

關於 GA4 工作階段來源媒介報表的 (not set) 成因，歡迎分享與討論 😊 。