Как настроить формы и аналитику в Zero Block на Тильде, чтобы заявки падали в CRM без дублей?

Zero Block даёт полный контроль над вёрсткой, но ломает стандартный механизм форм Tilda: обработчик, привязанный к блоку BF, не видит кастомные поля и кнопки внутри Zero Block. Из-за этого заявки либо не уходят в CRM, либо уходят повторно при обновлении страницы и повторной отправке. Аналитика при этом считает отправку формы, а не факт создания сделки, поэтому расхождение между отчётами и CRM накапливается.

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

Вердикт за 30 сек

• Форма в Zero Block — стандартный обработчик Tilda её не видит. Точка.
• Рабочая связка: поля на нативных элементах, скрытый ID заявки, webhook на промежуточный обработчик, дедупликация в CRM по внешнему ID.
• Событие в аналитику уходит по ответу обработчика о создании сделки. Не по клику. Иначе отчёты врут минимум на 5% и выше.

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

Два подхода, которые реально конкурируют

Форма в Zero Block отправляет заявку, а в CRM её нет. Или она там дважды. Дальше развилка из двух путей, и на тесте оба выглядят рабочими.

Подход A: встроенные коннекторы Tilda напрямую в CRM

Собираете форму, подключаете готовую интеграцию из кабинета, ставите галочку «отправлять в CRM». Быстро. Без кода. На первой тестовой заявке всё уходит.

Подход B: webhook через промежуточный обработчик

Форма шлёт POST на ваш URL. Обработчик (скрипт, Make, Albato, n8n) проверяет ID заявки, логирует запрос, только потом создаёт сделку в CRM. Дольше на старте, зато предсказуемо на потоке.

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

Критерии, по которым сравниваю

Таблица честная, но неполная. На практике выбор реже про «что лучше» и чаще про «что у меня уже есть». CRM не поддерживает API или webhook, промежуточного сервиса нет — вариант B физически не собрать. Тогда либо меняете CRM, либо миритесь с ручным переносом.

Когда брать A, когда B

Берите A (коннекторы напрямую), если:

• Формы собраны только на стандартных блоках Tilda, без Zero Block. Встроенных настроек там хватает.
• Поток заявок небольшой — до пары десятков в неделю, и ручная сверка не съедает день.
• Нет человека, который будет поддерживать обработчик и разбирать логи.
• CRM не отдаёт API и не принимает webhook — выбора просто нет.

Берите B (webhook + обработчик), если:

• Форма живёт внутри Zero Block и использует кастомные поля, select, textarea.
• Вы уже ловили дубли или заявки, не дошедшие до CRM.
• Нужна аналитика по факту сделки, а не по клику. Расхождение между отчётами и CRM при отправке события по клику — от 5% и выше, и оно копится.
• Есть готовый промежуточный сервис или 2–4 часа на его сборку.

Мой вердикт для Zero Block: A не подходит по определению. Обработчик Tilda привязан к блоку BF и ищет поля по своим селекторам. В Zero Block вы верстаете форму руками — скрипт не находит поля и молча ничего не отправляет. Это не «иногда глючит», это не работает.

Сборка формы в Zero Block: что обязательно

Форма внутри Zero Block должна стоять на нативных элементах Tilda — input, select, textarea. Не рисуйте поля картинками и не собирайте из div-ов: данные будет неоткуда взять.

1. Поля ввода — имя, телефон, email. Каждому элементу задайте понятное имя, по нему будете собирать объект.
2. Скрытое поле с уникальным ID заявки — генерируется при загрузке страницы. Это ядро всей схемы: по нему потом ловите дубли.
3. Кнопка отправки — обычная, но обработчик клика пишете сами. Стандартная кнопка Tilda здесь не сработает.

Дальше — сборка объекта с данными формы и POST-запрос на URL приёмника. В теле передаёте имя, телефон, email и тот самый ID. Ответ обработчика разбираете: успех — идёте дальше, ошибка — показываете пользователю понятное сообщение, а не «спасибо, мы свяжемся».

Тут часто спотыкаются: обработчик ответа пишут «на всякий случай», а потом не понимают, почему заявки теряются. Webhook вернул ошибку, а вы всё равно показали «спасибо» — заявка ушла в никуда, и вы об этом не узнаете.

Промежуточный обработчик: где именно рождается порядок

Обработчик — не бюрократия ради бюрократии. Это единственное место, где вы можете проверить ID на дубль до создания сделки. Без него дедупликация превращается в лотерею.

Что делает обработчик:

• Принимает POST, логирует входящий запрос целиком.
• Проверяет ID заявки — был такой или нет.
• Если новый — создаёт сделку в CRM, возвращает её ID.
• Если повтор — не создаёт вторую, возвращает признак «уже есть».

Варианты реализации: Make, Albato, n8n или собственный скрипт. По моему опыту для SMB без разработчика Make и Albato закрывают задачу в лоб, но подписка и лимиты операций — то, о чём вспоминают на третий месяц. Собственный скрипт дешевле в перспективе, но требует человека, который его поднимет. Нет такого человека — не берите B «на вырост», возьмите сервис.

Похожие связки форм и обработчиков мы разбираем в каталоге решений — там видно, как это собирается под разные CRM.

Дедупликация в CRM: поле, правило, тест

Без дедупликации доля дублей может достигать 10–15% от общего числа заявок. Это не редкость, это норма для формы, которую можно отправить дважды.

1. Заведите в CRM обязательное поле «внешний ID заявки».
2. Настройте правило: если ID уже есть — обновлять существующую сделку, а не создавать новую.
3. Прогоните тест: отправьте заявку, затем отправьте её повторно с тем же ID. Второй сделки быть не должно.

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

И про таймауты webhook. CRM отвечает медленно — запрос может уйти повторно. Тут спасает только идемпотентность на стороне обработчика: один ID — одна сделка, сколько бы раз запрос ни пришёл.

Аналитика: событие по факту сделки, не по клику

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

Правильно так: событие уходит после ответа обработчика об успешном создании сделки. CRM возвращает ID сделки — передавайте его в событие. Тогда в отчётах будет не «сколько раз нажали», а «сколько сделок реально создано».

Сверка отчётов с CRM — обязательный шаг. Не раз в квартал, а через отчётный период после запуска. Расхождение в 5% — повод лезть в логи обработчика, а не «списывать на погрешность».

Хотите, чтобы этот контур собрали и проверили под вашу CRM — это как раз задача для заявки на подключение.

Когда это не сработает

Честно, без «в большинстве случаев работает».

• CRM не поддерживает API или webhook и нет промежуточного сервиса для приёма данных. Схему B собрать не из чего.
• Формы только на стандартных блоках Tilda. Zero Block не используется — встроенных настроек хватает, городить webhook незачем.
• Нет человека на поддержку. Обработчик — живой контур: логи, таймауты, обновления полей. Поддерживать некому — через месяц он тихо умрёт, и вы вернётесь к ручному переносу.
• Поля собраны не на нативных элементах. Форма нарисована из div-ов — данные взять неоткуда, придётся переверстывать.

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

Что сделать через 10 минут после чтения

1. Откройте форму в Zero Block и проверьте: поля на нативных элементах или нарисованы?
2. Отправьте тестовую заявку и посмотрите, появилась ли она в CRM. Нет — вы уже знаете почему.
3. Отправьте ту же заявку второй раз. Появилась вторая сделка? Значит, дедупликации нет.
4. Заведите поле «внешний ID заявки» в CRM — это первый шаг, который не требует кода.

Этого хватит, чтобы понять, в какой точке вы находитесь: A, B или «пока никак».

FAQ

Почему стандартная форма Tilda не работает внутри Zero Block?

Обработчик Tilda привязан к блоку BF и ищет поля по своим селекторам. В Zero Block вы верстаете форму вручную, поэтому скрипт не находит поля и не отправляет данные. Это не баг, это архитектура.

Как настроить отправку заявки из Zero Block в CRM?

Соберите данные из полей формы в объект и отправьте POST-запрос на webhook-URL вашей CRM или промежуточного сервиса. В теле передайте имя, телефон, email и уникальный ID заявки. Ответ обработчика разберите: успех — показываете подтверждение, ошибка — сообщение об ошибке.

Откуда берутся дубли заявок и как их убрать?

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

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

Отправляйте событие в аналитику после ответа webhook об успешном создании сделки. CRM возвращает ID сделки — передавайте его в событие. Тогда в отчётах будет факт создания сделки, а не факт клика.

Можно ли обойтись без Make и Albato?

Да, если есть собственный скрипт на сервере. Он делает то же самое: принимает POST, проверяет ID, создаёт сделку, логирует. Разница в том, кто это поддерживает — сервис или ваш человек. Без человека сервис надёжнее.

Куда дальше

Если после тестовой заявки вы увидели дубль или пустоту в CRM — это не «Тильда глючит», это отсутствие промежуточного звена. Соберите контур по схеме B: нативные поля, скрытый ID, webhook, обработчик, дедупликация, событие по факту сделки.

Посмотрите готовые интеграции под ваш стек — там видно, что уже собрано и что придётся докручивать под вашу CRM.

Сценарий внедрения: дорожная карта на первые недели

Соберите форму внутри Zero Block на стандартных элементах Tilda (input, select, textarea) и добавьте скрытое поле с уникальным идентификатором сессии. Подключите отправку через webhook на промежуточный обработчик — собственный скрипт или Make/Albato, который проверяет идентификатор перед созданием сделки. В CRM заведите обязательное поле «внешний ID заявки» и настройте дедупликацию по нему. Событие в аналитике отправляйте не по клику, а по ответу обработчика об успешном создании сделки. Для отладки прогоните тестовую заявку и проверьте, что повторная отправка с тем же ID не создаёт вторую сделку.

1. Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
2. Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
3. Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
4. Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.

Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.

Риски и как их снять заранее

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

Отдельно для разработки: фиксируйте производительность, безопасность и индексируемость страниц как часть DoD деплоя, а не постфактум.

Что сделать дальше

Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

По запросу высылаем чеклист диагностики и шаблон weekly-отчёта по экспериментам: там видно, когда пора усиливать сценарий, а когда — остановиться.

• Запросить диагностику процесса: Открыть форму контактов PrimeCoder
• Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI

FAQ по теме статьи

Почему стандартная форма Tilda не работает внутри Zero Block?

Обработчик Tilda привязан к блоку BF и ищет поля по своим селекторам. В Zero Block вы верстаете форму вручную, поэтому скрипт не находит поля и не отправляет данные. Решение — либо использовать блок BF внутри Zero Block, либо отправлять данные своим скриптом через webhook.

Как настроить отправку заявки из Zero Block в CRM?

Соберите данные из полей формы в объект и отправьте POST-запрос на webhook-URL вашей CRM или промежуточного сервиса. В теле запроса передайте имя, телефон, email и уникальный ID заявки. Ответ обработчика используйте как триггер для события аналитики.

Откуда берутся дубли заявок и как их убрать?

Дубли появляются, когда пользователь дважды нажимает кнопку, обновляет страницу или когда webhook срабатывает повторно из-за таймаута. Уберите их на стороне приёмника: заведите поле «внешний ID» и настройте правило — если заявка с таким ID уже есть, новая не создаётся, а обновляется существующая.

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

Отправляйте событие в аналитику после ответа webhook об успешном создании сделки. Если CRM возвращает ID сделки, передавайте его в событие. Тогда в отчётах будет не «форма отправлена», а «сделка создана», и расхождение с CRM исчезнет.

Что делать, если CRM не принимает webhook напрямую?

Используйте промежуточный сервис — Make, Albato, n8n или собственный скрипт на сервере. Он принимает запрос от Tilda, проверяет ID на дубли и через API создаёт сделку в CRM. Это добавляет один шаг, но даёт контроль над дедупликацией и логированием.

Как проверить, что дублей нет?

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

Дальше по теме платформы: смежные материалы (Разработка и запуск продукта)

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

• Сколько стоит сайт под ключ в Москве
• Как выбрать подрядчика по AI и автоматизации
• Внедрение AI в продажи за 30 дней