Looker Studio тормозит, а счет за BigQuery пугает финдиректора? Архитектура идеального дашборда для CMO

11.08.2026

Шарафутдинов Р.

Боль CMO: Дашборд грузится вечность, а финдир хватается за корвалол

Представьте типичное утро Chief Marketing Officer (CMO). Кофе налит, ноутбук открыт, впереди совещание с советом директоров. Нужно быстро глянуть САС (Customer Acquisition Cost), ДРР и LTV в разрезе последних рекламных кампаний. CMO открывает Looker Studio...

...и смотрит на крутящийся синий кружочек.

Минута. Две. Три. На четвертой минуте дашборд выплевывает ошибку: "Looker Studio has encountered a system error" или "BigQuery error: Quota exceeded". В этот же момент в Slack стучится финансовый директор с вопросом: «Слушай, а почему мы за прошлый месяц сожгли в BigQuery $3000? Вы там биткоины майните на таблицах Google Analytics?». Знакомая картина? Если да, добро пожаловать в клуб «Мы настроили GA4 Export, но забыли про архитектуру».

В ОЗАТ мы регулярно сталкиваемся с такими проектами. Компании радостно включают интеграцию Google Analytics 4 (GA4) с BigQuery, подключают туда данные из amoCRM, 1C и рекламных кабинетов (через OWOX или Airbyte), а потом напрямую натравливают на это месиво Looker Studio (бывший Data Studio). Спойлер: так делать нельзя.

В этой статье мы разберем, почему ваш Looker Studio тормозит, почему BigQuery жрет деньги как не в себя, и как построить Data-архитектуру здорового человека, чтобы отчеты летали, а финдир спал спокойно.

Антипаттерны: Как НЕ надо строить аналитику

Давайте начнем с жесткого код-ревью типичного дашборда, собранного «на коленке» аналитиком, который очень спешил.

Грех 1: "SELECT * FROM events_*" прямо из Looker Studio

Это классика. Вместо того, чтобы подготовить витрину данных (Data Mart), аналитик подключает Looker Studio напрямую к сырым таблицам GA4 (events_*). Каждый раз, когда CMO меняет дату в фильтре дашборда, Looker отправляет в BigQuery запрос, который сканирует десятки гигабайт (а то и терабайт) данных.

BigQuery — это колоночная база данных. Она берет деньги за объем отсканированных данных, а не за время выполнения. Выполнили тяжелый запрос? Заплатили $5. Поменяли фильтр с «Google» на «Яндекс»? Заплатили еще $5. Страницу обновило 10 человек? С вас $50. За одно утро.

Грех 2: Data Blending (Объединение данных) на стороне Looker Studio

«О, нам нужно связать сессии из GA4 со сделками из CRM! Сделаем-ка мы Data Blending прямо в интерфейсе Looker Studio по Client ID». Звучит как план? Нет, это катастрофа.

Looker Studio — это инструмент визуализации, а не ETL-движок. Когда вы джойните две огромные таблицы внутри Looker, он пытается сделать это в оперативной памяти браузера или на своих хилых внутренних серверах. Результат: тормоза, лимиты на количество строк, и сломанные дашборды.

Грех 3: Бесконечные вьюхи (Views) поверх вьюх

Аналитик решает проблему сырых таблиц: «Окей, я напишу SQL-запрос, который чистит данные, и сохраню его как View в BigQuery, а Looker подключу к этому View». Потом он делает еще один View поверх первого. И еще один.

Проблема в том, что View не хранит данные. Каждый раз, когда Looker обращается к верхнеуровневому View, BigQuery «разворачивает» всю матрешку запросов до самых сырых таблиц и выполняет сканирование с нуля. Время ожидания растет экспоненциально.

Архитектура идеального дашборда: Разделяй и властвуй

Чтобы всё работало быстро и дешево, мы должны строго разделить процесс на 3 слоя (Layers): Raw (Бронза), Staging (Серебро) и Marts (Золото). Этот подход называется Data Lakehouse или просто мейнстримным аналитическим стеком (Modern Data Stack).

Слой 1: Raw (Сырые данные)

Здесь лежат данные в том виде, в котором они поступили из источников. Они не чищены, не отфильтрованы, в них дубли.

GA4 Export: Таблицы events_YYYYMMDD.
CRM (amoCRM, Bitrix24): Выгрузки лидов, сделок, контактов (через Cloud Functions, Airbyte или Fivetran).
Рекламные кабинеты: Косты и клики из Google Ads, Meta, Yandex Direct, TikTok.

Правило слоя: К этим таблицам имеет доступ только скрипт трансформации (ETL/ELT). Looker Studio сюда вообще не смотрит!

Слой 2: Staging и Transformation (Серебро)

Здесь начинается магия dbt (Data Build Tool). Если вы еще не используете dbt — самое время начать. Это фреймворк, который позволяет писать SQL-трансформации как программный код (с версионированием в Git, тестами и макросами).

На этом слое мы:

Очищаем данные от дублей.
Приводим типы данных в порядок (парсим JSON-поля GA4 event_params).
Стандартизируем UTM-метки.
Создаем промежуточные таблицы сессий, пользователей и сделок.

-- Пример dbt-модели для извлечения параметров GA4 (Staging)
SELECT
  event_date,
  event_timestamp,
  event_name,
  user_pseudo_id AS client_id,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'campaign') AS utm_campaign,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source') AS utm_source
FROM
  {{ source('google_analytics', 'events') }}
WHERE
  _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())

Слой 3: Data Marts (Золотые витрины данных)

А вот это — святая святых. Именно к этим таблицам будет подключаться Looker Studio. Мы создаем OBT (One Big Table) — одну широкую денормализованную таблицу для конкретного дашборда.

Рекомендуем к прочтению

Топ-5 архитектурных "костылей", которые мы постоянно находим на сайтах отечественных компаний

05.08.2026

Например, таблица mart_marketing_performance_daily. В ней уже всё сджоинено (сессии + расходы + сделки), сгруппировано по дням, кампаниям и источникам. В ней нет сотен миллионов строк кликстрима, в ней всего пара тысяч строк с агрегатами.

Самое важное: Эта таблица должна быть материализованной (Materialized Table). Она обновляется раз в сутки (или каждый час) через Scheduled Queries или dbt Cloud.

Когда CMO открывает дашборд, Looker Studio делает запрос к этой крошечной агрегированной таблице. Объем сканирования — 2 Мегабайта. Стоимость запроса — $0.00001. Время загрузки дашборда — 0.5 секунды. Бинго!

FinOps: Как укротить счета от Google Cloud

Итак, архитектуру мы исправили, дашборды летают. Но как еще сильнее срезать косты на BigQuery, особенно на этапе трансформации данных?

1. Партиционирование (Partitioning)

Это абсолютный маст-хэв. Таблицы в BigQuery должны быть разбиты на партиции (сегменты) по дате (event_date или created_at).

Если таблица партиционирована, и вы пишете в запросе WHERE event_date >= '2026-08-01', BigQuery физически не будет сканировать данные за 2024 и 2025 годы. Вы платите только за сканирование нужных партиций.

2. Кластеризация (Clustering)

Помимо партиционирования по дате, таблицы можно кластеризовать (отсортировать) по часто используемым полям для фильтрации или группировки. Например, по utm_source и campaign_id.

Если CMO фильтрует дашборд только по "Google Ads", BigQuery благодаря кластеризации быстро найдет нужные блоки данных, пропуская всё остальное. Это еще сильнее снижает объем сканируемых байт.

3. Инкрементальные обновления (Incremental Models)

При использовании dbt не нужно каждый день пересчитывать всю историю за 5 лет. Используйте materialized='incremental'. dbt возьмет данные только за вчерашний день, трансформирует их и добавит (UPSERT) в финальную золотую таблицу.

4. BI Engine: Кэширование на стероидах

Если вам нужны сверхскорости, включите BigQuery BI Engine. Это In-Memory кэш (база данных в оперативной памяти), который сидит между BigQuery и Looker Studio.

Вы выделяете 1 или 2 ГБ памяти (стоит копейки, порядка $30 в месяц за 1 ГБ). BigQuery сам определяет, какие данные нужны для дашборда, кэширует их в оперативке и отдает Looker-у практически мгновенно, вообще не запуская тяжелые SQL-движки и не расходуя квоту на сканирование.

С BI Engine дашборды грузятся быстрее, чем вы успеваете моргнуть, а счета за случайные запросы аналитиков падают в пропасть.

Кейс: Застройщик с дашбордом за $1500 в месяц

Пару месяцев назад к нам в ОЗАТ обратился девелопер. Их штатный аналитик собрал супер-дашборд по сквозной аналитике, где маркетологи отслеживали воронку от клика до подписания договора.

Проблема: дашборд грузился 4 минуты, регулярно падал с ошибками, а счет за BigQuery перевалил за $1500 в месяц. Почему? Они джойнили сырые таблицы GA4 с 1С прямо через кастомные SQL-запросы внутри Looker Studio без партиций. Маркетинговый отдел из 10 человек каждое утро "сжигал" по сотне долларов, просто тыкая в фильтры дат.

Что мы сделали за 2 недели спринта:

Настроили dbt-проект.
Написали модели (Staging), которые парсили сырой JSON из GA4 инкрементально.
Собрали одну широкую таблицу mart_cmo_dashboard с партиционированием по дате сделки/визита.
Переподключили Looker Studio на эту таблицу, удалив все джойны на стороне BI.
Включили BI Engine на 1 ГБ.

Результат:

Время загрузки дашборда: с 4 минут до 1.2 секунд.
Счет за BigQuery: упал с $1500 до $45 в месяц.
Нервы финдиректора: полностью восстановлены.

Влияние правильной архитектуры (dbt + BI Engine) на расходы и скорость

Сравнение метрик до и после внедрения Data Lakehouse подхода для маркетингового дашборда.

Итог: Не пытайтесь обмануть физику

Looker Studio — это прекрасный, бесплатный и очень гибкий инструмент. Но это просто "глупая" витрина (Frontend). Она не умеет и не должна считать гигабайты данных. Вся тяжелая логика, джойны, очистка и агрегация должны происходить на Backend-е (в BigQuery), управляться нормальным оркестратором (dbt, Airflow или Dataform) и материализовываться в готовые таблицы.

Относитесь к данным как к программному коду. Используйте версионирование, собирайте золотые витрины, партиционируйте таблицы, и тогда ваши дашборды будут летать, а Google Cloud обойдется дешевле бизнес-ланча.

Рустам Шарафутдинов

Автор инженерного блога

Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).

Экспертность: GCP, Kubernetes, Микросервисы, React, Node.js