<b>BigQuery export ломается не в SQL, а в настройке схемы и идентификаторов</b>

<b>BigQuery export ломается не в SQL, а в настройке схемы и идентификаторов</b>

Если грузите GA4 в BigQuery как «потом разберёмся», проблемы прилетают почти всегда в одних и тех же местах:
— путают user_pseudo_id и user_id и потом не могут собрать пользователя;
— не проверяют, что event_params и items нужно разворачивать отдельно;
— пытаются считать конверсии по сырым событиям без дедупликации;
— забывают про timezone в отчётах и получают сдвиг по дню.

Что важно: экспорт — это не витрина «как в интерфейсе GA4», а сырые события. Там легко получить дубли, если один и тот же action летит из веба и сервер-сайда, или если в таблицах есть повторные загрузки. Для проверки сначала смотрите event_name, event_timestamp, event_id, user_pseudo_id и source платформы, а уже потом строите отчёт.

Для базовой валидации держите три запроса: количество событий по дням, топ event_name и сверку ключевой конверсии между GA4 и BigQuery. Если цифры расходятся, ищите не в JOIN’ах, а в логике триггера, времени отправки и правилах дедупликации.

На практике BigQuery export окупается только тогда, когда у вас есть единая схема именования событий и понятный список полей, которые считаются источником истины. Иначе это просто дорогой склад сырых логов.