本篇要解決的問題
最近大家應該都忙著將公司埋 GA 的部份都換成 GA4 吧？在前一篇 GA4 事件 的筆記文中，解決了轉換成 GA4 後事件不吻合的陣痛期解法，這篇則是轉到 GA4 後，一些數據上「為什麼會不同？」的可能性原因整理，還有在認真的看過一次說明文件後，將覺得重要的內容給整理出來。
在往下讀之前，August 要先做一些說明。
GA3，就是官方文件中寫的「通用 Analytics (分析)」，因為相較於 GA4，直接講 GA3 會比較好理解，因此本篇直接將 通用 Analytics (分析) 稱為 GA3，而 GA4 就是 Google Analytics (分析) 4。
本篇內容很多是 August 看了文件後的猜測，因為目前 GA4 的相關文章很少，也還沒看到有專書，因此能找到的輔助對照資料也不多，就只能看文件說明後靠猜測了。
本篇主要看的說明文件：[UA→GA4] 比較指標：Google Analytics (分析) 4 與通用 Analytics (分析)
GA3、GA4 數據比較
GA4 的「使用者」，指的是活躍使用者：在網站或應用程式中開始工作階段的不重複使用者人數。
GA3、GA4 採用的使用者身分識別方法不同，3 用 Client ID，4 用 User-ID，差別如下表：
| GA3 Client ID | GA4 User-ID | |
|---|---|---|
| ID 的代表意義 | 某個匿名裝置或瀏覽器執行個體。 | 可能在一或多部裝置和/或瀏覽器上與內容互動的同一名使用者 (例如已登入帳戶的使用者)。 |
| ID 的設定方式 | 由 Analytics (分析) 資料庫隨機產生，並自動隨同所有的匹配傳送。 | 您必須自行設定 userId 並連同 Analytics (分析) 匹配一起傳送。 |
| 系統如何使用 ID 計算不重複使用者 | 在未啟用 User-ID 的資料檢視中，系統會根據用戶端 ID 計算不重複使用者。 | 在已啟用 User-ID 的資料檢視中，系統會根據 User-ID 計算不重複使用者。 |
GA3 的 Client ID，就是建一組亂數當作 User-ID 存進 cookies 裡，存進 cookies 裡的缺點就是：
無法跨瀏覽器、跨裝置、跨網域。
因此如果有使用到 GA3 的跨網域功能時，GA3 的作法就是將這組亂數在使用者跨網域的時候寫在網址上，所以有時我們逛網站時，會發現怎麼網址後面莫名其妙的多出了「_ga=xxxxxx」的參數。
GA4 主要看 User-ID，但 User-ID 我們必須自行傳送給 GA4。主要是因為 GA4 是 Web、App 通用，無法靠 cookies 來辨別是不是同一個人，就必須是我們在使用者登入後，自行把登入會員的 User-ID 傳送給 GA4，讓 GA4 在處理資料時能認出不重複使用者。
但……大概使用 GA 的人有 80% 以上都是不會主動傳 User-ID 的啊，至少 August 工作這麼久，還只遇過一位行銷人員主動說要用 User-ID 的功能。
設定 User-ID
GA3 也可以開啟 User-ID 的功能，以前有寫過筆記文，請看：User-ID 功能 設定及報表檢視。
GA4 設定 User-ID（文件）：
gtag('config', '這邊填評估 ID', {
'user_id': '這邊填 USER_ID'
});要注意的事，在看 GA4 報表時，維度的選擇上不會有「user_id」這個選項，即便我們主動傳了也不會有，傳 User-ID 給 GA4 是讓它可以辨別出是不是不重複的使用者。
如果想要看到 User-ID 的數值，就要改個方式，在傳 User-ID 的同時也傳送一組 XXX_id 出去，範例：
gtag('config', '這邊填評估 ID', {
'user_id': '這邊填 USER_ID'
});
// 多填寫這組使用者事件
gtag('set', 'user_properties', {
'crm_id' : '這邊填 USER_ID'
});上面的 crm_id 就是我們可以自定義的一個維度名稱，隨便想取什麼名稱都行，但要注意，這個自定義維度名稱，要在 GA4 後台的「設定 > 自定定義」上，建立一個範圍是「使用者」的自訂維度，GA4 才會把資料收集進報表中。
除了用寫程式碼的方式，也可以用 GTM 的介面來設定 User-ID，就麻煩自行參閱文件囉。
User-ID 的用途
主動把 User-ID 傳送給 GA4 有什麼好處呢？官方特別寫了一頁文件來說明：[GA4] 評估跨平台活動
裡面最驚訝的就是可以將報表用「已登入、未登入」來區分，如文件附圖：
事件
GA3、GA4 事件是不同概念
3、4 的事件概念完全不同。
GA3 的事件有「類別」、「動作」和「標籤」。而 GA4 完全沒有，參考之前 GA3 事件轉換至 GA4 的筆記文，除了 GA4 原有的事件參數，有自己的參數要增加時，要設定「自訂定義」。
這其實讓常常被追問 GA 事件的工程師們鬆了一口氣吧？至少不用面對「GA 事件的三個值是什麼？類別、動作、標籤要怎麼分別？有什麼不一樣？可以吃嗎？」之類的問題了。
3、4 事件計數的說明：事件計數。
DebugView 事件偵錯
GA4 有提供 DebugView 的介面：
要開通這項功能，只要在發事件時多加上一個參數即可（文件）：
// 所有事件都 debug
gtag('config', 'G-12345ABCDE',{ 'debug_mode': true });
// 指定的事件 debug
gtag('event', 'xyz', { 'debug_mode': true });不過，DebugView 必須選中自己正在測試的裝置才行，有點麻煩，有擴充功能可以偵測 GA4 的事件，推薦直接使用比較快：GTM/GA Debugger
電子商務事件
跟 GA3 的電商事件相比，GA4 給的參數有點不同，這部份文件上都有完整的範例了：Measure ecommerce。
完整的建議事件，也有官方文件可以參閱：[GA4] 建議事件。
轉換
對於同一個目標，這邊假設同一位使用者提交了表單 10 次：
- GA3 在同工作階段只會計算一次
- GA4 在同個工作階段會計算 10 次
工作階段、網頁瀏覽
文件上說：GA3、GA4，在「網頁瀏覽」的數值會接近。
但 August 實際看報表並非如此，反而「GA4 工作階段 、GA3 不重複網頁瀏覽量」才接近。
GA3 有一個很重要的事情，也是這次看文件才發現的，就是「utm」這個數不要沒事就塞進網站的連結上啊各位：
我們不建議您在自家網站上使用 UTM 標記，因為這會在通用 Analytics (分析) 中重設工作階段。如果您在自家網站上使用 UTM，則通用 Analytics (分析) 的工作階段數量可能會比 GA4 高出許多。
工作階段 注意事項
跳出率
GA3 的跳出率，在 GA4 被換成「參與度」。
參與度指的是：持續超過 10 秒、曾發生轉換事件，或包含至少 2 次網頁瀏覽或畫面瀏覽的工作階段數（文件）。
平均網頁停留時間、平均參與時間
GA3 是計算 平均網頁停留時間，如果前端寫過 監聽使用者關閉頁籤的事件 就知道，那一個叫痛苦，很多時候是抓不到使用者關閉或離開頁面事件的。
因此 GA3 其實是用「B頁 進入時間 – A頁 進入時間 = A頁 停留時間」，如果在 B頁 就關掉了沒有進到下一頁，那 B頁 就不會有停留時間的數據。
GA4 是計算 平均參與時間：應用程式在前景運作、或網站是使用者在瀏覽器中主要互動對象的平均時間長度（文件）。
這邊 August 的猜測是：
紀錄 A頁 進入時間，然後把每個捲動、點擊等的事件時間也記下。
之後把「最後一個事件的觸發時間 – A頁 進入時間 = 參與時間」，再把所有參與時間加起來後除以所有使用者，就得出了平均參與時間。
GA3 的「平均網頁停留時間」與「網頁」相關；GA4 的「平均參與時間」則與「使用者」相關（文件）。
