Встраивание Metabase-дашбордов в веб-приложение: signed embedding

Встраивание 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-компонента.

Сравнение: публичная ссылка vs signed embedding

Сравнение: signed embedding vs кастомная BI-разработка

Как настроить signed embedding в Metabase?

1. В админке Metabase включите Embedding и скопируйте Embedding Secret Key.
2. Для каждого дашборда включите «Enable embedding» и укажите locked/editable параметры.
3. Реализуйте серверный эндпоинт, который генерирует JWT с этими параметрами и возвращает embed-url.
4. На фронтенде создайте компонент, который получает url и рендерит iframe с sandbox.
5. Настройте 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 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 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: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-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 день)

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.