«У нас 10 000 подписчиков в боте» - не метрика, а vanity-цифра. Реальный вопрос - сколько денег приносит бот и где узкое место. Эта статья - разбор 12 ключевых метрик чат-бота с формулами, SQL-запросов для дашбордов в Grafana, A/B-инфраструктуры и реальных кейсов расчёта ROI. Без воды про «синергию data-driven подхода» - только конкретика.
TL;DR: аналитика чат-бота в одной таблице
| Метрика | Норма | Что значит |
|---|---|---|
| Time-to-first-response | < 5 сек | Скорость ответа бота на первое сообщение |
| Fallback rate | 5-15% | % сообщений «не понимаю» |
| Escalation rate | 10-30% | % диалогов, ушедших к оператору |
| Lead-to-call conversion | 7-25% | % лидов, дошедших до звонка |
| Call-to-deal conversion | 20-40% | % звонков в сделку |
| Customer satisfaction (CSAT) | 70-85% | Опрос «бот помог?» |
| Cost per dialog | 1-10 ₽ | Себестоимость одного диалога |
| Repeat rate | 25-40% | % пользователей с 2+ диалогами |
| Retention 30/60/90 дней | 40/25/15% | % возвращений через N дней |
| Hallucination rate (AI) | < 1% | % выдуманных фактов |
| Average dialog length | 3-7 сообщений | Длина типового диалога |
| ROI | 100-500% | (Прибыль - затраты) / затраты × 100% |
12 ключевых метрик чат-бота с формулами
1. Time-to-first-response
Сколько секунд с момента сообщения клиента до ответа бота. Критично для конверсии.
SELECT
AVG(EXTRACT(EPOCH FROM (bot_response_at - user_message_at))) as avg_seconds_p50
FROM bot.dialogs
WHERE created_at >= NOW() - INTERVAL '24 hours';Норма: менее 5 секунд для rule-based ботов, 1-3 секунды для AI-ботов с RAG. Проблема: более 10 секунд - клиент думает, что бот завис, уходит к конкурентам.
2. Fallback rate
Доля сообщений, на которые бот ответил «не понимаю» или «передам оператору».
SELECT
COUNT(*) FILTER (WHERE fallback = true) * 100.0 / COUNT(*) as fallback_pct
FROM bot.messages
WHERE created_at >= NOW() - INTERVAL '7 days';Норма: 5-15%. Выше - бедная база знаний или слишком высокий threshold в RAG. Падение: если стало 30%+ - срочно проверить базу знаний, возможно изменения в продукте не отражены.
3. Escalation rate
Доля диалогов, которые в итоге дошли до живого оператора.
Норма: 10-30%. В медицине и финансах - 30-50% (сложные кейсы). В FAQ-ботах - 5-10%. Высокое: значит бот закрывает мало кейсов, либо клиенты сразу просят оператора (триггер на слова «человек», «оператор»).
4. Lead-to-call conversion
Процент лидов, дошедших до звонка с менеджером.
SELECT
COUNT(DISTINCT user_id) FILTER (WHERE event = 'call_scheduled') * 100.0
/ COUNT(DISTINCT user_id) FILTER (WHERE event = 'lead_created') as conv_pct
FROM bot.events
WHERE created_at >= NOW() - INTERVAL '30 days';Норма: 7-25%, зависит от ниши. В B2B - 10-15%, в инфобизе - 15-25%. Низкое: значит квалификация плохая или CTA в боте слабый. Тестируем тексты приглашения на звонок через A/B.
5. Call-to-deal conversion
Процент звонков, перешедших в сделку. Это уже метрика менеджера, не бота, но без неё не посчитать ROI.
Норма: 20-40% для B2B, 30-50% для B2C. Низкое: либо менеджер слабый, либо квалификация бота плохая (передаёт не тех лидов).
6. Customer satisfaction (CSAT)
В конце диалога - rule-based опрос «бот помог?» с 5-балльной шкалой.
SELECT
AVG(satisfaction_score)::numeric(3,1) as csat_avg,
COUNT(*) FILTER (WHERE satisfaction_score >= 4) * 100.0 / COUNT(*) as csat_pct
FROM bot.feedback
WHERE created_at >= NOW() - INTERVAL '30 days' AND satisfaction_score IS NOT NULL;Норма: 70-85% оценок 4-5 баллов. Низкое: возможно бот часто фейлится, опрос показывает на проблемные сценарии.
7. Cost per dialog
Себестоимость одного диалога с учётом LLM-токенов, инфраструктуры, поддержки.
Формула: (LLM costs + VPS + support cost) / total dialogs
Норма: 1-10 ₽ за диалог в большинстве проектов. Высокое (50+ ₽): значит либо платите за GPT-4o full при том что хватит mini, либо много fallback’ов с повторными запросами в LLM.
8. Repeat rate
Процент пользователей с 2+ диалогами за период.
Норма: 25-40%. Низкое - пользователи не возвращаются, бот не закрывает их потребности повторно. Высокое (60%+): хорошо для retention, но проверьте что это не одни и те же люди задают одни и те же вопросы (тогда база знаний слабая).
9. Retention 30/60/90 дней
Из пользователей, написавших боту 30/60/90 дней назад, сколько вернулись сегодня.
Норма: 40/25/15% соответственно. Тренд: ключевая бизнес-метрика. Если retention падает - продукт слабеет.
10. Hallucination rate (для AI-ботов)
Процент ответов, содержащих выдуманные факты, цены, обещания. Ручная проверка 50-100 случайных диалогов в неделю.
Норма: менее 1%. На некоторых нишах (медицина, финансы) - менее 0.1%. Высокое: срочный фикс - усилить system-prompt, добавить валидацию, перейти на RAG.
11. Average dialog length
Среднее количество сообщений в диалоге до closure (либо решение, либо escalation).
Норма: 3-7 сообщений. Короче - бот не вытащил контекст; длиннее - запутывается. Тренд: при росте hallucination rate обычно растёт и длина диалога (бот «вьётся»).
12. ROI чат-бота
Главная метрика. Без неё всё остальное теряет смысл.
Формула:
ROI = (экономия операторов + дополнительная выручка) / затраты на внедрение и поддержку × 100%Расчёт:
- Экономия операторов: (часы освобождённые × ставка часа × 22 рабочих дня)
- Дополнительная выручка: (доп. сделки × средний чек × маржа)
- Затраты: (стоимость внедрения / amortization 12 мес + поддержка × месяцев + токены LLM)
Норма: 100-500% за первый год. Меньше 50% - бот не оправдывает себя, нужна оптимизация.
Дашборды: что показывать, где собирать
Минимальный стек:
- Postgres - логирование всех событий (
bot.dialogs,bot.messages,bot.events,bot.feedback) - Grafana или Metabase - дашборды
- cron - материализованные представления для быстрой отрисовки
Схема БД
CREATE SCHEMA bot;
CREATE TABLE bot.dialogs (
id BIGSERIAL PRIMARY KEY,
user_id TEXT NOT NULL,
started_at TIMESTAMPTZ NOT NULL,
closed_at TIMESTAMPTZ,
closure_reason TEXT, -- resolved | escalated | abandoned
messages_count INT NOT NULL DEFAULT 0,
fallback_count INT NOT NULL DEFAULT 0
);
CREATE TABLE bot.messages (
id BIGSERIAL PRIMARY KEY,
dialog_id BIGINT NOT NULL REFERENCES bot.dialogs(id),
sender TEXT NOT NULL, -- user | bot
text TEXT,
fallback BOOLEAN DEFAULT FALSE,
response_time_ms INT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE TABLE bot.events (
id BIGSERIAL PRIMARY KEY,
dialog_id BIGINT REFERENCES bot.dialogs(id),
user_id TEXT NOT NULL,
event TEXT NOT NULL, -- lead_created | call_scheduled | meeting_held | deal_closed
metadata JSONB,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE TABLE bot.feedback (
id BIGSERIAL PRIMARY KEY,
user_id TEXT NOT NULL,
dialog_id BIGINT REFERENCES bot.dialogs(id),
satisfaction_score SMALLINT, -- 1-5
feedback_text TEXT,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX ON bot.messages (created_at DESC);
CREATE INDEX ON bot.dialogs (started_at DESC);
CREATE INDEX ON bot.events (created_at DESC, event);Материализованные представления для скорости
Дашборды на больших объёмах тормозят. Решение - материализованные view, которые обновляются раз в час cron-задачей.
CREATE MATERIALIZED VIEW bot.daily_kpi AS
SELECT
date_trunc('day', d.started_at) AS day,
COUNT(*) AS total_dialogs,
COUNT(*) FILTER (WHERE d.closure_reason = 'escalated') * 100.0 / COUNT(*) AS escalation_pct,
AVG(d.messages_count) AS avg_messages,
COUNT(DISTINCT d.user_id) AS unique_users
FROM bot.dialogs d
WHERE d.started_at >= NOW() - INTERVAL '90 days'
GROUP BY 1;
CREATE UNIQUE INDEX ON bot.daily_kpi (day);Cron:
0 * * * * psql -c "REFRESH MATERIALIZED VIEW CONCURRENTLY bot.daily_kpi;"Чего НЕ должно быть на дашборде
- Total messages - vanity-метрика, ничего не говорит
- Unique active users без сегментации - слишком общая
- Average response time без p95/p99 - средняя скрывает выбросы
Что должно быть:
- Тренды по дням (fallback, escalation, conversion)
- Топ-5 самых частых fallback-вопросов (для улучшения базы знаний)
- Воронка lead → call → deal с конверсиями
- Метрики по сегментам (новички vs возвратники, по нише, по бюджету)
- Алерты (red flag при превышении нормы)
A/B-тесты: инфраструктура и подход
Без A/B-тестов нельзя сказать «какая версия лучше». Минимум - 200 пользователей на ветку, длительность 1-2 недели.
Минимальная схема
ALTER TABLE bot.dialogs ADD COLUMN variant TEXT DEFAULT 'baseline';Распределение в коде:
def get_variant(user_id: str, experiment: str) -> str:
h = int(hashlib.md5(f"{user_id}:{experiment}".encode()).hexdigest(), 16)
return 'A' if h % 2 == 0 else 'B'Анализ:
SELECT
variant,
COUNT(*) AS dialogs,
COUNT(*) FILTER (WHERE closure_reason = 'resolved') * 100.0 / COUNT(*) AS success_pct,
AVG(messages_count) AS avg_msg
FROM bot.dialogs
WHERE started_at BETWEEN '2026-05-01' AND '2026-05-14'
GROUP BY variant;Что тестировать
Первое касание - текст приветствия, кнопки vs свободный ввод. Промпт LLM - формулировка system-prompt для AI-классификации. Время отправки - утром vs вечером. CTA в конце - «записаться на звонок» vs «получить КП на email». Threshold RAG - 0.65 vs 0.75 для отсечения нерелевантных чанков.
Статистическая значимость
Используем Bayes A/B-калькулятор или z-test. Решение принимается если p < 0.05 и абсолютная разница > 5%.
Каждая 4-я гипотеза по нашей практике побеждает baseline. Без A/B вы теряете 30-50% потенциала бота.
Реальные кейсы расчёта ROI
Кейс 1. Онлайн-школа: ROI 380% за первый год
Школа со средним чеком 50 000 ₽, поток 300 лидов в месяц.
До бота:
- Менеджер закрывает 4% лидов = 12 сделок/мес
- Выручка 600 000 ₽, маржа 40% = 240 000 ₽/мес
После AI-квалификации (120 000 ₽ внедрения, 15 000 ₽/мес поддержки):
- Конверсия 7% = 21 сделка/мес
- Выручка 1 050 000 ₽, маржа 40% = 420 000 ₽/мес
- Дополнительная маржа: +180 000 ₽/мес
ROI за 12 месяцев:
- Затраты: 120 000 + 15 000 × 12 = 300 000 ₽
- Доп. маржа: 180 000 × 12 = 2 160 000 ₽
- ROI = (2 160 000 - 300 000) / 300 000 × 100% = 620%
Кейс 2. Контакт-центр e-commerce: окупаемость 6 недель
5000 запросов в день, ставка оператора 70 000 ₽/мес.
До бота: 25 операторов = 1 750 000 ₽/мес
После AI-бота поддержки (250 000 ₽ внедрения, 30 000 ₽/мес LLM-токены + поддержка):
- Бот закрывает 60% = 15 операторов хватит
- Экономия: 10 × 70 000 = 700 000 ₽/мес
Окупаемость:
- 250 000 / 700 000 = 0.36 мес = ~6 недель
ROI за год:
- Затраты: 250 000 + 30 000 × 12 = 610 000 ₽
- Экономия: 700 000 × 12 = 8 400 000 ₽
- ROI = (8 400 000 - 610 000) / 610 000 × 100% = 1277%
Кейс 3. Клуб по подписке: rebought rate +30%
Клуб на 500 участников, чек подписки 1 500 ₽/мес.
До бота: retention 30 дней = 70%, выручка 525 000 ₽/мес
После бота с проактивными касаниями (90 000 ₽ внедрения, 12 000 ₽/мес поддержки):
- Retention 30 дней = 84% (+30% удержаний)
- Выручка 630 000 ₽/мес = +105 000 ₽/мес
ROI за год:
- Затраты: 90 000 + 12 000 × 12 = 234 000 ₽
- Дополнительная выручка: 105 000 × 12 = 1 260 000 ₽
- ROI = (1 260 000 - 234 000) / 234 000 × 100% = 438%
Главные ошибки аналитики чат-бота
1. Считают только подписчиков и сообщения. Vanity-метрики. Реальный вопрос - сколько денег принёс бот.
2. Нет логирования событий. Через 3 месяца хотите посчитать конверсию - данных нет. Минимум - таблица events с момента запуска.
3. Дашборд без алертов. Fallback rate вырос с 10 до 30% - никто не заметил неделю. Алерты в Telegram или email при превышении нормы.
4. A/B-тесты «на глазок». «Кажется, B лучше» - без размера выборки и p-value - это случайные вариации, не данные.
5. Игнор сегментации. Общая конверсия 5%, по сегментам - 15% и 1%. Без сегментной аналитики не видно где деньги.
6. Метрики ради метрик. 50 метрик на дашборде = ноль действий. 10 ключевых с понятной интерпретацией - управляемая система.
7. Не считают ROI. Без ROI нет решения - продолжать развивать или отказаться от инициативы.
Часто задаваемые вопросы
Какие метрики самые важные?
Top-3: ROI, fallback rate, lead-to-call conversion. Если выбирать одну - ROI, потому что она агрегирует всё.
Через сколько начинает быть видна реальная картина?
Минимум 2-3 недели на потоке 500+ диалогов в неделю. Меньше - случайные вариации.
Можно ли использовать встроенную аналитику Salebot/BotHelp?
Базовые метрики - да (отправлено, прочитано, кликнуто). Воронка lead → deal и ROI - нужна отдельная аналитика в Postgres.
Сколько стоит настроить аналитику?
От 30 000 ₽ за базовый дашборд с 5-7 метриками до 150 000 ₽ за полную систему с A/B-инфраструктурой и алертами.
Чем Grafana отличается от Metabase?
Grafana лучше для метрик во времени (тренды, ряды). Metabase удобнее для бизнес-аналитики с фильтрами и drill-down. На одной БД можно использовать обе.
Как часто пересматривать метрики?
Ежедневно (через дашборд), еженедельно (drill-down по проблемным метрикам), ежемесячно (полный ретроспектив + новые A/B).
Что делать, если ROI отрицательный?
Сначала найти причину: высокий cost per dialog (заменить LLM на mini), низкая конверсия (фиксить промпт), много fallback (улучшать базу). Если за 3 месяца не вышли в плюс - возможно, бот не нужен в этой нише.
Можно ли подключить аналитику бота к Power BI / Tableau?
Да. Postgres → ODBC → Power BI / Tableau. Но Grafana/Metabase в 95% случаев хватает.
Как мерить ROI AI-агентов?
Особенность - кроме операционной экономии и доп.выручки добавляется метрика «количество автономно выполненных задач × ставка специалиста, которая раньше это делала». В разработке - тоже считаем по сэкономленным часам разработчика.
Что если данных мало (стартап)?
Аналитика всё равно нужна с первого дня - даже на 50 диалогах в неделю собирайте логи. Через 2-3 месяца будет на чем считать.
Готовы обсудить вашу задачу?
Если эта статья откликнулась - у вас сейчас одна из трёх ситуаций:
- Бот уже работает, но непонятно эффективен ли. Сделаем аудит метрик за 3-5 рабочих дней с рекомендациями. Цена 30-50к ₽, возвращается с первой оптимизации.
- Запускаете нового бота и хотите сразу с аналитикой. Включим в архитектуру логи + дашборд + A/B. Дополнительно к стоимости бота +20-50к.
- Уже есть бот без аналитики. Подключим Postgres-логирование и Grafana-дашборд. 30-80к, срок 1-2 недели.
📱 Telegram @viktdo - отвечаю в течение часа в будни 📝 Форма обратной связи 👀 Кейсы
О нас: BotKraft - студия чат-ботов и автоматизации (5 лет, 300+ проектов, ИНН 701718749598). Стек: Salebot / BotHelp / n8n / Python aiogram + Postgres / Grafana / Metabase для аналитики.