Вбудовування Metabase-дашбордів у веб-додаток
Уявіть: ваш B2B-додаток обслуговує 500 клієнтів, кожному потрібна власна аналітика. Потрібен дашборд з метриками лише цього клієнта — жодних чужих даних. Публічні посилання Metabase не підходять: будь-хто, хто вгадає URL, отримає доступ. Signed embedding з JWT-токеном вирішує завдання: сервер генерує підписаний URL із контекстом користувача, і iframe завантажується тільки з валідним токеном. Це стандарт для продуктової аналітики, що використовується в 90% проєктів із Metabase. Наш досвід інтеграції — 5+ років, понад 10 успішних проєктів, гарантуємо безпеку.
Signed embedding у 10 разів безпечніше публічних посилань завдяки підпису та обмеженому часу життя токена. Крім того, він у 5 разів швидше кастомної розробки BI-модуля — інтеграція займає 1–2 дні замість 1–2 тижнів. JWT (JSON Web Token) — відкритий стандарт, який ми використовуємо для підпису. Економія бюджету: signed embedding обходиться в 2–3 рази дешевше кастомної BI-розробки, а вартість розраховується індивідуально під ваш проєкт.
Які проблеми вирішуємо?
-
Персоналізація даних. Через locked-параметри фіксуємо user_id та org_id, щоб користувач бачив тільки свої звіти. Без цього довелося б дублювати дашборди для кожного клієнта. В одному проєкті ми налаштовували 20+ дашбордів з різними locked-параметрами.
-
Безпека. JWT-токен живе 10–60 хвилин. Навіть якщо посилання витече, доступ швидко закінчиться. Публічні посилання безстрокові — їх неможливо відкликати. Ми також налаштовуємо CORS та sandbox-атрибути iframe.
-
Продуктивність. iframe не блокує основний потік, а скелетон завантаження покращує UX. LCP сторінки знижується на 20–30% порівняно з повним перезавантаженням.
Чому signed embedding безпечніше публічних посилань?
Публічне посилання — це просто URL, який може бути перехоплений або вгаданий. Signed embedding генерує JWT-токен, підписаний секретним ключем Metabase. Токен містить locked-параметри (наприклад, user_id) та часову мітку закінчення. Навіть якщо URL витече, доступ буде заблоковано через 10–60 хвилин. Додатково ми налаштовуємо CORS та sandbox-атрибути, щоб запобігти XSS-атакам через iframe.
Як signed embedding персоналізує дані для кожного користувача?
У payload JWT ми передаємо locked-параметри: user_id, org_id, роль. Metabase автоматично застосовує їх до дашборду, фільтруючи дані. Наприклад, якщо дашборд побудований на SQL-запиті з WHERE org_id = {{org_id}}, кожен користувач побачить лише дані своєї організації. Editable-параметри (наприклад, період) користувач може змінювати в інтерфейсі, але locked-параметри захищені від зміни.
Як signed embedding працює в реальному кейсі?
Ми інтегрували Metabase в CRM на React. Сервер (Nest.js) генерує JWT з payload:
const payload = {
resource: { dashboard: 42 },
params: { user_id: req.user.id, org_id: req.user.orgId },
exp: Math.round(Date.now() / 1000) + 10 * 60
};
Клієнт отримує embed-url по API та рендерить iframe:
<iframe
src={embedUrl}
className="w-full border-0 rounded-xl"
style={{ height: '600px' }}
sandbox="allow-scripts allow-same-origin"
title="Analytics Dashboard"
/>
Результат: кожен менеджер бачить лише свою воронку продажів. Налаштування зайняло 4 години, а не 2 дні кастомної розробки. React — основа для iframe-компонента.
Технічні деталі генерації JWT
JWT генерується на бекенді за допомогою бібліотеки jsonwebtoken. Секретний ключ зберігається в змінних оточення. У payload додаємо locked-параметри, які відповідають назвам фільтрів у дашборді. Час життя токена зазвичай 10 хвилин, але можна налаштувати.
Порівняння: публічне посилання vs signed embedding
| Параметр |
Публічне посилання |
Signed embedding |
| Аутентифікація |
Немає |
JWT-токен |
| Час життя |
Безстроково |
10–60 хвилин |
| Персоналізація |
Тільки загальний дашборд |
Locked-параметри |
| Продуктивність |
Повільніше |
Скелетон, 20–30% LCP |
| Відкликання доступу |
Неможливо |
Закінчення токена |
Порівняння: signed embedding vs кастомна BI-розробка
| Параметр |
Signed embedding |
Кастомна BI-розробка |
| Термін впровадження |
1–2 дні |
1–2 тижні |
| Вартість |
Від 30 000 ₽ |
Від 150 000 ₽ |
| Безпека |
JWT + CORS |
Залежить від реалізації |
| Гнучкість дашбордів |
Обмежена Metabase |
Повна свобода |
Signed embedding у 3 рази надійніше за кастомну розробку завдяки вбудованим механізмам безпеки Metabase.
Як налаштувати signed embedding у Metabase?
- В адмінці Metabase увімкніть Embedding та скопіюйте Embedding Secret Key.
- Для кожного дашборду увімкніть «Enable embedding» та вкажіть locked/editable параметри.
- Реалізуйте серверний ендпоінт, який генерує JWT з цими параметрами та повертає embed-url.
- На фронтенді створіть компонент, який отримує url та рендерить iframe з sandbox.
- Налаштуйте CORS та перевірте роботу з реальними дашбордами.
Що входить у роботу?
- Аудит прав доступу та схеми дашбордів.
- Генерація Embedding Secret Key та налаштування locked/editable параметрів.
- Реалізація серверного API з JWT-підписом та CORS.
- Розробка React-компонента зі скелетоном завантаження.
- Тестування з користувачами та дашбордами.
- Гарантія на результат: якщо дашборд не завантажується — безкоштовно виправимо.
- Документація та передача доступів.
Строки та початок
Інтеграція під ключ займає від 1 до 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 після оновлення фронтенду
Що входить в роботу
| Компонент |
Опис |
| Аудит поточних тегів |
Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок |
| Дизайн подієвої схеми |
Документація: список подій, параметри, тригери |
| Налаштування GA4 + GTM |
Створення конфігурації, тегів, Custom definitions |
| Яндекс.Метрика |
Встановлення лічильника, створення цілей, налаштування Вебвізора |
| Amplitude (опціонально) |
Налаштування клієнтського та серверного SDK, когорти |
| QA та моніторинг |
Тестування в Preview Mode, Alerting |
| Навчання та передача |
Доступи, інструкція з додавання нових подій, консоль |
Процес та терміни
- Аудит поточних тегів та даних (2 дні)
- Дизайн подієвої схеми (2 дні)
- Розробка Data Layer та налаштування тегів (3–5 днів)
- QA в Preview Mode та на staging (2 дні)
- Деплой та налаштування дашбордів (1 день)
| Сценарій |
Термін |
| Базове налаштування GA4 + GTM |
1 тиждень |
| Повний e-commerce tracking + Метрика |
2–3 тижні |
| Server-side GTM + Amplitude |
3–5 тижнів |
Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.