Розробка дашборда аналітики та звітності під ключ

Розробка дашборда аналітики та звітності

До нас прийшов проєкт: e-commerce з 50 млн рядків замовлень. Керівництво просило «один екран, де видно всі KPI». Запити до PostgreSQL лягали базу на 20 секунд. Після міграції на ClickHouse + матеріалізовані представлення дашборд відкривався за 1.2 секунди. Ми займаємося такими задачами більше п'яти років і знаємо, як обійти типові граблі.

Дашборд аналітики — інтерфейс для візуалізації бізнес-метрик у реальному часі. Розробка дашборда аналітики вимагає інтеграції кількох джерел та швидкої агрегації. Ключові вимоги: швидкість завантаження, гнучка фільтрація та коректне агрегування. Користувач не повинен чекати 30 секунд на відкриття сторінки. Нижче — типові вузькі місця та наші рішення.

Чому аналітичні дашборди гальмують?

Основна причина — важкі запити проти OLTP-бази. Наприклад, SELECT * FROM orders JOIN users ... без індексів. Результат — Timeout або load average 200. Ми вирішуємо це трьома способами: матеріалізовані представлення, окрема аналітична БД та Redis-кеш.

ClickHouse — колоночна СУБД для аналітичної обробки даних у реальному часі (ClickHouse Documentation).

Матеріалізовані представлення

CREATE MATERIALIZED VIEW daily_revenue AS
SELECT
  DATE_TRUNC('day', created_at) AS date,
  SUM(amount) AS revenue,
  COUNT(*) AS orders
FROM orders
WHERE status = 'completed'
GROUP BY 1;

CREATE UNIQUE INDEX ON daily_revenue (date);

-- Оновлення за розкладом
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;

Окрема аналітична БД: реплікація з OLTP в ClickHouse або в read-replica PostgreSQL. Усі важкі запити йдуть туди.

Кеш Redis: результати дорогих запитів кешуються з TTL 5–60 хвилин. При оновленні даних — інвалідація кешу. Така архітектура знижує навантаження на прод у 10 разів.

Як вибрати бібліотеку для візуалізації?

Вибір бібліотеки залежить від складності графіків. Для React-стека використовуємо Recharts — добре документований, кастомізація через props. Якщо потрібні heatmaps або treemap — беремо Apache ECharts (він потужніший, але важчий). Для швидких прототипів підходить Tremor — готові компоненти з Tailwind. За тестами, ECharts рендерить 10 000 точок за 200 мс, а Recharts — за 150 мс на тому ж наборі даних. Tremor поступається за продуктивністю при великих обсягах (понад 5000 точок). Типові віджети:

Як налаштувати ETL для дашборда?

ETL-процес включає кілька кроків, кожен з яких впливає на швидкість та точність даних:

1. Визначення джерел даних. Виявляємо всі необхідні таблиці, API та файли (CSV, Excel).
2. Налаштування реплікації. Використовуємо Debezium або pglogical для безперервної синхронізації з OLTP в аналітичну БД.
3. Побудова матеріалізованих представлень. Агрегуємо дані за часовими ієрархіями (день, тиждень, місяць).
4. Налаштування кешування. Результати повільних запитів зберігаємо в Redis з TTL 5–15 хвилин.
5. Моніторинг та алерти. Контролюємо затримки реплікації та споживання ресурсів.

Порівняємо ClickHouse та PostgreSQL для аналітичних навантажень:

ClickHouse в середньому в 40 разів швидший на аналітичних запитах, що підтверджується нашими проєктами з навантаженням до 1000 запитів на хвилину.

Що входить в роботу?

Ми здаємо не просто код, а повністю документоване рішення:

• Архітектурна схема з описом джерел даних та ETL-процесів
• Вихідний код дашборда (React/Next.js або Vue/Nuxt) з коментарями
• Докер-конфігурація для локального запуску та деплою
• Доступ до репозиторію та CI/CD пайплайн
• Навчання команди замовника (2–3 воркшопи)
• Гарантійна підтримка 6 місяців

Наш досвід — понад 10 проєктів дашбордів для ритейлу, фінтеху та логістики. Ми гарантуємо стабільну роботу при навантаженні до 1000 запитів на хвилину.

Фільтри та drill-down

Глобальні фільтри (період, регіон, категорія) повинні застосовуватися до всіх віджетів одночасно. Drill-down: клік по точці на графіку → деталізована таблиця по цьому зрізу.

URL повинен відображати стан фільтрів (?period=last30d&region=Kyiv) для збереження та шерінгу конкретного виду дашборда.

Експорт та шерінг

• Експорт в Excel/CSV — вивантаження даних таблиць
• Експорт в PDF — снапшот дашборда (puppeteer або print CSS) — генерація займає 5 секунд при 50 віджетах
• Scheduled reports — автоматична відправка звіту на email за розкладом
• Public URL — дашборд з readonly-доступом за посиланням (без логіну)

Терміни

MVP (5–10 віджетів, глобальні фільтри, основні джерела): 6–8 тижнів. Повноцінний дашборд з конструктором віджетів, drill-down, експортом та scheduled reports: 3–4 місяці.

Якщо потрібен дашборд, який не розвалиться під навантаженням і буде зрозумілий керівництву — зв'яжіться з нами. Оцінимо проєкт за 2 дні, дамо реалістичний план та вартість. Замовте попередню консультацію — допоможемо визначити оптимальну архітектуру.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

• GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
• Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
• GTM Preview в staging-оточенні перед продакшеном
• Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.

Що перевіряємо після кожного деплою

• Чи всі рекомендовані події присутні в DebugView
• Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
• Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Процес та терміни

1. Аудит поточних тегів та даних (2 дні)
2. Дизайн подієвої схеми (2 дні)
3. Розробка Data Layer та налаштування тегів (3–5 днів)
4. QA в Preview Mode та на staging (2 дні)
5. Деплой та налаштування дашбордів (1 день)

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.