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

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

Если ждёте от экспорта «готовую аналитику», почти всегда получаете сырые события. В BigQuery нет магии: там лежит то, что отправил трекинг, включая пустые параметры, дубли и кривые типы. Поэтому первый чек — не дашборд, а качество данных на уровне события.

Проверьте базовые вещи:
— event_name и user_pseudo_id реально заполняются
— параметры не прыгают между string, int и float
— повторяющиеся события не считаются за конверсии
— вложенные массивы распакованы так, как вы их потом будете читать в SQL

Самая частая ошибка — пытаться строить отчёт сразу по raw events без слоя нормализации. Сначала соберите витрину: определите ключевые события, зафиксируйте единые названия параметров, отдельно обработайте consent-логику и user stitching. Иначе любой запрос через месяц начнёт давать другой ответ.

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

Что делать на практике: заведите один контрольный запрос и один контрольный дашборд, которые показывают не бизнес-метрики, а здоровье экспорта. Если сырьё чистое, BigQuery начинает работать как фундамент. Если нет — вы просто строите BI на песке.