BigQuery export ломается не на выгрузке, а на схеме и идентификаторах

BigQuery export ломается не на выгрузке, а на схеме и идентификаторах

Если export в GA4 включён, дальше важны не «есть ли данные», а как вы их читаете. Главные точки контроля:
— event_date и event_timestamp: для окон и дедупликации
— user_pseudo_id, user_id: не путать анонимного и авторизованного пользователя
— event_params и items: не тащить их как есть в отчёт без нормализации
— traffic_source и collected_traffic_source: источник нужно фиксировать по одной логике

Частая ошибка — строить отчёты по сырым событиям без учёта повторов. Один и тот же клик может быть записан несколько раз, а purchase — приехать с задержкой. Поэтому в витрине сразу задайте правило: сначала фильтр по событию, потом агрегация, потом отдельная дедупликация по business key. Для транзакций обычно хватает сочетания transaction_id + user_pseudo_id + event_timestamp.

Ещё один узкий участок — атрибуция. В export легко смешать session source, first user source и last non-direct. Если бизнесу нужен один стандарт, зафиксируйте его в SQL и не меняйте в каждом дашборде. Иначе один отчёт будет считать канал по сессии, другой — по пользователю, третий — по последнему клику.

Что делать на практике: соберите слой staging с разворотом event_params в плоские поля, отдельно храните raw и curated-таблицы, а в Looker Studio подключайте только curated. Тогда BigQuery export станет не «свалкой событий», а нормальной измерительной базой.