BigQuery export ломает аналитику не схемой, а грязными допущениями в отчётах

BigQuery export ломает аналитику не схемой, а грязными допущениями в отчётах

Если export включён, это ещё не значит, что данные готовы к работе. Чаще всего ломается не сбор, а логика запроса: путают user-level и event-level поля, не учитывают дубликаты событий, а потом строят выводы на сыром наборе без фильтров.

Проверь базу:
— в событиях используй `event_timestamp`, а не порядок строк;
— `event_params` и `user_properties` разворачивай явно, не «на глаз»;
— `user_pseudo_id` не равен пользователю в CRM;
— `session_traffic_source_last_click` и UTM в событиях — это не одно и то же;
— `is_active_user`, `entrances`, `engagement_time_msec` нельзя смешивать в одной логике без понимания уровня данных.

Что чаще всего ломает отчёт:
— считают конверсии по всем событиям, не убирая дубли;
— берут `COUNT(*)` вместо `COUNT(DISTINCT user_pseudo_id)` там, где нужен пользователь;
— джойнят таблицы по дате, теряя события на границе дня;
— строят сессии без нормализации таймзоны и окна бездействия.

Что делать на практике: сначала фиксируй уровень метрики: event, session или user. Потом пиши запрос так, чтобы каждое поле было привязано к своей сущности. Если логика не помещается в один CTE — это нормально. Если помещается, но не читается — тоже плохо.

BigQuery export полезен только тогда, когда запросы повторяют модель данных GA4, а не ломают её под удобный дашборд.