Google Analytics 4 如何透過 User ID 歸因使用者行為？

最後更新日期 2021 年 7 月 23 日|Google Analytics 4

GA4 User ID 歸因有自己的，因此，很多時候並不是 User ID 設定錯誤，而是解讀邏輯誤解；本篇文章將會拆解 User ID 歸因模型，帶你了解 GA4 如何歸因 User ID。如果你還不確定是否正確設定了 User ID ，可以參考 Google Analytics 4 資源 User ID 設定教學與應用範例。

認識 User ID 歸因模型

數據收集

GA4 對不同平台有著不同的標準：

在網站環境 – 只要使用者是在登入狀態下，每一個事件都必須送出 User ID ，否則 GA4 會把事件視為非登入狀態產生的行為活動。
在 APP 環境 – 只要使用者登入一次(有設定&送出 User ID)，未來所有事件都會自動套用該 User ID 。

User ID 歸因

注意：要啟用 User ID 歸因，必須確定預設報表識別資訊已經設定為『按 User ID 和裝置劃分』。

不管事件有沒有設定 User ID ，所有事件都會自動收集 user_pseudo_id 這個欄位資訊(依環境不同，分別儲存網站 client ID 和 APP 廣告 ID)，當帶有 User ID 的事件產生時， GA4 會使用 user_pseudo_id 欄位資訊，找到同工作階段內已經送出的事件，歸因為相同 User ID 。

以上圖為例，4個事件都是來自同一個瀏覽器裝置(111.111)，依序送出了事件1～事件4，產生了兩個工作階段；並於事件3送出了 User ID 資訊(UID001)，這時候 GA4 對其餘三個事件的歸因如下：

事件1：跨工作階段，不會歸因為相同 User ID。
事件2：同工作階段，先前的事件，會歸因為相同 User ID。
事件4：同工作階段，後續的事件，不會歸因為相同 User ID。

User ID 歸因將如何影響報表？

透過 User ID 歸因， GA4 只會將事件使用者歸屬，按照歸因邏輯重新進行分配（僅限於報表層級，不會更改底層原始數據）；也就是說， User ID 歸因並不會影響事件總數；但要注意的是，事件使用者歸屬在進行分配後，有可能會影響使用者數量，下面將透過兩個情境說明：

情境1 – 所有事件都有 User ID

使用者開啟了一個工作階段，工作階段內所有事件都有 User ID：

以上圖為例，使用者在同一工作階段內，先送了一個沒有 User ID 的事件，接著又送了一個有 User ID 的事件；由於是同工作階段，先前送出的事件，因此事件1 在 User ID 歸因後也會被歸屬於 UID001 這個使用者。

從分析中心的使用者多層檢視報表，可以看到只有 UID001 這個使用者，因為兩個事件都被歸因為同一個 User ID 產生的行為活動（事件計數顯示4，是因為除了送出的兩個事件以外，還有自動收集的 session_start & first_visit 事件）；這時候，系統計算的使用者數量為1。

情境2 – 有些事件沒有 User ID

使用者開啟了一個工作階段，工作階段內有些事件沒有 User ID：

以上圖為例，使用者在同一工作階段內，先送了一個沒有 User ID 的事件，接著送了一個有 User ID 的事件，最後送了一個沒有 User ID 的事件；雖然事件都是在同工作階段產生，但是事件3是在送出 User ID 以後才產生，所以事件3不會被歸因為 UID001。

從分析中心使用者多層檢視報表，可以看到出現了 UID001 和 111.111 兩個使用者，事件1和事件2被歸因為同一個使用者，事件3由於是在送出 User ID 後才產生的事件，所以沒有被歸因為同一個 User ID，事件也會獨立分開計算；這時候，系統計算的使用者數量為2。

額外資訊

雖然 GA4 歸因模型會重新分配使用者事件歸屬，但在資料底層，所有事件還是和原 user_pseudo_id （網站 client id 或 APP 廣告 ID）綁定在一起。

舉例來說，從情境2的使用者多層檢視報表，可以看到使用者 111.111 顯示事件計數為1，但是當我們點進去查看使用者活動資訊時，可以看到顯示事件計數變為5個，多出來的4個事件就是已經被歸因為 UID001 的事件；由此可推斷出， User ID 歸因並不會影響底層數據，事件本身還是和 user_pseudo_id 綁定在一起，使用 user_pseudo_id 仍然可以查看完整使用者活動資訊。

User ID 跨裝置歸因範例

為了能夠簡化 User ID 歸因，先前提到的情境範例，都是以同裝置產生的事件做說明；但實際上， User ID 歸因模型，主要是用於整合跨裝置產生事件，下面將會使用跨裝置行為，解析 User ID 帶來的歸因：

以上圖為例，使用者分別在3個不同裝置產生了不同事件：

裝置1：開啟工作階段，送出一個登入事件。
裝置2：開啟工作階段，先送出一個未登入事件，接著送出一個登入事件。
裝置3：開啟工作階段，先送出一個未登入事件，接著送出一個登入事件，最後再送出一個未登入事件。

備註：由於是在3個不同裝置開啟工作階段，所以3個裝置分別都會有額外的 session_start & first_visit 事件。

預設報表識別資訊 – 按 User ID 和裝置 ID 劃分

事件計數解讀方式：
- UID001：事件計數11，包含3個裝置 session_start & first_visit 事件(共6個)，加上裝置1（1個事件）、裝置2（2個事件）、裝置3（2個事件），合計11個事件。
- 333.333：事件計數1，裝置3產生的第三個事件，因為是在送出 User ID 之後才產生，所以沒辦法被歸因為 UID001 活動行為。

由於裝置1（111.111）和裝置2（222.222）產生的所有事件都已經被歸因為 UID001 活動行為，所以不會顯示在報表上，而裝置3（333.333）因為有一個事件沒被歸因到，所以還是會出現在報表上；這就造成最終在計算使用者時，裝置3會被重複計算為2個使用者，而裝置1和2則被合併計算為1個使用者。