BigQuery export ломают не настройкой, а плохой схемой событий и грязными полями

BigQuery export ломают не настройкой, а плохой схемой событий и грязными полями

Если выгрузка GA4 в BigQuery нужна не “для галочки”, а для отчетов и алертов, сначала проверьте структуру данных: event_name, event_timestamp, user_pseudo_id, event_params и items должны быть предсказуемыми. Без этого любой SQL быстро превращается в набор костылей.

Что важно:
• Стабильные имена событий без дублей и опечаток.
• Параметры в одном формате: не мешать строки, числа и пустые значения.
• Один и тот же смысл — один параметр, а не revenue / value / order_sum.
• Для e-commerce отдельно валидировать items, item_id, item_name, quantity, price.

На практике полезно сразу делать слой нормализации: вытаскивать параметры в плоскую таблицу, приводить типы и собирать базовые поля в отдельный view. Тогда Looker Studio и ad-hoc SQL перестают падать на каждом новом событии.

Еще один частый провал — ожидание, что экспорт сам по себе решит атрибуцию. Нет: BigQuery дает сырье, но дедупликация, sessionization и окно конверсии — это уже ваша логика. Если ее не описать, в отчетах появятся “магические” расхождения с интерфейсом GA4.

Вывод простой: сначала порядок в схеме данных и правилах нормализации, потом дашборды. Иначе BigQuery станет не хранилищем, а дорогим складом мусора.