Google Analytics (分析) 開發人員服務代表 Minhaz Kazi - 2023 年 4 月
「為什麼數據與 UI 不相符？」
若您使用過 GA4 資源的 BigQuery 事件匯出資料，您必定會問過這個問題。更糟的是 有人要求你提供相關資訊因此，在嘗試回答時，您可能已經準備好回答後續問題：
"哪裡可以說？"
本文將著重介紹這兩項功能。
在深入探討數字差異之前，請務必瞭解 BigQuery 事件匯出資料的預期用途。Google Analytics (分析) 使用者 可透過以下其中一種收集方法，將收集到的資料傳送至 Google Analytics (分析)：Google 代碼、Google 代碼管理工具、Measurement Protocol、SDK 和資料匯入。 根據 Google Analytics (分析) 資源的設定，Google Analytics (分析) 在收集到的資料送達標準報表介面 (包括標準報表、探索和 Data API) 前，已能發揮重要價值。這些附加價值包括 Google 信號、模擬、流量歸因、預測等。
標準報表途徑的目標是在最順暢的時候，為 Google Analytics (分析) 使用者提供最高價值。但我們瞭解，對於各式各樣的使用者，有些可能想補足 Google Analytics (分析) 的附加價值，甚至是全面自訂。對於這些使用者來說，理想狀況是 BigQuery 事件匯出功能。BigQuery 事件匯出功能會收集的資料，這些資料會從用戶端或應用程式傳送至 Google Analytics (分析)。BigQuery 事件匯出功能不會包含上述大多數新增值的精細資料。
因此，在大量的使用案例中，這些附加值的各部分應該不會與標準報表介面和 BigQuery 匯出資料互相核對。如果兩者的內部一致性，且與收集的內容相符 就應該就能開始使用。
現在讓我們來深入探討造成差異的幾個具體原因，並盡可能找出降低這些原因的方法。本文僅著重說明 BigQuery 每日事件匯出，而非串流匯出。
取樣
為正確比較 BigQuery 匯出資料與標準報表、Data API 報表或「探索」報表，請確認這些資料並非以取樣資料為基礎。如需進一步的詳細資訊和處理取樣的方式，請參閱 GA4 中的資料取樣頁面。
活躍使用者
如果計算在 GA4 資源中記錄到至少一個事件的所有使用者，就會取得「使用者總數」指標。雖然 GA4 UI 的「探索」中提供「使用者總數」指標，但 GA4 報表的主要使用者指標是「活躍使用者」。在 GA4 UI 和報表中，如果只提及「使用者」，通常是指「活躍使用者」。因此，從 BigQuery 資料計算使用者人數時，您必須篩選並只保留活躍使用者，才能讓這些數據與 Google Analytics (分析) UI 進行比較。計算方式也會因您選取的報表識別資訊而異。
技術實作
在 BigQuery 事件匯出資料中，如果您計算不重複 User-ID 的數量，就會發現「使用者總數」數量。以下查詢範例會依據 user_pseudo_id 顯示「使用者總數」和「新使用者」：
-- Example: Get 'Total User' count and 'New User' count.
WITH
UserInfo AS (
SELECT
user_pseudo_id,
MAX(IF(event_name IN ('first_visit', 'first_open'), 1, 0)) AS is_new_user
-- Replace table name.
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
-- Replace date range.
WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
GROUP BY 1
)
SELECT
COUNT(*) AS user_count,
SUM(is_new_user) AS new_user_count
FROM UserInfo;
如果只要選取活躍使用者，請將查詢範圍限制在 is_active_user 為 true 的事件：
-- Example: Get exact and approximate Active User count.
WITH
ActiveUsers AS (
SELECT
user_pseudo_id
-- Replace table name.
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
-- Replace date range.
WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20201130'
AND is_active_user
GROUP BY 1
)
SELECT
COUNT(DISTINCT user_pseudo_id) AS exact_active_user_count,
APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_active_user_count
FROM ActiveUsers;
HyperLogLog++
Google Analytics (分析) 使用 HyperLogLog++ (HLL++) 演算法來估算常見指標 (包括活躍使用者和工作階段) 的基數。這表示當您透過 UI 或 API 查看這些指標的不重複計數時，這些指標是具有特定精確度的約略數量。在 BigQuery 中，由於您可以存取精細的資料，因此能計算出這些指標的確切基數。因此指標可能會有極小的百分比變化。在信賴區間 95% 時，以工作階段數而言，精確度可能是 ±1.63%。精確度層級會因指標而異，並且會根據信賴區間變更。如要瞭解 HLL++ 的不同精確度參數，請參閱 HLL++ 草圖，瞭解不同信賴區間的精確度等級。
技術實作
如要瞭解 Google Analytics (分析) 中 HLL++ 的實作方式，以及如何使用 BigQuery 查詢複製功能，請參閱 Google Analytics (分析) 中的不重複近似值。
資料收集延遲
Google Analytics (分析) 收集當天的所有事件後，就會建立每日匯出表格。 每日資料表最多可以更新到資料表日期之後 72 小時內，其中的事件帶有資料表日期的時間戳記。請參閱這篇文章的詳細說明並查看範例。如果 Firebase SDK 或 Measurement Protocol 實作項目會在離線或延遲事件中傳送，則這不是問題。視標準報表介面和 BigQuery 在 72 小時內更新的時間而定，您可能會發現兩者之間有所差異。針對這類實作，則應比較 72 小時以前的資料。
高基數報表
假設您透過標準報表或 Data API 查看報表。 報表會顯示大量資料，且具有高基數的維度。高基數維度可能會導致報表超出基礎資料表的基數限制。在這種情況下，Google Analytics (分析) 會將較不常見的值分組，並標示為「(其他)」。
使用精簡和小型樣本，如果基礎資料表的基數限制為 10 列，則預期會發生的情況如下：
如您所見，事件總數維持不變。不過，較少出現的值會歸為一組，而且您無法根據任何維度重新匯總資料表 (例如，您無法擷取匯總資料表，也無法以高精確度的方式取得特定城市的事件總數)。如根據任何維度篩選匯總資料，則此範例會更加明顯。
只有在報表超過基數限制時，才會在報表模組和 Data API 中套用這個「(other)」列。假如您使用 BigQuery 計算，最終值一定是實際資料，也就是最精細的資料列。進一步瞭解「(other)」列，以及避免發生此問題的最佳做法。
Google 信號
在 GA4 資源上啟用 Google 信號有幾項好處，包括跨平台和裝置重複使用者。假設未導入 User-ID 和 Google 信號，如果使用者透過三種不同的網路瀏覽器瀏覽您的網站，Google Analytics (分析) 就會將網站計為三位不同的使用者，BigQuery 匯出作業則會有三個獨立的 user_pseudo_id。但啟用 Google 信號後，如果使用者同時在三個瀏覽器中登入同一個 Google 帳戶，Google Analytics (分析) 就會重複計算一位使用者，並在標準報表平台中顯示這項計數。不過，BigQuery 仍會顯示三個獨立的 user_pseudo_id。BigQuery 匯出項目中沒有任何 Google 信號資訊。因此，包含 Google 信號資料的報表，使用者人數可能會比 BigQuery Export 更少。
如要降低這項效應，最佳做法是在 GA4 資源中導入 User-ID 並啟用 Google 信號。這可確保系統會先根據 user_id 執行簡化作業。對於已登入的使用者，user_id 欄位會填入 BigQuery，並可用於計算。但如果使用者未登入 (即沒有 user_id 的工作階段)，系統還是會使用 Google 信號簡化資料。
另請注意，標準報表介面中的某些報表可能會套用閾值，而不會傳回特定資料。一般來說，BigQuery 匯出內容不會提供大多數可能受到閾值限制的資訊。
同意聲明模式和模擬資料
您可以使用網站和行動應用程式中的同意聲明模式，將使用者的 Cookie 或應用程式 ID 同意聲明狀態傳送給 Google。訪客拒絕同意時，GA4 會使用轉換模擬和行為模擬來填補資料收集缺口。BigQuery 事件匯出項目中不會提供任何模擬資料。導入同意聲明模式後，BigQuery 資料集會包含 Google Analytics (分析) 收集的不含 Cookie 連線偵測 (ping)，且每個工作階段都會有不同的 user_pseudo_id。基於模擬功能，標準報表介面與 BigQuery 中的精細資料會有所差異。舉例來說，由於行為模擬的關係，與 BigQuery Export 相較，活躍使用者人數可能會較少，因為模擬功能會嘗試預測未同意個別使用者的多個工作階段。
同樣地，為減少這個問題的影響，建議您在 GA4 資源中導入 User-ID。無論使用者的同意聲明狀態為何，user_id 和自訂維度都會匯出至 BigQuery。
流量歸因資料
在 BigQuery 中，使用者 (首次造訪) 和事件層級可取得流量歸因資料。我們會收集這些資料。不過，Google Analytics (分析) 會在工作階段層級導入專屬的歸因模式，因此該資訊無法在 BigQuery 匯出中直接取得，也無法使用可用資料完整計算出。視用途而定，您可以考慮將 BigQuery 資料集與任何相關的第一方資料彙整，然後建立自己的歸因模式。日後，您可以透過 BigQuery 事件匯出功能取得其他收集到的流量歸因資料。
常見計算錯誤
- 計算方法：在 BigQuery 中計算不同的指標時，請確保採用正確的方法。例如：
- 維度和指標範圍：確保計算使用正確的使用者、工作階段、項目或事件層級範圍。
- 時區：在 BigQuery 匯出中，
event_date代表報表時區，而event_timestamp是以微秒為單位的世界標準時間時間戳記。因此，當一個查詢使用event_timestamp時，在與 UI 編號比較時，必須先根據正確的報表時區進行調整。 - 資料篩選和匯出限制：如果您為 BigQuery 事件匯出設定了資料篩選功能，或每日事件匯出量已超過限制，BigQuery 事件匯出資料會與標準報表平台不符。
換句話說，這篇文章也有一些不足之處。希望您可以從這裡的指南中，為 DISTINCT 專案選取合適的解決方案。如有任何疑問，歡迎加入 GA Discord 伺服器。歡迎查詢！