Когда нужен BigQuery — а когда это уже лишние расходы

Кто-то — агентство, фрилансер или человек из вашей же команды — сказал: «нужно подключить GA4 к BigQuery». Звучит серьёзно, выглядит недёшево, а что это реально даст — не очень понятно. Вопрос закономерный: это настоящая потребность или просто попытка продать лишнюю работу?

Ответ — «зависит», но не расплывчато, а от трёх конкретных условий. Если ни одно из них не про вас, BigQuery сейчас покупать не стоит — эти деньги принесут больше пользы в другом месте.

Когда достаточно обычных отчётов GA4

Если раз в месяц вы смотрите на источники трафика, число конверсий и самые посещаемые страницы, ответ у вас уже есть. Стандартная панель отчётов GA4 — не раздел «Изучение», а обычные отчёты — уже считает и показывает эти цифры, и, по документации самого Google, стандартные агрегированные отчёты не подвержены сэмплированию (источник). То есть скрытой погрешности в этих числах нет — они уже точные.

Типичная ежемесячная планёрка выглядит так: «сколько покупателей пришло с каждого канала в этом месяце», «какие пять страниц смотрели больше всего», «есть ли разница между мобильными и десктопными посетителями» — все эти вопросы уже закрыты стандартными графиками в обычной панели отчётов. Если ваша потребность именно в этом, BigQuery не добавит ни одной новой цифры, для которой можно принять решение, — вы просто начнёте платить за тот же ответ более дорогим способом.

Когда сэмплирование становится реальной проблемой

Другая картина: трафик высокий, и вы регулярно строите в разделе «Изучение» специальные срезы — например, источник трафика × устройство × страница входа. Тогда цифры от запроса к запросу могут немного плавать, и это особенность движка живых запросов раздела «Изучение», а не стандартных отчётов. Кто реально с этим сталкивается: у локального сайта услуг с несколькими сотнями посетителей в месяц объём событий для обработки обычно слишком мал, чтобы дойти до этой точки. А у интернет-магазина с сотнями заказов в день, который каждую неделю тестирует новый срез данных, это происходит регулярно.

Решается это просто: данные, экспортируемые в BigQuery, — это «сырые, несэмплированные данные о событиях», как формулирует сам Google (источник). Если запрашивать таблицу напрямую через SQL, сэмплирование интерфейса полностью исчезает. Но эта выгода работает только тогда, когда вы действительно регулярно строите многомерные срезы, а не когда раз в месяц смотрите на общую цифру трафика.

Срок хранения данных — стена в 14 месяцев

Попробуйте сравнить прошлогоднюю Чёрную пятницу с показателями двухлетней давности в разделе «Изучение» — и можно упереться в стену: в стандартном (бесплатном) свойстве GA4 данные на уровне событий хранятся максимум 14 месяцев, и это ограничение касается именно отчётов «Изучение» и воронок (источник). Важная деталь: та же документация прямо говорит, что это ограничение не затрагивает стандартные агрегированные отчёты. Если годовой тренд трафика вам нужен именно из обычной панели отчётов, стена в 14 месяцев вас на самом деле не блокирует — проверьте это до того, как платить.

Откуда берётся эта разница: агрегированный отчёт уже показывает посчитанное число по дням («сегодня 240 сеансов»), а данные на уровне событий хранят путь каждого отдельного посетителя — из какой рекламы пришёл, какие страницы смотрел, через сколько дней вернулся. Итоговое число никуда не «удаляется», потому что оно уже посчитано; а вот путь конкретного человека становится недоступен в «Изучении» после 14 месяцев. Но если у вас сезонный бизнес и нужен анализ на уровне событий за несколько лет — например, из какой кампании пришёл пользователь и через сколько месяцев купил, — эта стена становится реальной. Данные, выгруженные в BigQuery, хранятся в вашей собственной таблице постоянно, без автоматического удаления.

Несколько источников в одном месте — где GA4 сам по себе останавливается

GA4 показывает поведение на сайте, но не хранит реальную сумму сделки из вашей CRM или продажу, закрытую по телефону. Спросите себя, как это делается сейчас: скорее всего, в конце месяца кто-то отдельно выгружает таблицу из Google Ads, отдельно из Meta, отдельно список из CRM — и сводит всё вручную в Excel. Это отнимает время и несёт риск ошибки, повторяющийся каждый месяц, потому что ни одна из систем не знает идентификаторов клиента другой.

Если нужно видеть расход на рекламу, поведение на сайте и реальный результат продаж в одной таблице, каждый источник должен попасть в одно место и соединяться через SQL — это как раз задача хранилища данных: GA4, рекламные платформы (Meta, Google Ads) и CRM в одной базе, доступной для запросов. Правильно настроенное один раз соединение потом не требует ручного повторения каждый месяц — оно обновляется само.

Почему для небольшого сайта это уже лишний расход

Сами цифры подсказывают ответ: бесплатный уровень BigQuery включает 10 ГиБ хранения и 1 ТиБ обработки запросов в месяц (источник), а стандартные свойства GA4 могут бесплатно экспортировать до 1 миллиона событий в день (источник). У небольшого или среднего сайта дневной объём событий и итоговый размер таблицы обычно долго остаются в пределах этих лимитов — то есть прямой счёт за BigQuery, как правило, не проблема.

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

Настоящий расход — в другом: кто-то должен написать и поддерживать SQL, чинить соединение таблиц, когда платформа меняет структуру экспорта, и, наконец, открывать результат и принимать по нему решения. Хранилище, которое никто не запрашивает, — это ежемесячные затраты на обслуживание при нулевой отдаче, даже если сама обработка данных стоит копейки.

BigQuery не делает данные лучше — он увеличивает число вопросов, которые можно задать; за вопрос, который вы никогда не зададите, платить не стоит, даже если счёт бесплатный.

Задайте себе три вопроса: я регулярно строю многомерные срезы в разделе «Изучение»? Мне нужна история на уровне событий длиннее 14 месяцев? Я хочу свести рекламу, сайт и CRM в одну таблицу? Если ни на один ответ «да» — не покупайте BigQuery сейчас. Если хотя бы на два — наша работа по сведению всех данных в одно хранилище как раз для этого: вместе определяем, какие источники реально нужны, и не даём заплатить за лишнее.