Как измерить воронку «сайт → чат-бот → заявка»?

Начните с карты событий: посещение страницы, переход в чат-бот, запуск диалога, запрос на услугу и успешная отправка заявки. Затем свяжите эти события общей меткой перехода и посчитайте долю клиентов, которые дошли до следующего этапа. Такая воронка покажет, где искать причину потерь: на странице сайта, при открытии бота, внутри сценария или при передаче обращения менеджеру. Ниже разберём, как настроить учёт без сложной системы, проверить цифры и превратить переписку в список конкретных исправлений.

Какие этапы включить в воронку?

Выберите одну задачу клиента, например заявку на расчёт стоимости услуги. Покупку товара и обращение за консультацией лучше считать отдельно: у них разные сценарии и причины остановки. Для начала достаточно пути, по которому человек проходит от страницы с предложением до подтверждения заявки.

1. Посетил страницу, с которой можно перейти в бот.
2. Нажал кнопку перехода в чат-бот.
3. Запустил диалог в боте.
4. Дошёл до шага отправки заявки.
5. Получил подтверждение, что система приняла заявку.

Запишите для каждого этапа точное условие. «Заинтересовался услугой» нельзя проверить по событию, а выбор пункта «Запросить расчёт» можно. Последний этап фиксируйте после успешного приёма заявки: нажатие кнопки отправки ещё не доказывает, что обращение дошло.

Не смешивайте заявку с продажей. Если цель бота — передать запрос менеджеру, на этом заканчивается его основная воронка. Дальше можно отдельно отслеживать обработку обращения и оплату. Связка сайта, заявок и CRM помогает найти участок, на котором пропадают обращения (DZ Digital).

Перед настройкой проверьте сам маршрут: откройте страницу, перейдите в бот и отправьте тестовый запрос. По итогам у вас должен быть список событий с понятными условиями, а не только схема из стрелок.

Как связать события сайта и чат-бота?

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

Заранее уточните, когда бот получает эту метку. В зависимости от платформы она приходит при запуске диалога, а не при открытии приложения. Поэтому между нажатием кнопки на сайте и стартом бота нужен отдельный этап: человек может открыть мессенджер и так и не начать разговор.

Для рабочего отчёта хватит таблицы с полями: метка пути, источник перехода, название события и время. Если конструктор бота умеет отправлять события в систему аналитики, настройте передачу. Если нет, начните с выгрузки событий и сопоставления в таблице. Базовую картину по входам в бот, прохождению этапов и целевым действиям можно получить и без CRM (База знаний Botman).

Отдельно помечайте входы без сайта. Человек может открыть бот по сохранённой ссылке или вернуться в старый диалог. Такие обращения полезны бизнесу, но добавлять их в числитель конверсии посетителей сайта нельзя: иначе отчёт покажет переходы между разными группами людей.

Если платформа не позволяет связать путь целиком, оставьте два отчёта: переходы с сайта и прохождение сценария бота. Обозначьте границу измерения. Когда обращения уже попадают в CRM, следующий участок проверки описан в материале о том, как найти причину расхождения между заявками на сайте и CRM.

Как посчитать конверсию и выбрать место для проверки?

Конверсия этапа — доля путей, которые продолжились на следующем шаге. Чтобы её посчитать, разделите число таких переходов на число входов в предыдущий этап. Для общей конверсии разделите число успешных заявок на число посещений страницы, с которой начинается выбранный маршрут.

Используйте одну единицу учёта на всём пути. Если считаете отдельные прохождения сценария, повторные нажатия внутри одного прохождения не должны создавать новые заявки. Правило повторного входа тоже запишите заранее: когда продолжение старого диалога становится новым обращением.

Сравнивайте пути с одинаковым сроком наблюдения. Человек, который вошёл в бот в конце отчётного периода, ещё может вернуться и отправить запрос. Если сразу записать его в потери, последние дни будут выглядеть хуже без реального ухудшения сценария.

Для каждого перехода держите рядом три показателя: сколько путей дошло до этапа, сколько продолжилось и сколько остановилось. Высокая доля отказов на редком шаге и большое число остановок на массовом шаге требуют разного приоритета. Начните с участка, где теряется заметная часть потенциальных заявок и есть проверяемая причина.

Низкая конверсия сама по себе не объясняет поведение. Мало переходов с сайта — проверьте текст кнопки и обещание рядом с ней. Есть переходы, но нет запусков — откройте ссылку на телефоне. Диалог начинается, но до заявки не доходит — изучите вопросы бота и ответы пользователей. Если проблема возникает ещё до перехода, пригодится проверка мобильных страниц, где скорость мешает заявкам.

Как логи диалогов помогают объяснить потери?

Просматривайте переписку рядом с конкретным этапом остановки. Общая подборка вопросов покажет темы обращений, но для исправления воронки нужно знать, какой вопрос возник перед выходом. Запрос о сроках после выбора услуги и тот же запрос после отправки заявки относятся к разным задачам.

Составьте короткую таблицу наблюдений: этап, вопрос клиента, ответ бота, следующее действие и гипотеза исправления. Например, перед заявкой человек спрашивает, какие документы получит, а бот снова предлагает выбрать услугу. Проверьте, отвечает ли сайт на этот вопрос и предусмотрена ли такая ветка в сценарии.

Вот ещё практическая деталь: повторные вопросы о статусе заказа относятся к сопровождению покупки. Если считать их новыми заявками на продажу, отчёт покажет лишние лиды. Отделите сервисные обращения от запросов на покупку ещё при разметке тем.

Для разбора причин полезен подход, который описан в статье на chatbot.by: наблюдения из переписки нужно связывать с изменениями продукта и сценария. В вашей рабочей таблице у каждой гипотезы должна быть конкретная правка, например добавить условия оплаты перед отправкой заявки или предложить связь с менеджером после непонятного ответа.

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

Типичные ошибки: что проверить перед выводами?

• Считать клик по кнопке готовой заявкой. Исправление: фиксировать отдельное событие после успешного приёма обращения.
• Смешивать входы с сайта и прямые запуски бота. Исправление: разделить их по источнику и считать воронку для каждого маршрута.
• Принимать отсутствие события за уход клиента. Исправление: пройти маршрут вручную и проверить, приходит ли событие в отчёт.
• Сравнивать разные предложения и источники трафика одной цифрой. Исправление: сначала выделить одинаковые маршруты, затем сравнивать их конверсию.
• Оценивать сценарий только по техническим ошибкам. Исправление: проверить, получает ли человек ответ и понимает ли, что делать дальше.

Проверка работает, когда тестовый путь виден в отчёте целиком, а заявка появляется там, где её ждёт менеджер. Повторите этот тест после изменения сценария или формы. Он поможет отделить сбой учёта от реальной остановки клиента.

Если цифры сайта, бота и CRM расходятся, задача аналитического аудита — установить границы измерения и проверить передачу событий. Полезный результат такой работы можно проверить: схема воронки, словарь событий и список исправлений с приоритетами. Эти документы также дают основу для обучения сотрудника, который будет вести отчёт.

За ближайшую минуту выпишите точное условие, после которого ваша система считает обращение принятой заявкой: какое событие произошло и где его можно увидеть.