Тильда рассылка: сбор базы подписчиков и передача в сервис писем

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

Как устроена тильда рассылка на стороне платформы

Сама Тильда массовую рассылку по базе не ведёт - она отправляет только служебные письма вроде подтверждения заказа или уведомления о новой заявке. Форма (блок «Формы») собирает данные и сохраняет их в разделе «Лиды» панели проекта, а дальше может передать их по одному из двух каналов: через готовую интеграцию во вкладке настроек формы или через собственный вебхук.

Список готовых интеграций у Тильды достаточно широкий: сервисы email-рассылок (UniSender, GetResponse, Mailchimp, SendPulse), CRM-системы (amoCRM, Битрикс24, retailCRM), Google Таблицы, Telegram, а также универсальный Webhook и no-code коннекторы вроде Zapier, Albato и Make для сервисов, которых нет в базовом списке.

Сбор базы подписчиков: форма, согласие, скрытые поля

Прежде чем настраивать передачу лидов дальше, форма должна собирать данные правильно на своей стороне.

• Добавляю обязательный чекбокс «Согласие на обработку персональных данных» со ссылкой на политику конфиденциальности - без него сбор базы не имеет правового основания по 152-ФЗ.
• Называю поля формы так, чтобы они однозначно сопоставлялись с полями сервиса рассылок: Email, Name, Phone, а не «Ваша почта» или «Контакт для связи» - при передаче через вебхук путаница в названиях полей теряет часть данных.
• Для отслеживания источника подписки использую скрытые поля формы: Тильда умеет автоматически подставлять в них значения UTM-меток (utm_source, utm_medium, utm_campaign) из адресной строки, если завести такие скрытые поля с соответствующими плейсхолдерами.
• Если нужен double opt-in (подтверждение подписки по ссылке в письме), эту логику выполняет сам сервис рассылок после получения email - Тильда только передаёт контакт дальше.

Передача заявок в сервис email-рассылок через готовую интеграцию

Порядок настройки одинаковый для большинства сервисов из списка: открываю блок формы на странице, перехожу в настройки блока, вкладка «Интеграции», выбираю нужный сервис (например, UniSender или GetResponse), вставляю API-ключ из личного кабинета этого сервиса, сопоставляю поля формы с полями списка рассылки и сохраняю. Важный момент, о который спотыкаются чаще всего: настройки интеграции применяются только после публикации страницы - если проверить форму сразу после сохранения без публикации, данные никуда не уйдут.

Поскольку email и телефон подписчика - персональные данные, для основного хранения базы выбираю сервис с серверами в России (например, UniSender или DashaMail), а не завожу контакты клиентов в иностранном облачном сервисе на постоянной основе. Google Таблицы удобны как временный лог для отладки вебхука, но не как основное хранилище базы подписчиков.

Если нужного сервиса нет в списке - вебхук и no-code коннекторы

Когда в готовых интеграциях Тильды нет сервиса рассылок, использую вкладку «Webhook» в настройках формы: указываю URL обработчика, и Тильда отправляет туда POST-запрос с полями формы при каждой отправке. Принять такой запрос можно обычным PHP-скриптом на том же хостинге, где уже лежит сайт, - отдельный сервер под это не нужен, обработчик вебхука не требует ничего, кроме поддержки PHP и исходящих запросов curl.

<?php
$email = $_POST['Email'] ?? null;
$name = $_POST['Name'] ?? '';

if (!$email) {
    http_response_code(400);
    exit('email required');
}

$ch = curl_init('https://api.unisender.com/ru/api/subscribe');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query([
    'format' => 'json',
    'api_key' => getenv('UNISENDER_API_KEY'),
    'list_ids' => '1',
    'fields[email]' => $email,
    'fields[Name]' => $name,
]));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_exec($ch);
curl_close($ch);

http_response_code(200);
echo 'ok';

Если логика сложнее одного вызова API - нужно разложить лид сразу в CRM, в сервис рассылок и отправить уведомление в Telegram-бота, или сначала проверить email на дубли и только потом добавлять подписчика - проще собрать это как сценарий, а не городить свой обработчик под каждую интеграцию. Для такой оркестровки нескольких вебхуков и API беру автоматизацию в n8n: вебхук на входе, дальше ветвление и вызовы нужных сервисов без отдельного кода под каждый шаг.

Где хранить базу подписчиков и требования к персональным данным

Контакты пользователей из России по 152-ФЗ должны в первую очередь обрабатываться на серверах в РФ. На практике это значит: выбираю сервис рассылок или CRM с локализацией данных в России (UniSender, DashaMail, amoCRM и Битрикс24 в российском облаке), а не держу основную базу клиентов в иностранном сервисе таблиц или заметок - там её можно вести разве что как черновой рабочий лог, но не как систему хранения контактов.

Частые ошибки при сборе базы на Тильде

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

Если нужно собрать связку с нуля - форма с согласием, вебхук, интеграция с CRM и эквайрингом - обычно это идёт как комплексная интеграция для Tilda, от 40 000 ₽. Точечная правка формы или вебхука (например, добавить скрытое поле или поменять адрес обработчика) - это кастомный скрипт для Tilda, от 3 000 ₽.

Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.

Частые вопросы

Нужно ли согласие на обработку персональных данных для сбора email через форму на Тильде?

Да, обязательный чекбокс с ссылкой на политику конфиденциальности нужен всегда, когда форма собирает email, телефон или имя. Без него сбор базы не имеет правового основания по 152-ФЗ, независимо от того, куда потом уходят данные - в CRM, сервис рассылок или просто в раздел «Лиды» на Тильде.

Можно ли одновременно передавать заявку в CRM, сервис рассылок и Telegram?

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

Что делать, если нужного сервиса email-рассылок нет в списке готовых интеграций Тильды?

Использую вкладку «Webhook» в настройках формы и принимаю данные своим обработчиком на хостинге, который уже обращается к API нужного сервиса. Второй вариант - no-code коннектор вроде Zapier, Albato или Make: они умеют забирать вебхук от Тильды и передавать его в сервисы, для которых нет прямой интеграции.

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

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