Kommo + Metabase: аналитика и дашборды по данным CRM без выгрузки в Excel

Встроенная аналитика Kommo покрывает базовое: конверсия по воронке, количество сделок по этапам, выручка за период. Как только нужен кастомный отчёт — «сколько времени сделка проводит на каждом этапе», «конверсия по источникам лидов», «активность менеджеров в разрезе типов задач» — команда выгружает данные в Excel и строит сводные таблицы вручную. Это медленно, не обновляется в реальном времени и требует постоянного ручного труда.

Metabase — open-source BI-инструмент, который позволяет строить дашборды на живых данных. Интеграция с Kommo через промежуточную базу данных даёт аналитику в реальном времени без Excel и без ограничений встроенных отчётов.

Почему встроенная аналитика Kommo не хватает

Kommo предоставляет раздел «Аналитика» со стандартными отчётами:
— Сводный отчёт: количество сделок, сумма, конверсия по воронке
— Отчёт по сотрудникам: сделки и задачи на менеджера
— Отчёт по звонкам: количество и длительность
— Цели: план/факт по выручке

Этого не хватает когда:
— Нужен отчёт в разрезе кастомных полей (источник лида, тип клиента, регион)
— Нужно время жизни на этапе (как долго сделка висит в «Переговорах»)
— Нужна когортная аналитика (лиды из января — сколько закрылось к марту)
— Нужны комбинированные отчёты: активность менеджера + конверсия по его сделкам
— Дашборд должен обновляться автоматически и быть виден всей команде или борду

Архитектура интеграции Kommo -> Metabase

Metabase не подключается напрямую к Kommo API — он работает с реляционными базами данных (PostgreSQL, MySQL, ClickHouse и другие). Нужен промежуточный слой: ETL-пайплайн, который регулярно выгружает данные из Kommo API в БД, а Metabase строит дашборды на этой БД.

Kommo API
  ↓ (ETL, каждые 15–60 минут)
PostgreSQL / ClickHouse
  ↑
Metabase (дашборды, SQL-вопросы, алерты)

Что выгружается из Kommo:
— /api/v4/leads — сделки со всеми полями, включая кастомные
— /api/v4/contacts — контакты
— /api/v4/events — история изменений (смены этапов, ответственных)
— /api/v4/tasks — задачи (выполненные и открытые)
— /api/v4/users — менеджеры
— /api/v4/pipelines — воронки и этапы (справочник)

Схема базы данных

Для аналитики CRM достаточно нескольких таблиц:

CREATE TABLE leads (
  id          BIGINT PRIMARY KEY,
  name        TEXT,
  price       INTEGER,
  status_id   INTEGER,
  pipeline_id INTEGER,
  created_at  TIMESTAMP,
  updated_at  TIMESTAMP,
  closed_at   TIMESTAMP,
  responsible_user_id INTEGER,
  loss_reason TEXT,
  -- кастомные поля (денормализованы для простоты запросов)
  source      TEXT,
  client_type TEXT,
  region      TEXT
);

CREATE TABLE lead_status_history (
  id          BIGSERIAL PRIMARY KEY,
  lead_id     BIGINT,
  from_status INTEGER,
  to_status   INTEGER,
  changed_at  TIMESTAMP,
  changed_by  INTEGER
);

CREATE TABLE tasks (
  id          BIGINT PRIMARY KEY,
  lead_id     BIGINT,
  task_type   INTEGER,
  created_at  TIMESTAMP,
  completed_at TIMESTAMP,
  responsible_user_id INTEGER
);

Таблица lead_status_history — ключевая для time-on-stage аналитики: из неё считается, сколько времени сделка провела на каждом этапе.

Примеры дашбордов в Metabase

Время на этапе (SQL-вопрос):

SELECT
  p.name AS pipeline_name,
  s.name AS stage_name,
  AVG(EXTRACT(EPOCH FROM (h.next_change - h.changed_at)) / 3600) AS avg_hours
FROM lead_status_history h
JOIN pipelines p ON h.pipeline_id = p.id
JOIN stages s ON h.to_status = s.id
WHERP h.changed_at > NOW() - INTERVAL '90 days'
GROUP BY 1, 2
ORDER BY 1, avg_hours DESC

Конверсия по источникам:

SELECT
  source,
  COUNT(*) AS total,
  COUNT(*) FILTER (WHERE status_id = 142) AS won,
  ROUND(100.0 * COUNT(*) FILTER (WHERE status_id = 142) / COUNT(*), 1) AS win_rate
FROM leads
WHERE created_at > NOW() - INTERVAL '6 months'
GROUP BY source
ORDER BY win_rate DESC

Активность менеджеров:

SELECT
  u.name AS manager,
  COUNT(t.id) AS tasks_completed,
  COUNT(DISTINCT t.lead_id) AS deals_touched,
  AVG(l.price) FILTER (WHERE l.status_id = 142) AS avg_won_deal
FROM tasks t
JOIN users u ON t.responsible_user_id = u.id
JOIN leads l ON t.lead_id = l.id
WHERE t.completed_at > NOW() - INTERVAL '30 days'
GROUP BY u.name

Metabase строит визуализацию из любого SQL-запроса: таблица, бар-чарт, линейный график, funnel, scatter plot. Дашборд из 6–8 вопросов собирается за несколько часов после настройки ETL.

Metabase vs Power BI, Looker, Google Data Studio

Metabase Community Edition — бесплатен и self-hosted. Для небольших команд это оптимальный выбор: разворачивается на любом VPS за 30 минут (Docker), не требует лицензий.

Если компания уже использует Power BI — схема интеграции аналогична. Подробнее в статье о интеграции Kommo и Power BI.

ETL: частота обновления и инкрементальная загрузка

Полный перезалив базы при каждом обновлении неэффективен при больших объёмах. Правильный подход — инкрементальная загрузка:

# Читаем только изменённые с последнего обновления
last_updated = get_last_sync_timestamp()
leads = kommo_api.get_leads(
    updated_from=int(last_updated.timestamp())
)
upsert_leads(leads)  # INSERT ... ON CONFLICT DO UPDATE
save_sync_timestamp(now())

Для таблицы lead_status_history — отдельная логика: читаем события из /api/v4/events?filter[type]=lead_status_changed с фильтром по дате.

Частота обновления:
— Оперативные дашборды (сегодня, эта неделя) -> каждые 15–30 минут
— Стратегические отчёты (квартал, год) -> раз в час или раз в день

Реальный кейс

Для дистрибьюторской компании (4 воронки, 12 менеджеров, 300+ сделок в месяц):
— До интеграции: еженедельный Excel-отчёт готовился 3–4 часа, данные на момент презентации уже устаревали на 1–7 дней
— После: дашборд Metabase обновляется каждые 30 минут, виден всем руководителям по ссылке
— Ключевые метрики на дашборде: конверсия по этапам, время на этапе, активность менеджеров, выручка по регионам
— Обнаруженный инсайт через неделю после запуска: сделки из одного источника (партнёрский канал) конвертировались в 2.3 раза хуже при одинаковом среднем чеке — маркетинг не знал об этом

Для кого актуально

Интеграция Kommo + Metabase имеет смысл если:
— Нужны кастомные отчёты, которых нет во встроенной аналитике Kommo
— Дашборд должен обновляться автоматически и быть доступен руководителям без CRM-доступа
— Нужна time-on-stage аналитика или когортный анализ лидов
— Команда ценит open source и не хочет платить за BI-лицензии

Часто задаваемые вопросы

Metabase Community Edition бесплатен навсегда?

Да. Community Edition — полностью бесплатный, MIT-лицензия, self-hosted. Платный Pro ($500/мес) добавляет SSO, расширенные права доступа, аудит логов и embedding без брендинга Metabase. Для внутреннего использования Community достаточно.

Какая БД лучше для хранения данных из Kommo: PostgreSQL или ClickHouse?

До 5 миллионов событий — PostgreSQL с индексами справляется отлично. При больших объёмах или аналитических запросах с GROUP BY по десяткам миллионов строк — ClickHouse значительно быстрее. Для большинства Kommo-аккаунтов (до 100,000 сделок) PostgreSQL — правильный выбор.

Насколько сложно развернуть Metabase?

Docker: docker run -p 3000:3000 metabase/metabase — и через 2 минуты Metabase доступен по localhost. Настройка подключения к БД, создание первого дашборда — ещё час. Это один из самых простых в развёртывании BI-инструментов.

Можно ли встроить дашборды Metabase в другие сервисы?

Да. Metabase поддерживает embedding через iframe — можно встроить дашборд в Notion, внутренний портал или отправлять по ссылке без необходимости логина (signed embedding). В Pro-версии — embedding без брендинга Metabase.

Итого

• Встроенная аналитика Kommo не покрывает кастомные отчёты и time-on-stage метрики
• Metabase подключается к PostgreSQL, куда ETL-пайплайн выгружает данные из Kommo API
• Инкрементальная загрузка каждые 15–30 минут — оперативные дашборды без перегрузки API
• Metabase Community Edition бесплатен; разворачивается за 30 минут на любом VPS
• Типовой срок разработки ETL + базовый набор дашбордов — 3–4 недели

Если вы хотите видеть аналитику по воронке Kommo в реальном времени без Excel — опишите, какие отчёты нужны. Exceltic.dev оценит объём данных и предложит конкретную схему.