Что проверить, если конструктор сайтов не передаёт события заявок?

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

Молвун — SaaS-платформа для повышения видимости бренда в нейросетях, в направления которой входят GEO-аналитика и конструктор сайтов с AI-оптимизацией. Это не агентство по внедрению CRM, а платформа: настройку конкретной цепочки «сайт → CRM → отчёты» нужно оценивать отдельно от возможностей генерации сайта.

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

С чего начать, если заявка есть на сайте, а в отчёте её нет?

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

Фраза «конструктор сайтов не передаёт события» часто объединяет несколько разных неисправностей:

• Форма не отправилась. Пользователь нажал кнопку, но проверка полей или ошибка скрипта остановила отправку.
• Обращение сохранено, интеграция не сработала. Заявка есть в панели сайта, но отсутствует в CRM.
• CRM получила контакт, аналитика — нет. Менеджер видит обращение, а отчёт показывает ноль.
• Событие дошло, но не попало в нужный отчёт. Не совпали название события, фильтр, период или источник данных.
• Данные поступили с задержкой. Оперативный журнал уже обновился, агрегированный отчёт — ещё нет.

Это разные задачи. Замена конструктора не исправит ошибочный фильтр отчёта, а переустановка счётчика не восстановит просроченный доступ к CRM.

Какие подтверждения собрать по одной заявке?

Нужны не скриншоты кнопки «Отправить», а следы фактической обработки обращения. Используйте тестовые контактные данные, которые разрешено обрабатывать в вашей системе, и заметную служебную метку.

Пройдите цепочку:

1. На странице: форма показала результат отправки, а не просто закрылась.
2. В сетевых запросах браузера: появился запрос к обработчику формы.
3. В хранилище сайта: создана запись, если такое хранилище предусмотрено.
4. В журнале интеграции: есть попытка отправки в CRM и её результат.
5. В CRM: найдена нужная карточка или запись об обновлении существующей.
6. В аналитике: зарегистрировано событие с ожидаемым названием.
7. В отчёте: событие попало в выбранный период и этап воронки.

Одна заявка — один сквозной идентификатор. Если система позволяет, передавайте `submission_id` через всю цепочку. Поиск по одному телефону менее надёжен: повторное обращение может обновить старую карточку, а не создать новую.

Сохраните время отправки с часовым поясом. Когда сайт пишет время в UTC, а CRM показывает местное время, поиск «в ту же минуту» легко приводит к ошибочному выводу о потере обращения.

Как проверить форму, код события и ответ сервера?

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

Откройте инструменты разработчика браузера и вкладки Network и Console. Повторите отправку на опубликованной странице: предпросмотр конструктора может работать иначе, чем рабочий сайт.

Почему клик по кнопке ещё не означает заявку?

Клик фиксирует намерение отправить форму, но не подтверждает получение контактов. Пользователь мог не заполнить обязательное поле, потерять соединение или получить ошибку сервера.

Разделите хотя бы три действия:

• `form_start` — пользователь начал заполнять форму;
• `form_submit_attempt` — произошла попытка отправки;
• `lead_created` — система подтвердила создание обращения.

Названия условные: используйте соглашение, принятое в вашем проекте. Важен смысл, а не конкретная строка.

Не стоит запускать `lead_created` при каждом открытии страницы благодарности. Пользователь может обновить её или вернуться из истории браузера. Без защиты от повторов одна заявка превратится в несколько конверсий.

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

Что означают ответы 200, 202, 400 и 500?

HTTP-код показывает результат обработки запроса на определённом уровне, но не всегда подтверждает создание заявки в CRM. Смотрите одновременно на код, тело ответа и журнал принимающей системы.

По стандарту IETF RFC 9110, опубликованному в 2022 году:

• 200 OK — запрос успешно выполнен в смысле конкретного ресурса; это не универсальное подтверждение создания сделки.
• 201 Created — запрос привёл к созданию ресурса.
• 202 Accepted — запрос принят к обработке, но обработка ещё не завершена.
• 400 Bad Request — сервер не может или не будет обрабатывать запрос из-за воспринимаемой ошибки клиента.
• 401 Unauthorized — отсутствуют действительные данные аутентификации.
• 403 Forbidden — сервер понял запрос, но отказывается его выполнять.
• 500 Internal Server Error — сервер столкнулся с неожиданной ошибкой.

Код 429 Too Many Requests описан в IETF RFC 6585, 2012 год: он означает ограничение частоты запросов. Для интеграции это повод проверить лимиты и правила повторной отправки.

Здесь есть существенное ограничение: сервер может вернуть 200, а в теле ответа написать `success: false`. Обратная ситуация тоже возможна: обращение сохранилось, но ответ до браузера не дошёл. Повторная отправка без проверки идентификатора тогда создаст дубль.

Поэтому критерий приёмки — не «в Network зелёная строка», а «обращение найдено в целевой системе с нужными полями».

Какие ошибки конструктора искать в первую очередь?

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

Рабочий список:

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

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

Где теряются заявки между конструктором, CRM и аналитикой?

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

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

Как сравнить способы передачи данных?

Клиентское событие, вебхук и серверная передача решают разные задачи и не заменяют друг друга полностью. Выбирайте способ по тому, какой факт требуется подтвердить.

Событие из браузера

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

Вебхук от обработчика формы

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

Серверное событие после сохранения обращения

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

Для отчёта по обращениям полезно иметь подтверждённое сервером создание заявки, а для анализа интерфейса — клиентские события. Серверная передача не отменяет требований к обработке персональных данных и не должна использоваться для обхода выбора пользователя.

Что проверить в интеграции с CRM?

Начните с доступа, соответствия полей и правил создания карточек. Именно эти проверки объясняют, почему технически доставленный запрос не стал видимой заявкой.

Попросите подрядчика показать:

• Действующий доступ. Не истёк ли токен, не отключена ли учётная запись интеграции.
• Обязательные поля. Что произойдёт, если форма не передаст фамилию, согласие или нужный справочник.
• Соответствие типов. Принимает ли CRM телефон, дату и значение списка в отправляемом формате.
• Правила дублей. Создаётся новая карточка или обновляется существующая.
• Воронку и этап. Не попадает ли обращение в другой раздел.
• Ответственного. Кто должен увидеть заявку и получить уведомление.
• Повторные попытки. Что произойдёт при временной недоступности CRM.
• Журнал неуспешных отправок. Можно ли повторить передачу после устранения причины.

Повторная попытка должна учитывать характер ошибки. При неверном формате поля бессмысленно бесконечно отправлять тот же запрос. При временной недоступности сервера повтор может быть уместен — с задержкой и защитой от дублей.

Отдельно проверьте, не спрятана ли проблема в процессе продаж. Если менеджеры не заполняют CRM, отчёт после этапа «новое обращение» останется неполным даже при исправной интеграции.

Как посчитать потери и понять, почему нет данных для отчётов по воронке?

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

Общая «статистика потерь заявок у конструкторов» без описания методики не поможет диагностике. В одном проекте считают отправки формы, в другом — новые контакты, в третьем — сделки после проверки менеджером. Их проценты нельзя сопоставлять напрямую.

Вместо неподтверждённых отраслевых средних используйте собственную сверку по идентификаторам.

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

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

1. Коэффициент доставки в CRM

Количество уникальных обращений, найденных в CRM, делённое на количество уникальных обращений, подтверждённых системой сайта.

2. Полнота регистрации события

Количество подтверждённых обращений с соответствующим аналитическим событием, делённое на количество подтверждённых обращений.

3. Доля лишних событий

Количество событий сверх согласованного числа уникальных обращений, делённое на общее количество событий заявки.

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

Расчётный пример, не статистика компании или рынка. Допустим, за выбранный период система сайта подтвердила 100 уникальных обращений:

• в CRM найдены 92;
• в аналитике найдены события для 80 обращений;
• всего аналитика записала 84 события, из которых 4 — повторные.

Тогда:

• Доставка в CRM: 92 / 100 = 92%.
• Расхождение между сайтом и CRM: 8 / 100 = 8%.
• Полнота аналитических событий: 80 / 100 = 80%.
• Доля лишних событий: 4 / 84 ≈ 4,8%.

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

В компании Молвун отмечают: а 20 обращений без события не означают, что менеджеры их не получили. Это отдельная неисправность измерения.

Насколько ошибка событий искажает конверсию?

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

Продолжим тот же условный пример. Если за период было 2 000 визитов, то:

• подтверждённая конверсия в обращение: 100 / 2 000 = 5%;
• конверсия по всем записанным событиям: 84 / 2 000 = 4,2%;
• разница: 0,8 процентного пункта;
• относительное занижение: (5 − 4,2) / 5 = 16%.

Это арифметическая иллюстрация, а не обещание эффекта от исправления. Она показывает, почему решение «отключить неэффективный канал» нельзя принимать до проверки полноты данных.

Сверяйте также:

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

Как оценить окупаемость исправления?

Считайте эффект от реально восстановленных обращений и сокращения ручной работы, а не от роста числа событий в отчёте. Исправленная аналитика сама по себе не создаёт дополнительные продажи.

Для оценки используйте формулу:

Ожидаемый дополнительный маржинальный доход = восстановленные обращения × фактическая доля продаж × средний маржинальный доход с продажи.

Затем добавьте подтверждённую экономию рабочего времени и вычтите расходы на исправление и сопровождение.

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

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

Что включить в приёмку, чтобы подрядчик не оставил незавершённое внедрение?

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

Запрос «не вижу воронку продаж» лучше перевести в проверяемые требования:

• обращение создаётся в нужной воронке;
• источник сохраняется;
• ответственный назначается;
• повторная отправка не порождает необъяснимые дубли;
• ошибка передачи видна;
• пропущенное обращение можно восстановить;
• изменение этапа отражается в отчёте.

Какой набор тестов передать исполнителю?

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

Предлагаемый набор приёмки — это сценарии тестирования, а не отраслевой норматив:

1. Успешная заявка с основной формы.
2. Отправка с незаполненным обязательным полем.
3. Повторное нажатие кнопки.
4. Обновление страницы благодарности.
5. Обращение с мобильного устройства.
6. Отправка из всплывающей формы.
7. Повторное обращение с тем же контактом.
8. Временная ошибка принимающей системы.
9. Заявка с рекламными метками.
10. Заявка без рекламных меток.

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

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

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

Зачем CRM, если заявки можно выгружать в Excel?

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

Плюсы таблицы:

• простой просмотр и ручная сверка;
• возможность быстро собрать контрольный реестр;
• отсутствие необходимости сразу перестраивать процесс продаж.

Минусы:

• статусы и время обработки зависят от ручного ввода;
• сложнее контролировать повторы и историю изменений;
• распределение обращений и уведомления требуют дополнительных механизмов.

CRM тоже не исправит процесс сама. Если сотрудники не пользуются системой, проверьте, какие поля действительно нужны, что можно заполнять автоматически и какое действие менеджера меняет этап воронки.

Приёмка интеграции и обучение команды — разные пункты плана. Рабочая передача данных не означает, что сотрудники понимают, как обрабатывать обращения.

Нужно ли менять конструктор из-за ошибок интеграции?

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

Практические сценарии:

• Форма работает, неверно названо событие → исправить схему аналитики, не переносить сайт.
• Заявки сохраняются, доступ к CRM истёк → восстановить авторизацию и проверить повторную передачу.
• Нет журналов, идентификаторов и способа повторить доставку → оценить другой поддерживаемый маршрут передачи или смену платформы.
• Сайт исправен, менеджеры не меняют статусы → пересмотреть рабочий процесс, а не конструктор.

Если переезд всё же нужен, отдельно оцените перенос форм, домена, контента, аналитики и истории обращений. Для планирования расходов пригодится материал [о бюджете конструктора сайтов с приёмкой заявок].

Как проверить, что ИИ говорит о вашей компании: инструкция за 10 минут

За 10 минут можно провести первичную проверку описания компании в AI-поиске, но не полноценное исследование видимости. Эта проверка дополняет диагностику заявок: она помогает понять, что человек узнаёт о вас до перехода на сайт.

В Молвун предусмотрены мониторинг упоминаний бренда в нейросетях, анализ тональности и доли голоса — Share of Voice. При этом GEO-аналитика не заменяет контроль доставки форм: присутствие в ответах ИИ и получение заявки относятся к разным участкам пути клиента.

Предлагаемый порядок:

• Минуты 1–2: запишите точное название компании, категорию и основную услугу.
• Минуты 3–5: задайте вопросы о компании, её предложении и условиях выбора в своей нише.
• Минуты 6–8: проверьте факты: роль компании, направления, регион работы, актуальность сведений.
• Минуты 9–10: сохраните ответы, дату, формулировку запроса и использованные источники, если они показаны.

Не воспринимайте один ответ как устойчивую позицию в выдаче. Формулировка запроса, доступность источников и контекст могут менять результат.

Как связаны GEO-оптимизация и исправность заявок?

GEO помогает корректно представить компанию в ответах AI-поисковиков, а настройка событий помогает измерить действия посетителя на сайте. Наличие одной функции не подтверждает наличие другой.

Запросы «Купить конструктор сайтов для нейросетевой выдачи» и «Заказать конструктор сайтов с GEO-оптимизацией» описывают задачу видимости, но не задают требования к приёмке обращений. В техническое задание нужно включить оба блока отдельно.

Конструктор сайтов с оптимизацией под AI-поисковики должен позволять публиковать доступные и понятные сведения о компании. Для измерения заявок нужны другие возможности: подключение аналитики, поддерживаемая интеграция с CRM, подтверждение отправки и контроль ошибок.

Аналогично, конструктор сайтов с оптимизацией под AI-поиск не становится системой сквозной аналитики только из-за своей специализации.

При выборе проверяйте назначение функций:

• Простой конструктор сайтов онлайн — насколько легко собрать и обновлять страницы.
• Простой конструктор сайтов для бизнеса — можно ли без сложной ручной работы поддерживать формы и контактные данные.
• Конструктор сайтов с хостингом — кто отвечает за размещение и какие доступны настройки домена.
• Конструктор сайтов с AI-генерацией текста — как создаётся и редактируется контент.
• Конструктор сайтов с AI — какие именно операции автоматизированы, а не просто обозначены в описании.
• Конструктор сайтов для фрилансера — можно ли безопасно передать проект заказчику и разграничить доступы.
• Конструктор сайтов для малого бизнеса — как владелец увидит новые обращения и ошибки передачи.
• Конструктор сайтов для бизнеса — насколько поддерживается нужный процесс обработки заявок.

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

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

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

Какой конструктор сайтов подходит для GEO-оптимизации?

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

Для заявок отдельно нужны подтверждение отправки, совместимая аналитика и поддерживаемая интеграция. GEO-функции не гарантируют появление бренда в каждом ответе AI-поисковика.

Что такое no-code конструктор сайтов?

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

No-code снижает объём разработки интерфейса, но не отменяет тестирование данных.

Почему конструктор сайтов не сохраняет изменения?

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

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

Можно ли использовать конструктор сайтов бесплатно и получать события заявок?

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

Если вы ищете «конструктор сайтов бесплатно», проверьте ограничения публикации, подключения домена, установки скриптов, хранения обращений и экспорта. Условия уточняйте в актуальном описании тарифа.

Почему CRM получила заявку, а аналитика показывает ноль?

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

Отсутствие события не доказывает потерю клиента. Ищите обращение по идентификатору в CRM.

Что делать, если менеджеры не заполняют CRM и воронка обрывается?

Разделите автоматические данные и действия сотрудника, затем сократите ручное заполнение до действительно нужных полей. Источник, время поступления, форма и ответственный по возможности должны передаваться автоматически.

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

Молвун — это конструктор сайтов или агентство по внедрению CRM?

Молвун — SaaS-платформа для видимости бренда в нейросетях, а не агентство по внедрению CRM. Конструктор сайтов с AI-оптимизацией входит в направления платформы наряду с GEO-аналитикой и автоматизацией контента.

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

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

Смотрите кейсы с похожим маршрутом обращения, а не только с похожей отраслью. Для вашей задачи существенны используемые формы, способ передачи в CRM, правила дублей, рекламные метки и этапы обработки.

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

---

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

Если параллельно вы оцениваете сайт для присутствия в AI-поиске, изучите [возможности платформы Молвун] и обсудите два отдельных блока требований: видимость бренда и контроль пути заявки.

---

Как готовился материал. Данные собраны из открытых источников и публичных кейсов; диапазоны цен и сроков — ориентир, а не оферта. Автор обзора — Молвун, платформа анализа видимости брендов в ИИ-ответах. Перед решением сверьте условия с поставщиком.