BigQuery Export ломают не ошибки SQL, а мусор в схеме и событиях

BigQuery Export ломают не ошибки SQL, а мусор в схеме и событиях

Если хотите нормальную аналитику, проверьте экспорт до того, как начнёте строить отчёты:
— event_name должен быть стабилен и без дублирующих вариантов;
— event_params не должен превращаться в свалку из 20 почти одинаковых ключей;
— user_pseudo_id и ga_session_id нужны для связки событий, а не для красоты;
— timestamps лучше нормализовать сразу, иначе воронки и атрибуция поедут.

Самая частая ошибка — тянуть в BI сырые таблицы без слоя очистки. В результате одно и то же действие считается по-разному в разных дашбордах, а JOIN по `event_params` начинает тормозить на объёмах. Для регулярной работы почти всегда нужен промежуточный слой: развернуть параметры, зафиксировать типы, убрать пустые строки, собрать базовые флаги событий.

Если нужен минимум, держите три объекта: raw export, cleaned events и reporting view. В cleaned events уже должны быть `event_date`, `user_id`, `session_id`, `event_category`, `event_action`, `event_label` или их эквиваленты. Тогда Looker Studio и любые ad hoc-запросы не будут каждый раз переизобретать логику.

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