О расхождениях между интерфейсом Google Аналитики и BigQuery Export

Минхаз Кази (Minhaz Kazi), специалист по связям с разработчиками, Google Аналитика, апрель 2023 г.


"Почему значения в интерфейсе не совпадают с данными?"

Если вы когда-либо работали с экспортированным в BigQuery данными событий для ресурса GA4, у вас наверняка возникал этот вопрос. Возможно, этот вопрос задавали вам. А когда вы пытались на него ответить, у вас наверняка спрашивали:

"И где об этом написано?"

В этой статье мы постараемся пролить свет на оба эт��х вопроса.

Прежде чем мы подробно рассмотрим причину расхождения между значениями, важно понять, для чего нужен экспорт событий в BigQuery. Пользователи Google Аналитики отправляют собранные данные в этот сервис, используя один из следующих методов: тег Google, Google Менеджер тегов, Measurement Protocol, SDK или импорт данных. В зависимости от настроек ресурса Google Аналитики система может значительно дополнить собранные данные, прежде чем они станут доступны на платформах стандартных отчетов, в том числе в стандартных отчетах, исследованиях и Data API. Среди прочего, она может добавить данные сигналов Google, моделей, атрибуции трафика, прогнозирования и другие.

Платформы стандартных отчетов разработаны таким образом, чтобы пользователи Google Аналитики могли извлечь из них максимальную пользу с минимальными усилиями. Однако мы понимаем, что некоторые пользователи хотели бы дополнить добавленные значения Аналитики или даже настроить показ данных совершенно иным образом. Для этих пользователей предназначен экспорт событий в BigQuery. С его помощью можно получить собранные данные, которые клиент или приложение отправляет в Google Аналитику. Экспорт событий в BigQuery не содержит детализированных данных для большинства упомянутых выше дополнений.

Таким образом, когда речь идет о дополнениях, в большинстве случаев не ожидается, что данные в стандартных отчетах и в BigQuery будут совпадать. Если присутствует внутренняя согласованность и значения соответствуют собранным вами данным, то о различиях можно не беспокоиться.

Далее мы расскажем о некоторых причинах различий и как их устранить, если это возможно. В этой статье речь идет только об экспорте ежедневных событий в BigQuery – потоковый экспорт не рассматривается.

Выборка

Чтобы обеспечить точное сравнение данных, экспортированных в BigQuery, с данными стандартных отчетов, Data API и Исследований, не используйте выборки. Подробнее читайте в статье Выборка данных в GA4.

Активные пользователи

Если вы посчитаете всех пользователей, для которых было зарегистрировано хотя бы одно событие в ресурсе GA4, то получите показатель Всего пользователей. Хотя он доступен в Исследованиях в интерфейсе GA4, основной связанный с пользователями показатель в отчетах GA4 – Активные пользователи. Если в интерфейсе и отчетах GA4 упоминается показатель Пользователи, то, скорее всего, имеются в виду Активные пользователи. Таким образом, при расчете количества пользователей на основе данных BigQuery необходимо отфильтровать только активных пользователей, чтобы их количество было сравнимо с тем, что показано в интерфейсе Google Аналитики. Метод расчета зависит от выбранного способа идентификации.

Техническая реализация

Если в данных экспорта событий в BigQuery посчитать количество уникальных идентификаторов пользователей, получится значение Всего пользователей. Ниже приведен пример запроса, с помощью которого можно посмотреть значения показателей "Всего пользователей" и "Новые пользователи" на основе 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 Аналитике используется алгоритм HyperLogLog++ (HLL++), чтобы оценивать количество уникальных значений для распространенных показателей, в том числе "Активные пользователи" и "Сеансы". Это значит, что количество уникальных значений для этих показателей, приведенное в интерфейсе или полученное через API, является результатом приблизительной оценки с определенной точностью. В BigQuery, поскольку у вас есть доступ к детализированным данным, вы можете рассчитать точное количество уникальных значений. Поэтому показатели могут отличаться на небольшой процент. При доверительном интервале, равном 95 %, количество сеансов будет показано с точностью ±1,63 %. Уровни точности различаются для разных показателей и зависят от доверительных интервалов. С уровнями точности при разных доверительных интервалах для разных параметров точности HLL++ можно ознакомиться в разделе HLL++ Sketches.

Техническая реализация

Узнать, как алгоритм HLL++ реализован в Google Аналитике и как воссоздать его функциональность с помощью запросов BigQuery, можно из статьи Приблизительный расчет уникальных значений в Google Аналитике.

Задержка при сборе данных

Таблицы ежедневного экспорта данных создаются после сбора сведений о всех событиях за день в Google Аналитике. В течение 72 часов после даты создания таблицы в нее могут добавляться события с пометкой времени, соответствующей этой дате. Вы можете ознакомиться с примерами и подробными сведениями об этом. Эта проблема будет иметь большее значение, если ваша реализация Firebase SDK или Measurement Protocol присылает события с задержкой или офлайн-события. В зависимости от того, когда платформа стандартных отчетов и BigQuery обновляются в течение этих 72 часов, между данными в них могут появиться различия. Поэтому для этой реализации следует сравнивать данные, которым не менее 72 часов.

Отчеты с большим количеством уникальных значений

Предположим, вы просматриваете отчет, используя платформу стандартных отчетов или Data API. В отчете много данных и есть параметры с большим количеством уникальных значений, из-за чего в базовой таблице может быть превышено ограничение на количество уникальных значений. В таких случаях в Google Аналитике более редкие значения будут сгруппированы в строке (Прочие).

Если рассмотреть упрощенный пример, в котором ограничение на количество уникальных значений для базовой таблицы составляет 10 строк, произойдет следующее:

Упрощенный пример, в котором показана разница между полными данными и сводной таблицей со строкой "Прочие"

Как видите, общее количество событий не изменилось, но более редкие значения сгруппированы вместе. Повторно агрегировать таблицу по какому-либо показателю нельзя – например, вы не сможете на основе сводной таблицы получить общее количество событий для определенного города с высокой точностью. Пример усложняется, если отфильтровать агрегированные данные по любому из показателей.

Такое объединение в строку "(Прочие)" происходит только в модуле отчетов и Data API, когда в отчете превышается ограничение на количество уникальных значений. Если вы выполняете расчеты в BigQuery, то всегда будете получать полные данные – наиболее детализированные строки. Подробнее о строке "(Прочие)" и о том, как избежать ее появления…

Сигналы Google

У активации сигналов Google для ресурса GA4 есть несколько преимуществ, в том числе дедупликация пользователей на разных платформах и устройствах. Если user-id и сигналы Google не реализованы и пользователь посетит ваш сайт, используя три разных браузера, Google Аналитика зарегистрирует это как просмотры трех разных пользователей, а в BigQuery будет три разных идентификатора user_pseudo_id. Но если сигналы Google активированы и пользователь вошел в свой аккаунт Google во всех трех браузерах, Google Аналитика выполнит дедупликацию пользователя и покажет соответствующие значения на платформах стандартных отчетов. Однако в BigQuery все равно будут показаны три разных идентификатора user_pseudo_id. Информация сигналов Google недоступна в BigQuery, поэтому в отчетах с данными сигналов Google, скорее всего, будет меньше пользователей, чем в BigQuery.

Наилучший способ уменьшить влияние этого фактора – реализовать идентификаторы User-ID в ресурсе GA4 и активировать сигналы Google. Тогда дедупликация сначала будет выполняться на основе user_id. Для вошедших в аккаунт пользователей в BigQuery будет заполнено поле user_id, которое можно будет использовать для расчетов. Однако для пользователей, не выполнивших вход (например, сеансов без user_id), для дедупликации будут использоваться сигналы Google.

Кроме того, обратите внимание, что в некоторых отчетах на платформах стандартных отчетов могут быть применены ограничения, из-за чего не будут возвращаться некоторые данные. Большинство сведений, к которым могут быть применены ограничения, в BigQuery обычно недоступны.

С помощью режима согласия на сайтах и в мобильных приложениях можно передать Google статус согласия ваших пользователей на хранение файлов cookie или идентификаторов приложения. Если пользователь не предоставляет согласие, в Google Аналитике 4 пробелы в собранных данных заполняются с помощью моделирования конверсий �� поведения. Смоделированные данные недоступны в экспортированных в BigQuery событиях. Если вы реализовали режим согласия, в наборе данных BigQuery будут запросы ping без файлов cookie, собранные Google Аналитикой, а в каждом сеансе будет свой идентификатор user_pseudo_id. В результате моделирования между значениями на платформах стандартных отчетов и в детализированных данных в BigQuery будут различия. Например, из-за моделирования поведения количество активных пользователей может быть меньше, чем в BigQuery, поскольку при моделировании выявляются случаи, когда для одного пользователя, не предоставившего согласие, регистрировалось несколько сеансов.

Чтобы уменьшить влияние этого фактора, опять же рекомендуется реализовать идентификаторы User-ID в ресурсе GA4. Идентификатор user_id и специальные параметры экспортируются в BigQuery независимо от статуса согласия пользователей.

Данные атрибуции трафика

В BigQuery данные атрибуции трафика доступны на уровне пользователя (первое посещение) и события. Эти данные собираются. Однако в Google Аналитике реализована собственная модель на уровне сеанса, поэтому эта информация недоступна в BigQuery напрямую и ее нельзя точно рассчитать на основе доступных данных. При необходимости вы можете объединить набор данных BigQuery с любыми подходящими собственными данными и создать собственную модель атрибуции. В будущем дополнительные данные для атрибуции трафика могут быть доступны после экспорта событий в BigQuery.

Распространенные ошибки при расчетах

  • Методика расчета. При расчете различных показателей в BigQuery важно выбрать подходящую методику. Например:
    • Стандартный метод учета сеансов для ресурсов Google Аналитики 4 – рассчитать уникальные комбинации user_pseudo_id/user_id и ga_session_id независимо от периода времени. В Universal Analytics сеансы сбрасываются в полночь. Если вы будете использовать модель UA, рассчитаете количество сеансов за каждый день, а затем путем суммирования получите общее количество сеансов, то сеансы, которые длятся больше одного дня, будут учтены повторно.
    • В зависимости от выбранного способа идентификации метод расчета количества пользователей нужно будет изменить.
  • Область действия показателей и параметров. Уб��д��тес��, ��то в ваших расчетах используется подходящая область действия на уровне пользователя, сеанса, позиции или события.
  • Часовой пояс. В BigQuery event_date указывается в часовом поясе времени в отчете, а event_timestamp – временная метка UTC в микросекундах. Поэтому для правильного сравнения со значениями в интерфейсе параметр event_timestamp в запросе нужно откорректировать в соответствии с часовым поясом отчета.
  • Фильтрация данных и ограничения при экспорте. Если вы настроили фильтрацию данных для экспорта событий в BigQuery или объем этого экспорта превысил ограничение, данные экспорта событий в BigQuery не будут соответствовать значениям на платформах стандартных отчетов.

В этой статье много полезной информации. Надеемся, вы сможете выбрать подходящие решения для вашего проекта. Если у вас есть вопросы, вы можете задать их на сервере Discord Google Аналитики.

Назад
Бизнес решения
Далее
Расчет приблизительного числа уникальных посетителей с помощью HLL++