Клик есть, заявки нет: где теряются клиенты между сайтом и Telegram-ботом
Например, в отчёте по сайту нажатия на кнопку «Написать в Telegram» есть, в боте стартов заметно меньше, а карточек у менеджера ещё меньше. Дальше начинается спор о том, кто виноват: сайт, Telegram, подрядчик, собиравший бота, или менеджер, который «опять не ответил». Спор бессмысленный, потому что его участники смотрят на разные события и называют их одним словом — «заявка».
Клик по кнопке мессенджера не обращение и не лид. Это начало маршрута, на котором заявка появляется только после нескольких последовательных шагов: переход по ссылке, запуск бота, первое сообщение, фиксация данных, передача лида ответственному. Пока эти шаги не разделены, понять, где теряются люди, нельзя.
Почему клик ещё не равен обращению
Сайт подтверждает только то, что произошло на сайте. Яндекс Метрика умеет считать клики по кнопкам, переходы по внешним ссылкам и открытие мессенджера — это отдельные типы целей. Но все они фиксируют действие на странице, а не факт, что человек открыл Telegram, нажал «Запустить» и отправил сообщение. Переход на домен, отличный от домена сайта, Метрика видит как внешнюю ссылку, и на этом её зона ответственности заканчивается. Если считать конверсию лендинга по такому клику, цифра получится завышенной.
Дальше начинается территория Telegram. Ссылка вида https://t.me/company_bot?start=landing_top` передаёт боту параметр, и при запуске он получает команду /start landing_top`. В параметр можно положить до 64 символов в формате base64url — хватит на метку страницы, кнопки или рекламной кампании. Удобная разметка, но не сквозная аналитика: параметр лишь помогает боту понять, откуда пришёл человек, и ничего не говорит о том, что дальше всё пошло по плану.
Получение сообщения — тоже отдельная операция. Бот забирает обновления через webhook или метод getUpdates, а отвечает отдельным вызовом, например sendMessage. Принять сообщение и ответить на него — разные действия, и между ними возможны сбои. Telegram хранит входящие обновления на своей стороне, но не бесконечно: не более 24 часов. Если обработчик в это время не забирал обновления, после истечения этого срока они могут стать для него недоступны — и часть обращений не попадёт в обработку.
Где рвётся маршрут
Первый участок — сам сайт. Стоит проверить, что каждая кнопка ведёт на актуальную ссылку и что переход срабатывает на телефоне и на компьютере. Человек мог отвлечься, закрыть вкладку или не дойти до запуска бота — клик остался кликом, а заявки здесь ещё нет. Метрика его честно посчитала, но обращением он не стал.
Дальше начинается переход и запуск бота. Без специальной метки start ссылка не передаёт боту заданный идентификатор источника: страницы, кнопки или рекламной кампании. С метками уже можно сравнивать, сколько реальных запусков дала верхняя кнопка лендинга, а сколько — блок с ценами.
Потом эстафету принимает обработчик бота. Смотреть здесь стоит не на красивый интерфейс, а на журнал входящих обновлений и ошибки доставки: при ошибках обновления могут оставаться на стороне Telegram, а в Bot API доступны сведения о числе ожидающих обновлений и последней ошибке доставки. Утверждать «Telegram потерял заявку» без проверки логов нельзя — причина с равной вероятностью может быть в ссылке, в коде бота или в интеграции.
И последний участок — передача менеджеру. Лид создан, данные записаны, а уведомление не ушло: интеграция отвалилась, чат с ответственным сменился, сообщение попало в папку, которую никто не читает. Формально заявка есть, фактически её нет. Именно так и появляются потерянные лиды — не из-за мистики, а из-за разрыва на одном конкретном стыке.
Минимальная диагностика без сложной CRM
Для первого замера тяжёлая система не нужна. Достаточно развести шесть событий и посмотреть, сколько людей дошло до каждого:
messenger_click— нажатие кнопки на сайте, его подтверждает Метрика;telegramlinkclick— клик по внешней ссылке на бота; сайт подтверждает клик или переход по ссылке, но не факт, что Telegram открылся;bot_start— получение/start, подтверждает бот;first_message— первое сообщение пользователя; это событие бизнес определяет сам — любое первое сообщение или первое содержательное по заданному правилу; подтверждает бот;lead_created— зафиксированы нужные для работы данные;manager_notified— уведомление или карточка переданы ответственному.
Дальше картина становится предметной. Предположим, на сайте 100 кликов, в боте 63 запуска, первое сообщение отправил 51 человек, данные оставили 18, менеджеру передано 16 карточек. Это не статистика конкретного бизнеса и не типичная картина, а иллюстрация логики: каждый переход показывает свой участок потерь, и лечить нужно именно его, а не «конверсию в Telegram» целиком. Провал между кликом и запуском — смотрите ссылку и мобильный сценарий. Провал между запуском и первым сообщением — читайте сценарий бота. Провал между данными и карточкой — проверяйте интеграцию.
UTM-метки при этом полезны, но не всесильны: они размечают источник перехода, однако сами по себе не создают лид и не гарантируют, что метка сохранится внутри мессенджера. Для Telegram надёжнее связка «параметр start плюс запись события в базе бота».
Что проверить в первую очередь
Начать стоит с ручной проверки ссылки: открыть её с телефона, где Telegram установлен, и с компьютера, где его может не быть, а потом сверить, какая ссылка стоит на каждой кнопке и совпадает ли она с той, что вы тестируете. Следующий шаг — разные метки start для разных кнопок и страниц: это дешевле и быстрее, чем сразу строить сквозную аналитику.
Потом стоит сопоставить цель в Метрике с логами входящих обновлений бота: сходится ли число запусков, нет ли ошибок доставки. Отдельно проверяется, отвечает ли бот на /start, создаётся ли запись после первого сообщения и приходит ли уведомление менеджеру. И ещё один сценарий, который обычно забывают: человек закрыл чат на середине — сохранились ли данные и можно ли к нему вернуться.
Искать нужно не виноватого, а первый этап, на котором число подтверждённых событий резко падает. Иногда это одна кривая ссылка, иногда отсутствие ответа на первое сообщение, иногда уведомление, которое уходит в никуда.
Измеримая цепочка вместо разовой проверки
Разовая диагностика показывает, где рвётся маршрут сегодня, но не защищает от повторения. Дальше нужна регулярная схема, в которой каждое событие фиксируется отдельно и связывается с конкретным лидом. В Market-GPT такой путь проектируется как измеримая цепочка до реального лида. Это не обещание «полной защиты от потерь», а подход: считать не клики и не старты по отдельности, а весь маршрут целиком.
По-моему, главная ошибка здесь не техническая, а терминологическая. Команда называет заявкой то, что ею не является, а потом удивляется расхождению в цифрах. Как только клик, запуск бота, первое сообщение и созданный лид получают разные имена и разных ответственных, спор о виноватом превращается в обычную рабочую задачу.
Надёжная аналитика начинается не с дорогой CRM, а с честного разделения событий между сайтом, ботом и менеджером. Пока каждый этап не подтверждён отдельно, бизнес видит только общую цифру и не может понять, где именно теряются деньги — между интерфейсами, где каждая система считает успех по-своему.
