<b>BigQuery export ломается не на выгрузке, а на схеме и допущениях</b>

<b>BigQuery export ломается не на выгрузке, а на схеме и допущениях</b>

Самая частая ошибка — смотреть только на факт наличия экспорта. Дальше начинается грязь: дубли событий, пустые params, разные типы одного и того же поля, сессии, которые не собираются в один user journey, и отчёты, где «всё есть», но доверять им нельзя.

Проверь базу:
— events_YYYYMMDD читаются как сырые факты, а не как готовая витрина;
— event_params и user_properties надо разворачивать явно;
— user_pseudo_id не равен пользователю;
— timezone и date-границы в SQL всегда задаются руками;
— если используешь consent mode или серверную отправку, заранее сравни объём событий с GA4 UI.

Что важно: BigQuery export полезен не сам по себе, а когда у тебя есть слой нормализации. Минимум — таблица с событием, датой, идентификатором пользователя, source/medium, campaign, revenue и флагом качества данных. Без этого любой Looker Studio начнёт рисовать красивые, но бессмысленные графики.

Что делать на практике: сначала собери 3 контрольных запроса — по количеству событий, по выручке и по уникальным пользователям. Потом сравни их с GA4 интерфейсом на одном и том же периоде. Если расхождение стабильно — это не баг, а правило, которое нужно описать в документации проекта.

BigQuery экспорт работает, когда ты относишься к нему как к сырью. Не к отчёту.