BigQuery export ломает аналитику не хуже кривого GTM: вот что проверить первым

BigQuery export ломает аналитику не хуже кривого GTM: вот что проверить первым

Если export в GA4 включён, это ещё не значит, что данные можно сразу использовать для отчётов и LTV-моделей. Самые дорогие ошибки обычно не в SQL, а в структуре событий и ключах, по которым вы потом собираете сессии, пользователей и конверсии.

Что проверить в первую очередь:
— одинаково ли пишутся user_pseudo_id и user_id;
— не дублируются ли события при повторной отправке;
— хватает ли параметров в purchase, refund, generate_lead;
— не теряются ли timezone и event_timestamp при объединении таблиц.

Отдельно смотрите на traffic_source и собранные вручную UTM: в export часто попадают ситуации, где первый источник пользователя и источник конкретной сессии смешиваются в одном отчёте. Если строите воронку, фиксируйте правило атрибуции до запроса, а не после. Иначе один и тот же SQL начнёт давать разные цифры в зависимости от окна и JOIN-логики.

Ещё одна типовая поломка — считать уникальных пользователей по event_name, а не по стабильному идентификатору. Для сверки используйте базовый каркас: WITH base AS (...), then GROUP BY user_pseudo_id, DATE(TIMESTAMP_MICROS(event_timestamp), 'Europe/Moscow').

Что делать на практике: сначала соберите один «эталонный» запрос для users, sessions и purchases, потом уже строите BI. Если базовая логика не воспроизводится в BigQuery, дашборд просто красиво оформляет ошибку.