缩小 Google Analytics（分析）界面与 BigQuery Export 之间的差距

Minhaz Kazi，Google Analytics（分析）开发技术推广工程师 - 2023 年 4 月

“但为什么这些数据与界面中的数据不一致？”

如果您针对 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 Export 数据与标准报告、Data API 报告或“探索”报告进行准确的比较，请确认您的数据不是依据抽样数据。GA4 中的数据抽样对抽样进行了详细说明，并提供了解决方法。

活跃用户数

如果您统计在您的 GA4 媒体资源上记录了至少一个事件的所有用户，会获得“用户总数”指标。虽然 GA4 界面的“探索”中提供“用户总数”指标，但在 GA4 中用于报告的主要用户指标是活跃用户数。在 GA4 界面和报告中，如果仅提及“用户数”，通常是指“活跃用户数”。因此，在基于 BigQuery 数据计算用户数时，您需要进行过滤，仅保留活跃用户数，才能使数据与 Google Analytics（分析）界面中的数据相差无几。此外，计算方法也会因您选择的在报告中使用的 ID 而异。

技术实现

在 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++) 算法来估算“活跃用户数”和“会话数”等常见指标的基数。也就是说，当您在界面中或通过 API 查看这些指标的唯一计数时，看到的是具有一定精确度的近似值。在 BigQuery 中，您可以访问精细数据，能够计算这些指标的确切基数。因此，指标可能会有较小百分比的差异。当置信区间为 95% 时，会话数的精确度可能为 ±1.63%。精确度因指标而异，并会根据置信区间而有所变化。如需了解对于 HLL++ 的不同精确度参数，不同置信区间的精确度如何，请参阅 HLL++ 草图。

技术实现

请参阅 Google Analytics（分析）中的唯一计数近似值，了解如何在 Google Analytics（分析）中实现 HLL++，以及如何使用 BigQuery 查询来复制该功能。

数据收集延迟

每日导出表格在 Google Analytics（分析）收集当天的所有事件后创建。每日表格可以在表格创建日期后的长达 72 小时内更新，纳入时间戳为表格创建日期的事件。不妨了解详情并查看示例。如果您的 Firebase SDK 或 Measurement Protocol 实现会发送线下或延迟事件，这更是一个问题。根据标准报告界面和 BigQuery 在这 72 小时内进行更新的时间，您可能会发现它们之间存在差异。对于此类实现，应对时间超过 72 小时的数据进行比较。

高基数报告

假设您通过标准报告或 Data API 查看某报告。该报告显示大量数据，且具有高基数维度。高基数维度可能会导致报告超出底层表格的基数上限。如果发生这种情况，Google Analytics（分析）会将不太常见的值归为一组，并标记为“（其他）”。

我们使用简化的小型示例来说明，如果底层表格的基数上限为 10 行，预计会发生以下情况：

简化示例：标准答案数据与使用“（其他）”行的汇总表格

如您所见，事件总数保持不变。但是，不太常见的值会归为一组，并且您无法基于任何维度重新汇总表格（例如，您无法利用汇总表格获取高精确度的特定城市事件总数）。如果您基于任何维度过滤汇总数据，该示例会更深入。

“（其他）”行分组仅会在报告超出基数上限时出现在报告模块和 Data API 中。如果您通过 BigQuery 进行计算，获得的始终是标准答案数据，即细化程度最高的行。详细了解“（其他）”行以及有关如何避免显示该行的最佳做法。

Google 信号

在 GA4 媒体资源上启用 Google 信号有诸多优势，包括跨平台和设备删除重复的用户。假设您未实现 User-ID 和 Google 信号，当某个用户使用三个不同的网络浏览器查看您的网站时，Google Analytics（分析）会将其计为三个不同的用户，而 BigQuery Export 将具有三个单独的 user_pseudo_id。但是，如果启用 Google 信号，并且用户在所有三个浏览器中都登录了其 Google 账号，那么 Google Analytics（分析）会将该用户计为一个用户，并在标准报告界面中显示这一计数。不过，BigQuery 仍会显示三个单独的 user_pseudo_id。BigQuery Export 中没有任何 Google 信号信息。因此，与 BigQuery Export 相比，具有 Google 信号数据的报告中的用户数很可能会较少。

若要减轻这种影响，最好的方法是在启用 Google 信号的同时，在 GA4 媒体资源中实现 User-ID。这将确保首先基于 user_id 删除重复信息。对于已登录的用户，BigQuery 中会填充 user_id 字段，并且该字段可用于计算用途。但是，对于未登录的用户（即没有 user_id 的会话），系统仍会使用 Google 信号来删除重复信息。

另请注意，标准报告界面中的某些报告可能应用了阈值，不会返回特定数据。可能受阈值应用影响的大部分信息通常不会显示在 BigQuery Export 中。

意见征求模式和根据模型估算的数据

通过在网站和移动应用中实现意见征求模式，您可以向 Google 传达用户是否同意使用 Cookie 或应用标识符。如果访问者拒绝同意，GA4 会使用根据模型估算转化和行为建模来填补数据收集缺口。BigQuery 事件导出中没有任何根据模型估算的数据。实现意见征求模式后，BigQuery 数据集将包含 Google Analytics（分析）收集的不使用 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 的唯一组合数。在 Universal Analytics 中，会话数会在零点重置。如果您采用 UA 模型，计算每天的会话数，然后将其相加来计算出会话总数，则会重复计算时间涉及多日的会话数。
- 根据所选的在报告中使用的 ID，您必须更新用户数的计算方法。
维度和指标范围：确保计算时使用的是正确的用户、会话、商品或事件级范围。
时区：在 BigQuery Export 中，event_date 基于报告时区，而 event_timestamp 是采用世界协调时间 (UTC) 的时间戳（以微秒为单位）。因此，理想情况下，如果在查询中使用 event_timestamp，则在与界面数据进行比较时，必须针对正确的报告时区进行调整。
数据过滤和导出限制：如果您为 BigQuery 事件导出设置了数据过滤，或者您的每日事件导出量超出了限制，则 BigQuery 事件导出数据将与标准报告界面数据不一致。

以上就是这篇博文的全部内容。希望此处的指南可以帮助您为自己的独特项目选择合适的解决方案。如果您有任何疑问，欢迎使用 GA Discord 服务器进行查询！

商务解决方案

使用 HLL++ 的唯一计数近似值