<b>BigQuery export ломает аналитику не настроенностью, а грязной схемой данных</b>

<b>BigQuery export ломает аналитику не настроенностью, а грязной схемой данных</b>

Самая частая ошибка — считать, что экспорт сам по себе решит все проблемы. Нет: он просто переносит сырые события в SQL, а дальше вы живёте с дубликатами, неполными параметрами и разной логикой идентификаторов. Если заранее не договориться о правилах, отчёты в Looker Studio и сводки в BI быстро начинают расходиться.

Что проверять сразу:
— ключи дедупликации: event_name, event_timestamp, user_pseudo_id, event_bundle_sequence_id;
— наличие нормального event_id для важных событий;
— структуру event_params, чтобы не тащить в запросы хаос из пустых значений;
— связку client_id / user_id, если нужен кросс-девайс;
— timezone и логику сессий, если строите воронки не в GA4, а в SQL.

Отдельно смотрите на объём и типы полей. repeated fields в BigQuery удобны до первого сложного JOIN: один неверный UNNEST — и метрика раздваивается. Для постоянной работы лучше сразу собрать слой с нормализованными таблицами: события, пользователи, сессии, конверсии. Тогда поверх него можно строить любые витрины без переписывания каждого запроса.

Самый полезный паттерн — не тянуть raw-export напрямую в дашборд, а делать промежуточную модель с понятными правилами фильтрации и атрибуции. Тогда BigQuery становится не складом логов, а источником правды.