消除 Google Analytics (分析) 使用者介面與 BigQuery Export 之間的差距

Google Analytics 開發人員服務代表 Minhaz Kazi - 4 月 2023 年


「但為什麼這些數字與使用者介面不相符？」

如果您曾使用 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 AnalyticsBigQuery 事件匯出功能 將不會針對上述大部分新增值提供精細的資料。

因此，對於大量用途，標準報表介面和 BigQuery Export 的資料如果涉及這些限制， 發揮加值效果如果兩者都有內部一致性， 應該可以順利使用

現在來看看造成兩者差異的具體原因 以降低這些風險本文將著重說明 BigQuery 系統只會匯出每日事件，不會匯出串流匯出資料。

取樣

如要準確比較 BigQuery 匯出資料與標準報表，「資料」 API 報表 (或「探索」報表) 確認這些報告並非以取樣資料為基礎。 GA4 中的資料取樣提供更多詳細資訊和解決取樣問題的方法。

活躍使用者

如果計入在 GA4 中記錄了至少一個事件的所有使用者 資源，就能看到「使用者總數」指標。雖然使用者總數 GA4 UI 的「探索」提供該指標，這是 GA4 UI 中用於 GA4 中的報表就是「活躍使用者」。在 GA4 UI 和報表中，如果只有「使用者」 通常是指「活躍使用者」。因此，計算使用者參與度時 就是根據 BigQuery 資料篩選，然後只篩選並保留活躍使用者 將這些數據與 Google Analytics UI 相當。計算方法也會 會因您選取的報表識別資訊而有所不同。

技術實作

在 BigQuery 事件匯出資料中，如果您計算不重複使用者 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++ 並應用在 Google Analytics 中 運用 BigQuery 查詢

資料收集延遲

Google Analytics 收集當天的所有事件後，就會建立每日匯出表格。 每日資料表的更新時間最多可比表格日期晚 72 小時 具有時間加上資料表日期的事件。閱讀詳細資料 並查看相關範例如果發生這類情況， 導入 Firebase SDK 或 Measurement Protocol 時，以離線方式傳送或 事件。取決於標準報表介面和 BigQuery 在這 72 小時內更新，您可能會看到一些差異 兩者之間的關聯實現這類實作時，比較時應以較舊的資料進行比較 超過 72 小時

高基數報表

假設您是透過標準報表或 Data API 查看報表， 這份報表會顯示大量資料，並具有高維度維度 基數。高基數維度可能會導致報表超過 基礎資料表的基數限制。發生這種情況時 會將較不常見的值分組，並標示為 (other)。

使用簡化和小規模的範例 (如果分數的基數限制 基礎資料表為 10 列，這會產生以下結果：

「真值資料」與「匯總資料表」的簡化範例 列

如您所見，事件總數維持不變。不過，較少 頻繁的值會分組，而且您無法根據 例如無法擷取匯總表格 來精確計算特定城市的事件計數)。範例會 您可根據任何維度篩選匯總資料。

這一列的「(other)」列只會在報表模組中產生， 報表超過基數限制時的資料 API。如果您將 BigQuery 計算作業最終一定會得到真值資料： 最精細的資料列進一步瞭解 (other) 列和最佳做法 該如何避免

Google 信號

在 GA4 資源中啟用 Google 信號有幾項好處，包括： 在不同平台和裝置上簡化使用者。如果無法收集 ID 或啟用 Google 信號，且一名訪客透過三個管道瀏覽您的網站 Google Analytics 會將活動歸因於 不同使用者，而 BigQuery Export 也會有三個不同的 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 Export 不會有閾值限制。

網站和行動應用程式中的同意聲明模式可協助您向使用者傳達 Cookie 或應用程式 ID 同意聲明狀態。如果訪客拒絕同意聲明， GA4 會使用重要事件模擬和行為，填補資料收集缺口 模擬所有模擬資料都不適用於 BigQuery 事件匯出項目。 導入同意聲明模式後，BigQuery 資料集會包含不含 Cookie 的連線偵測 (ping) 且每個工作階段都會有不同的user_pseudo_id。因為 標準報表介面和 在 BigQuery 中檢視精細資料比方說，藉由行為模擬功能 活躍使用者人數可能會少於 BigQuery Export 模擬功能可能會嘗試根據沒有同意授權的個別工作階段，預測多個工作階段 使用者。

再次提醒您，為減輕影響程度，應在 GA4 中導入 User-ID 資源。系統會將 user_id 和自訂維度匯出至 BigQuery，無論是否 使用者的同意聲明狀態

流量歸因資料

BigQuery 在使用者 (初次造訪) 時提供流量歸因資料， 事件層級。這些是收集的資料。不過，由於 Google Analytics 導入自家的歸因模式，而得到的就是 無法直接在 BigQuery Export 中使用，也無法使用完整計算 準確搭配可用資料視應用情況而定 彙整 BigQuery 資料集與任何相關的第一方資料，並且建立資料集 您也需要調整歸因模式日後系統為流量收集的其他資料 歸因方法或許能透過 BigQuery 事件匯出功能取得。

常見的計算錯誤

  • 計算方法：在 BigQuery 中計算不同指標時 請務必使用正確的方法例如：
    • Google Analytics 4 工作階段的計算方式標準 正在計算 user_pseudo_id/user_id 和 ga_session_id，無論 時間範圍。在通用 Analytics 中，工作階段會在午夜重設。如果 採用通用 Analytics 模式，計算並新增每天的工作階段 才能算出工作階段總數，此時系統會重複計算 橫跨多天的工作階段
    • 使用者人數 (視您選取的報表識別資訊而定) 這項計算方法必須更新。
  • 維度和指標範圍：請確定計算採用的是 正確的使用者、工作階段、項目或事件層級範圍
  • 時區：在 BigQuery 匯出項目中，event_date 代表報表時間 但 event_timestamp 是世界標準時間時間戳記，以微秒為單位。以下內容 理想情況下，如果一個查詢使用 event_timestamp，就必須調整 與 UI 數據進行比較時，應顯示正確的報表時區。
  • 資料篩選和匯出限制：如果您已為 BigQuery 事件匯出功能，或已超過每日事件匯出量 所需要的數量上限，BigQuery 事件匯出資料將與標準價格不符 報表介面。

反正，本文中會有一些小事。希望你可以選取 請參閱這裡的指南，瞭解如何為您的 DISTINCT 專案建立適當解決方案。如果發生以下情況： 有任何疑問，歡迎加入 Google Analytics Discord 伺服器，查詢最符合需求的 WHERE 查詢！

上一頁
企業解決方案
下一頁
使用 HLL++ 的不重複計數