Як ми переступили через обмеження GA4 API Quotas та Looker Studio, побудувавши маркетинговий двигун на ClickHouse
Якщо ви коли-небудь відповідали за звітність маркетингової агенції або власного е-commerce, ви точно бачили цю картину: клієнт відкриває дашборд у Looker Studio, чекає
Це не баг конкретного дашборда. Це структурна межа стека Google Analytics 4 + Looker Studio, коли обсяг даних чи кількість переглядів переростають рівень одного невеликого сайту.
Три конкретні причини
1. GA4 Data API має жорсткі квоти. Для стандартної (безкоштовної) властивості Google офіційно документує:
- 200 000 токенів на добу (core tokens per day)
- 40 000 токенів на годину
- 10 одночасних запитів
(офіційна документація Google)
Звучить багато — доки у вас не з’явиться десяток клієнтських дашбордів, кожен з кількома віджетами, і кілька людей, які одночасно оновлюють звіти вранці перед плануванням. Кожен віджет у Looker Studio — це окремий виклик Data API. Дашборд із 10 графіками, відкритий трьома людьми одночасно, — це вже 30 запитів, і кожен з’їдає токени з того самого добового ліміту властивості.
2. Looker Studio не кешує дані так, як усі уявляють. GA4-конектор у Looker Studio будує запит до Data API щоразу, коли хтось відкриває звіт або змінює фільтр — фактично наживо, без власного шару кешування на стороні агенції. Це означає, що вартість (у сенсі часу й квоти) кожного перегляду лінійно множиться на кількість переглядачів.
3. BigQuery Export вирішує квоти ціною грошей і швидкості. Технічно підковані команди обходять GA4 Data API, підключаючи Looker Studio напряму до BigQuery Export — сирих подієвих даних GA4. Квоти зникають, але з’являється інша проблема: кожен запит сканує реальні байти, а платите ви за кожен просканований гігабайт, щоразу заново, бо стандартний BigQuery-конектор Looker Studio теж не кешує результати між запусками.
Ми вирішили перевірити це не на словах, а цифрами.
Архітектура: один двигун замість трьох різних болей
Ідея Vibe BI проста: дані з рекламних і аналітичних платформ (GA4, Google Ads, Meta Ads, Search Console та інші) синхронізуються один раз за розкладом у власне сховище, а не запитуються наживо щоразу, коли хтось відкриває дашборд.
Спрощена схема (без розкриття внутрішньої логіки трансформацій і мультитенантності):
[GA4 / Google Ads / Meta Ads / GSC API] │ (періодична синхронізація, dlt-пайплайн) ▼ [ ClickHouse ] ← аналітичний двигун, колонкове сховище ▲ │ SQL-запити з бекенду [ NestJS (Fastify) API ] ▲ │ REST/JSON [ Vue 3 SPA ] ← дашборди, звіти, конструктор метрик
Три принципи, які й дають різницю у швидкості:
- Дані витягуються один раз, а не на кожен перегляд. Синхронізація з зовнішнім API відбувається за розкладом (кілька разів на добу), а не в момент, коли клієнт відкриває звіт. Квоти зовнішніх API нас більше не хвилюють — ми впираємось у них рідко і контрольовано, а не при кожному кліку користувача.
- ClickHouse замість рядкової бази чи прямих запитів до API. Колонкове сховище зроблене саме для агрегацій по мільйонах рядків — групування по датах, каналах, кампаніях — це його «рідний» сценарій використання, а не побічний.
- NestJS на Fastify-адаптері — тонкий, швидкий шар між фронтендом і ClickHouse: валідація, авторизація, побудова запиту з конструктора метрик у SQL, і віддача JSON. Ніякої важкої бізнес-логіки на шляху гарячого запиту.
Ноу-хау — у деталях трансформації сирих даних під мультитенантну модель і в конструкторі метрик, і саме це залишається за кадром цієї статті.
Бенчмарк: реальні дані, не підігнаний приклад
Ми свідомо не стали малювати синтетичний «ідеальний» приклад. Замість цього взяли офіційний публічний датасет Google — BigQuery Public Dataset ga4_obfuscated_sample_ecommerce, реальний, знеособлений експорт подій інтернет-магазину Google Merchandise Store за три місяці (листопад 2020 — січень 2021): 4 295 584 сирі події.
Той самий датасет ми завантажили в ClickHouse (напряму, без API-обмежень GA4), і на обох сторонах прогнали ідентичний запит: кількість подій і сума виручки, згруповані по даті й джерелу трафіку.
| BigQuery (бекенд Looker Studio) | ClickHouse (бекенд Vibe BI) | |
|---|---|---|
| Час виконання запиту (медіана з 5 прогонів) | ~2,9 сек | ~0,27 сек |
| Дані, що скануються щоразу заново | 92 МБ на запит (cache miss щоразу) | — (локальний диск, без повторного сканування) |
| Час завантаження всього датасету (4,3М рядків) | — | 16,8 сек |
Різниця — приблизно
Важливо чесно зазначити: жоден із двох сценаріїв тут не зачіпає саме GA4 Data API Quotas (їх фізично неможливо відтворити без реального високонавантаженого GA4-акаунта під рукою) — цей бенчмарк ізолює саме питання «швидкість/вартість SQL-руху по сирих подіях». А ліміти самого GA4 Data API, описані вище, — це окрема, документована Google проблема, яка існує паралельно й незалежно від BigQuery-шляху.
Що далі
Vibe BI — не experiment на коліні: це робоча платформа з production-архітектурою й повним набором інтеграцій (GA4, Google Ads, Meta Ads, Search Console), яку я самостійно розробляю і вже перевіряю на реальних даних. Зараз я, як фаундер, свідомо шукаю перших
Якщо ви втомились підтримувати крихку звітність для клієнтів, Looker Studio, який падає під квотами, непередбачувані рахунки BigQuery або саморобні скрипти навколо GA4 API, і хочете готову інфраструктуру під власним брендом — пишіть: [email protected], або спершу подивіться наживо на vibe-bi.com.ua (публічна Metric Gallery, без реєстрації).
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів