Skip to content
Google Analytics 4 如何透過 User ID 歸因使用者行為?

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

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 這個使用者。

GA4 使用者多層檢視 User ID

從分析中心的使用者多層檢視報表,可以看到只有 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。

Google Analytics 4 使用者多層檢視 User ID

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

額外資訊

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

GA4 使用者行為活動

舉例來說,從情境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 劃分

Google Analytics 4 使用者多層檢視報表
  • 事件計數解讀方式:
    • 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個使用者。

預設報表識別資訊 – 僅限按裝置 ID 劃分

GA4 使用者多層檢視報表

使用僅限按裝置 ID 劃分預設報表資訊時,報表會以最原始數據呈現使用者活動行為,由此可看出,不管有沒有使用 User ID 歸因,報表顯示的事件總計數(12)都會一樣,而使用者數量則有可能會因為使用者行為不同導致歸因後產生變動。

注意事項

數據處理時間

GA4 數據處理時間最長為 72 小時,72小時內數據都有可能會變動,在數據完全處理完成以前,有可能會發生 User ID 歸因不完全,或是事件計數被重複計算。

使用者數量計算

由本篇文章提到的範例中可以得知,使用 User ID 歸因時,依照不同使用者產生的跨裝置行為活動,使用者數量有時候會被合併;有時候會被重複計算,因此進行使用者數量相關分析時,必須將此因素考量,並確實導入正確 User ID 事件代碼,以取得最精準的使用者數據。

更多有關 USER ID 的說明可以參考官方文件

數據顧問服務

數據酷顧問團隊
提供企業專屬的數據解決方案

文章許願池

想看什麼文章主題?
我們會儘快為您安排

數據顧問服務

數據酷顧問團隊
提供企業專屬的數據解決方案

文章許願池

想看什麼文章主題?
我們會儘快為您安排

數據顧問服務

數據酷顧問團隊
提供企業專屬的數據解決方案

文章許願池

想看什麼文章主題?
我們會儘快為您安排

Scroll To Top