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

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

После включения экспорта в GA4 многие ждут «сырые события в таблице». На практике вы получаете поток, где важно заранее договориться о 3 вещах: идентификаторы пользователей, валюты и таймзона отчёта. Если это не зафиксировать, дальше начнутся спорные метрики между GA4, BI и CRM.

Что проверить сразу:
— одинаково ли собирается user_pseudo_id / user_id
— не смешиваются ли event_date и event_timestamp в отчётах
— есть ли правила для duplicate events и late hits
— как трактуются null в параметрах и ecommerce-объектах

В запросах чаще всего ломают не JOIN, а granularity. Нельзя бездумно склеивать события, сессии и транзакции в один слой: сначала выделите event-level, потом session-level, потом purchase-level. Для витрин лучше сразу делать отдельные CTE под каждый уровень и только потом собирать финальную таблицу.

Полезный шаблон: храните raw export как есть, а бизнес-логику выносите в слой view или scheduled query. Тогда при смене правил атрибуции не придётся переписывать весь стек. И ещё: если в отчёте нужен стабильный KPI, фиксируйте его SQL-формулу рядом с дашбордом.

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