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

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

Если экспорт уже включён, основная боль обычно не в самой выгрузке, а в том, как потом с ней работают.

— Сразу проверьте, что вы понимаете гранулярность таблиц: событие, пользователь, предметы, параметры. Ошибка №1 — пытаться считать сессию как “одну строку”.
— Не пишите запросы наугад. Для параметров события и user_properties почти всегда нужен `UNNEST`, иначе часть данных просто не попадёт в выборку.
— Дубли чаще появляются не в BigQuery, а в логике JOIN’ов. Если соединяете события с таблицами заказов, фиксируйте ключи и всегда проверяйте, не размножили ли строки.
— Для отчётов по воронке не тащите всё подряд из сырой таблицы. Сначала соберите нормализованный слой: события, сессии, конверсии, а потом уже стройте витрины.

Что важно: экспорт в BigQuery — это не “готовая аналитика”, а сырьё. Без слоя преобразований вы получите медленные запросы, нестабильные метрики и вечные споры про расхождения.

Что делать на практике: держите отдельные SQL-шаблоны для `events`, `sessions` и `users`, а любую метрику сначала валидируйте на 20–50 строках вручную.

Итог простой: сначала структура данных, потом дашборд. Иначе BigQuery будет показывать не правду, а хаос в красивой упаковке.