BigQuery export ломают не SQL, а кривую схему событий и ожидания от данных

BigQuery export ломают не SQL, а кривую схему событий и ожидания от данных

Если выгрузка из GA4 в BigQuery уже включена, дальше начинается работа не с таблицей, а с дисциплиной данных. Для стабильного анализа нужны: единые названия событий, понятные параметры, одинаковые currency/value и отсутствие дублей на уровне client_id + event_timestamp.

Что обычно портит выгрузку:
— event name живёт своей жизнью: signup, sign_up, registration;
— параметры приходят то строкой, то числом;
— purchase без transaction_id или с повторной отправкой;
— UTM и referrer не нормализованы, а канал потом «прыгает».

Перед любым дашбордом проверь 3 вещи: наличие ключевых полей в каждом событии, структуру items и ecommerce-параметров, а также то, как собран session_id. Если в raw-данных нет стабильного идентификатора, SQL-слой не спасёт: отчёт будет красивым, но бесполезным.

Что делать на практике: сначала собрать минимальный слой очистки views или dbt-моделей, потом строить метрики поверх него. Хорошая база для начала — отдельные витрины по purchase, lead, sign_up и page_view, а не попытка сразу тащить весь сырой экспорт в BI.

Экспорт в BigQuery полезен не тем, что «там всё есть», а тем, что вы сами задаёте правила качества. Чем раньше их зафиксировать, тем меньше ручной сверки и споров между маркетингом, аналитикой и разработкой.