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

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

Если GA4 уже льёт данные в BigQuery, главные ошибки обычно не в запросах, а в подготовке:
• нет стабильных имён событий и параметров;
• один и тот же смысл передают разными полями;
• не проверяют типы данных и пустые значения;
• не понимают разницу между event_params, items и user_properties.

Перед аналитикой соберите минимальный контракт данных: что считается событием, какие параметры обязательны, какие допускают null, где живёт идентификатор пользователя. Без этого любой отчёт будет «работать», но ответы будут плавающими. Особенно это заметно в воронках, LTV и атрибуции, где одна лишняя вариативность ломает сегментацию.

На практике держите отдельный слой проверок: наличие ключевых событий, дубликаты transaction_id, пустые session_id, неожиданные значения source/medium, несоответствие валюты и суммы. Для быстрых проверок хватает такого шаблона:

select event_name, count(*)
from `project.dataset.events_*`
where _table_suffix between '20250101' and '20250131'
group by 1
having count(*) = 0

BigQuery Export полезен не как «хранилище всего», а как сырьё для стабильной модели. Сначала фиксируете правила данных, потом строите отчёты, и только потом добавляете сложную атрибуцию. Иначе вы просто ускоряете производство мусора.