Собираю формы на Tilda больше пяти лет, и почти в каждом втором проекте вижу одну и ту же ошибку: клиент выкладывает форму заявки на 12-15 полей одним полотном, а потом удивляется, почему из 100 человек, открывших форму, до отправки доходят 15-20. Многошаговая форма на Tilda с логикой решает именно эту проблему - она дробит длинный список полей на 3-5 экранов и показывает пользователю только те вопросы, которые реально к нему относятся. Дальше расскажу, как я собираю такие формы на практике: какие блоки Tilda для этого подходят, где приходится дописывать JS вручную и на каких местах разработчики чаще всего застревают.
Зачем нужна форма в несколько шагов с условной логикой на Tilda
На мобильных устройствах после третьего обязательного поля отваливается до 50-60% посетителей - это не догадки, а то, что я регулярно вижу в Яндекс.Метрике на конкретных проектах. Причина простая: человек видит длинную анкету, на глаз оценивает, сколько времени на неё потратит, и закрывает вкладку, даже не начав заполнять.
Многошаговая форма решает это визуально: вместо 15 полей пользователь видит 3-4 на экране плюс прогресс-бар «Шаг 2 из 4». Психологически это воспринимается как короткая анкета, даже если суммарно полей столько же, сколько было в исходном варианте.
Условная логика добавляет вторую выгоду - форма не задаёт лишних вопросов. На одном из проектов (заявка на разработку сайта) я делал развилку: если человек выбирал «уже есть сайт, нужен редизайн» - форма показывала поле со ссылкой на текущий сайт и вопрос про CMS; если выбирал «делаем с нуля» - вместо этого появлялся блок с вариантами бюджета. За полтора месяца после запуска конверсия формы выросла с 2,4% до 4,1% при том же объёме трафика.
Из чего собрать пошаговую форму в Tilda: блоки и конструкторы
Штатный блок форм Tilda (T396 и его вариации) из коробки не умеет ни шагов, ни условной логики - только сплошной список полей с фиксированной версткой. Чтобы получить многошаговость, есть три рабочих варианта, и я выбираю между ними в зависимости от сложности проекта.
| Способ | Логика | Сложность | Когда использую |
|---|---|---|---|
| Zero Block + верстка вручную | Полная свобода, любые условия через JS | Высокая, нужен JS | Форма - часть воронки продаж, шагов больше 3 |
| T396 + кастомный скрипт поверх | Показ/скрытие блоков через классы и data-атрибуты | Средняя | Простая форма, 2-3 шага |
| Готовые конструкторы форм (Formstyler и аналоги) | Есть логика «если-то» из коробки | Низкая, но ограничена кастомизация | Бюджета на разработку нет, логика типовая |
Для сложных сценариев беру Zero Block и верстаю шаги руками - это единственный вариант, где можно завязать логику на несколько условий одновременно (например, тип клиента + регион + сумма заказа). Для типовых задач вроде «показать поле «Название компании» только при выборе «Юрлицо»» у меня есть набор готовых JS-сниппетов для Tilda, которыми закрываю большинство однотипных сценариев без написания кода с нуля.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Условная логика полей: как показывать и прятать вопросы по ответу
Схема, по которой я обычно собираю логику: каждый шаг - отдельный div с классом tilda-step и атрибутом data-step, а переключение полей внутри шага вешаю на событие change у радиокнопок или select. Прогресс-бар пересчитывается той же функцией, что переключает шаги.
document.addEventListener('DOMContentLoaded', function () {
var steps = document.querySelectorAll('.tilda-step');
var current = 0;
function showStep(index) {
steps.forEach(function (step, i) {
step.style.display = i === index ? 'block' : 'none';
});
var bar = document.querySelector('.progress-bar');
if (bar) bar.style.width = Math.round((index + 1) / steps.length * 100) + '%';
}
document.querySelectorAll('input[name="Radio_1"]').forEach(function (radio) {
radio.addEventListener('change', function () {
var companyField = document.querySelector('[data-name="Company"]');
var isCompany = this.value === 'Юрлицо';
companyField.style.display = isCompany ? 'block' : 'none';
companyField.querySelector('input').required = isCompany;
});
});
document.querySelectorAll('.btn-next').forEach(function (btn) {
btn.addEventListener('click', function () {
if (current steps.length - 1) {
current++;
showStep(current);
}
});
});
showStep(current);
});Важный момент, на котором ловил себя не раз: имена полей (name="Radio_1", data-name="Company") в Tilda генерируются автоматически при добавлении поля в форму и не всегда совпадают между блоками - перед тем как писать логику, смотрю реальную верстку через инспектор браузера, а не полагаюсь на документацию.
Валидация в форме со скрытыми и всплывающими полями
Самая частая поломка многошаговой формы - скрытое поле с атрибутом required, которое блокирует отправку, хотя пользователь его даже не видел. Tilda проверяет обязательность полей независимо от того, показаны они через display: none или нет, поэтому при переключении видимости нужно вручную снимать и возвращать required - это видно в примере кода выше, где атрибут переключается вместе со стилем.
Вторая часть валидации - проверка текущего шага перед переходом к следующему. Если этого не сделать, пользователь долистает до последнего экрана с незаполненным телефоном на первом шаге и получит ошибку в самом неудобном месте. На практике перед кнопкой «Далее» прогоняю проверку обязательных полей именно текущего шага, а не всей формы сразу, и подсвечиваю конкретное поле с ошибкой красной рамкой.
Прогресс-бар и UX многошаговой анкеты
Прогресс-бар - не декорация, а единственный сигнал пользователю, сколько ещё осталось. Считаю ширину полосы от количества активных (не скрытых логикой) шагов, а не от общего числа div-ов в верстке - иначе при ветвлении, где часть шагов пропускается, прогресс скачет нелогично.
Ответы с предыдущих шагов сохраняю в sessionStorage, чтобы кнопка «Назад» не обнуляла заполненные поля - без этого пользователи, которые случайно промахнулись мимо кнопки, теряют весь прогресс и уходят. На мобильных отдельно слежу, чтобы клавиатура не перекрывала кнопку «Далее» - добавляю scrollIntoView при фокусе на поле, иначе часть заявок теряется просто потому, что человек физически не видит кнопку отправки.
Куда уходят данные из формы: CRM, СДЭК, эквайринг
Сама Tilda после отправки формы шлёт данные одним пакетом в свою CRM и на почту, но для реальной работы этого обычно мало. На шаге с адресом доставки я нередко дёргаю API СДЭК через AJAX прямо внутри формы, чтобы показать стоимость и сроки ещё до отправки заявки - это отдельная доработка, а не штатная функция Tilda. После отправки весь пакет данных, включая рассчитанную доставку, улетает дальше: через нативный вебхук Tilda или через n8n - в amoCRM, Bitrix24 или сразу менеджеру в Telegram через бота на aiogram.
Простую доработку логики (условие для одного-двух полей, замена текста по выбору) делаю от 3 000 ₽, комплексную интеграцию формы с CRM, эквайрингом или расчётом доставки через СДЭК - от 40 000 ₽, срок зависит от количества систем на другой стороне интеграции.
Когда стандартных блоков не хватает
Кастомный скрипт
от 3 000 ₽
Подробнее →Частые вопросы
Сколько шагов делать в многошаговой форме на Tilda?
На практике 3-4 шага - оптимум для большинства заявок. Пять шагов уже начинает терять людей, если только это не сложный расчёт (например, конфигуратор для интернет-магазина с доставкой). На каждом шаге стараюсь держать не больше 3-4 полей, иначе смысл дробления теряется.
Можно ли сделать условную логику без программиста, штатными средствами Tilda?
Частично. Zero Block с готовыми блоками «показать при условии» закрывает простые сценарии вроде показа поля при выборе радиокнопки. Но ветвление на несколько уровней (когда следующий вопрос зависит сразу от двух-трёх предыдущих ответов) без JS не собрать - там уже нужен скрипт поверх формы.
Можно ли отправлять данные с разных шагов в разные системы - например, отдельно в СДЭК и отдельно в CRM?
Данные с формы уходят одним пакетом при финальной отправке, поэтому «разные шаги в разные системы» технически не работают. Но на промежуточном шаге с адресом можно через AJAX дёрнуть API СДЭК и получить стоимость доставки прямо в форме, а после отправки весь пакет данных, включая эту стоимость, уже одним запросом улетает в CRM через вебхук или n8n.
Ломается ли аналитика Метрики и GA4 при переходе между шагами формы?
Если шаги реализованы через переключение display: none/block без смены URL, стандартная цель на отправку формы в Tilda срабатывает нормально. А вот промежуточные шаги сами по себе в аналитику не попадают - чтобы видеть, на каком шаге отваливаются люди, вручную отправляю события в Метрику и GA4 при показе каждого шага. Без этого треть картины воронки остаётся невидимой.