Почему подписка на сайте теряет письма: разбор интеграции Unisender
Форма подписки на сайте выглядит рабочей: поле, кнопка, сообщение «спасибо, вы подписаны». Заявка при этом может не уходить никуда — обработчик складывает адрес в локальную таблицу или отправляет письмо на ящик менеджера, а в сервис рассылок не попадает ничего. Через месяц выясняется, что половина собранной базы лежит в файле, который никто не разбирал, и эти люди не получили ни одного письма.
Второй типовой сбой — потеря статусов двойного подтверждения подписки. Человек получает письмо, нажимает кнопку, но ответ сервиса не сохраняется: в базе он остаётся неподтверждённым, и запросы на подтверждение уходят снова и снова. Получатель воспринимает это как спам и жалуется — жалобы и отписки напрямую бьют по доставляемости писем для всей базы, а не только для одного адреса.
Третий — кривая обработка ошибок. Если сервис отдал отказ или ответил с задержкой, обработчик не повторяет запрос и не пишет сбой в журнал, а просто теряет адрес. Повторная отправка формы добавляет того же человека второй раз, письма уходят на адреса, которые никто не подтверждал, — и часть базы уходит в отписки по нашей вине.
Потеря подписчиков почти не видна в интерфейсе: там всё «успешно», пока не сравнишь число заявок с сайта с числом новых адресов в сервисе. Интеграция Unisender должна закрывать именно эти разрывы — заявка доходит и получает статус, повторный запрос не дублирует адрес, а сбой виден в журнале, а не в чужом почтовом ящике.
Что меняется после настройки: доставляемость, скорость, отписки
Пока контакты попадают в базу выгрузкой файлом раз в сутки, человек, подписавшийся вечером, получает приветственное письмо на следующий день — и часть адресов к этому моменту уже не помнит, где оставила согласие. После связки сайта с Unisender контакт уходит в базу в момент отправки формы, вместе со статусом подписки: подтверждён, ожидает подтверждения, отписан. Письмо приходит в течение минуты, пока интерес свежий, а статусы синхронизируются в обе стороны — отписка на сайте гасит рассылку, отписка в письме видна на сайте.
Доля подтверждённых адресов растёт за счёт двойного подтверждения: адрес попадает в активную базу только после перехода по ссылке из письма. Так отсеиваются опечатки, чужие и служебные адреса, а рассылка идёт по тем, кто действительно ждёт писем.
Снижение отписок и жалоб на спам — следствие того же порядка. Отписка в один клик сразу меняет статус и на сайте, и в базе рассылки, поэтому искать кнопку «это спам» незачем: письма отписавшимся не уходят, а почтовые фильтры видят, что механика отписки работает. Доля попаданий во «Входящие» растёт вместе с откликом.
Эффект измеряется четырьмя числами: время от отправки формы до первого письма, доля подтверждённых адресов, доля отписок и частота жалоб. Сверять их стоит раз в месяц: если подтверждённых стало меньше, форма или текст письма перестали объяснять, зачем подписываться.
Способы подключения: готовая форма, скрипт, обмен данными
Способы подключения различаются не «уровнем сложности», а тем, где живёт источник данных о подписчике. В одном случае адрес собирается прямо на странице, в другом — приходит с сервера вместе с заказом или регистрацией, в третьем — уходит обратно, когда человек отписался. От этого зависят требования к сайту и ограничения, которые проявятся позже.
На практике способы не заменяют, а комбинируют: один принимает адреса, второй синхронизирует статусы. В таблице — четыре варианта, когда каждый уместен и что он не умеет.
| Способ | Когда подходит | Ограничения |
|---|---|---|
| Встроенная форма подписки | Лендинг, блог, страница акции: приём адресов без доработки сайта | Поля и оформление заданы шаблоном; связь с заказом настраивается отдельно |
| Скрипт подписки | Несколько точек на сайте, всплывающее окно, форма внутри материала | Проверки идут в браузере: если сторонние скрипты блокируются, форма не появится |
| Программный интерфейс обмена данными | Подписка как часть регистрации, заказа, выгрузка из учётной системы | Нужна серверная обработка ответов и повторов: при сбое контакт теряется |
| Событийные уведомления | Обратная синхронизация: отписки, жалобы, недоставленные письма | Нужен приёмник событий и защита от повторной обработки |
Чаще выбирают комбинацию: форма или скрипт на витрине, обмен данными — для личного кабинета и учётной системы. При подключении к Unisender мы фиксируем, какой процесс закрывает каждый канал, и собираем минимальную конфигурацию: список не задваивается, отписки доходят до сайта.
Этапы внедрения интеграции Unisender: от аудита до передачи
Порядок здесь не формальность: если сначала настроить рассылку, а потом разбираться с источниками контактов, отписки и дубликаты всплывают уже после первых отправок — и репутация домена испорчена. Поэтому этапы внедрения интеграции Unisender идём от аудита к передаче, фиксируя проверяемый результат на каждом шаге.
-
Аудит подписных форм и текущей схемы. Смотрим, откуда приходят контакты, в какой список пишутся, есть ли подтверждение подписки, как обрабатываются отписки и повторные регистрации одних и тех же адресов.
-
Схема потоков данных. Рисуем карту: поле формы → собственное поле → список, сегмент или тег → сценарий. Здесь же правила дедупликации по адресу и нормализации значений, чтобы человек не оказался в базе трижды.
-
Настройка связки. Создаём списки, сегменты, теги, собственные поля и шаблоны, выдаём ключи доступа, подключаем события с сайта: регистрация, заказ, брошенная корзина.
-
Проверка сценариев рассылки. Прогоняем цепочки на тестовых контактах — приветственное письмо, серия прогрева, уведомления о заказе. Отдельно смотрим отписку, повторную подписку и поведение при недоступности сервиса: события должны уйти в очередь, а не потеряться.
-
Сверка данных. Убеждаемся, что отписка на сайте снимает контакт с рассылки, а смена статуса в сервисе отражается в базе сайта.
-
Передача доступов. Отдаём учётные записи и ключи, схему потоков, регламент добавления новых форм и сценариев, порядок разбора ошибок.
Конфигурация, схемы и регламенты: что остаётся у заказчика
Сдача интеграции — это не только работающие сценарии, но и набор артефактов, по которым ваша команда сможет менять рассылки без нас. Ниже — то, что остаётся на руках после запуска интеграции сервиса рассылок с сайтом.
- Карта сценариев. Все цепочки на одной схеме: событие на сайте, условие, задержка, письмо, следующий шаг. Видно, где сценарии пересекаются, а где конфликтуют за одну и ту же аудиторию.
- Шаблоны писем. Приветственное, триггерные, реактивационное и служебные — с темой, вёрсткой и списком переменных. Помечено, какие блоки редактор меняет свободно, а какие завязаны на данные сайта.
- Настройка полей подписчика. Какие поля обязательные и служебные, как они называются на сайте и в сервисе, правила нормализации телефона и почты при дублях и пустых значениях.
- Политики доступа. Роли в сервисе: кто видит списки, кто правит шаблоны, кто только выгружает статистику. Отдельно — права программных ключей и порядок их замены.
- Инструкции для редактора рассылок. Пошаговая сборка письма, проверка переменных, тестовая отправка на свою группу, порядок публикации и отката неудачной версии.
- Регламент синхронизации и отписок. Частота обмена, поведение при недоступности сайта, повтор событий из очереди, учёт жалоб и отказов досылки.
Каждый артефакт проверяем на живом сценарии: подписка, ветвление, отправка, отписка. Всё остаётся в вашем репозитории и в сервисе рассылок — менять сценарии и тексты можно без нашего участия.
Кейс: как выросла база подтверждённых подписок
В интернет-магазине подписка держалась на ручном экспорте контактов: менеджер раз в неделю выгружал заявки из админки, вычищал список глазами и заливал файл в сервис рассылок. К моменту разбора задачи до трети адресов дублировались — клиент приходил через форму, чат и офлайн-кассу, — а письма уходили и на адреса без подтверждения, из-за чего домен терял репутацию.
Мы подключили сайт к Unisender напрямую: форма подписки пишет контакт в нужный список в момент отправки, с источником и датой, и сразу включает подтверждение адреса. Дедупликация идёт по нормализованному адресу при каждой записи, приветственная триггерная цепочка стартует после подтверждения, а отписки синхронно возвращаются на сайт, чтобы повторно не подписать человека.
Метрики до и после
| Показатель | До интеграции | После |
|---|---|---|
| Доля подтверждённых адресов | 41% | 88% |
| Дубли в базе | около 30% | менее 1% |
| Задержка между подпиской и первым письмом | 3–7 дней | минуты |
| Ручные операции с базой | 4–6 часов в неделю | не требуются |
| Отписки после приветственной серии | 9% | 3% |
Ручных операций с базой не осталось, а у каждого контакта есть источник и дата — сегментацию по интересам можно строить без выгрузок. Такой кейс интеграции рассылок даёт рост базы подписчиков не за счёт объёма, а за счёт качества: писать можно чаще и безопаснее для репутации домена.
Чем транзакционные письма отличаются от массовых рассылок?
Транзакционное письмо — реакция на действие человека: подтверждение заказа, чек, восстановление доступа, код входа. Его нельзя отложить — получатель ждёт письмо в ту же секунду и без него не закончит сценарий. Массовая рассылка живёт иначе: её можно растянуть по часам, развести по сегментам и отправить в момент, когда аудитория активна.
Отсюда и разделение потоков писем. В общем потоке код подтверждения встаёт в очередь за кампанией на сотни тысяч адресов, и клиент получает его через сорок минут. Приоритет доставки решается раздельными подключениями и отдельными очередями: транзакция уходит немедленно, массовая рассылка — фоном, с ограничением скорости отправки.
Требования к шаблонам тоже расходятся. В транзакционном важна точная подстановка переменных — номер заказа, состав корзины, одноразовая ссылка — и одинаковая вёрстка во всех почтовых клиентах. В массовом шаблон несёт бренд и наборы блоков под сегменты, а персонализация ограничивается именем и парой полей.
Обработка ошибок отправки — главное отличие. Отказ адреса в транзакционном потоке значит, что человек не получил чек или не смог войти: нужны повторные попытки с нарастающей паузой, журнал отказов и сигнал в поддержку. В массовой рассылке жёсткий отказ — повод пометить адрес неактивным и исключить из будущих отправок, а не повторять отправку бесконечно.
И репутация домена: смешивать потоки с разной долей жалоб рискованно. Всплеск жалоб на рекламную кампанию утянет за собой доставляемость чеков и кодов. В Unisender это разделяется на уровне подключений и лимитов — каждый поток со своей статистикой и своими реакциями на ошибки.
Частые технические вопросы: синхронизация, дубли, сбои
При интеграции формы подписки с внешним сервисом рассылок команда упирается в одни и те же места: дубли контактов, поведение формы в момент недоступности внешнего сервиса и подтверждение согласия пользователя. Это не настройки в интерфейсе, а решения на уровне схемы данных и обработчиков — поэтому разбираем их до старта, а не после первой жалобы на рассылку.
Ниже — ответы на технические сомнения, которые чаще всего приходят от инженерных команд: как считается совпадение контактов при слиянии баз подписчиков, что видит пользователь при сбое на стороне сервиса и чем подтверждается согласие на обработку данных.
Как избежать дублей контактов при слиянии баз подписчиков?
Совпадение считаем по нормализованному адресу: приводим к нижнему регистру, отбрасываем точки и алиасы вида «плюс-тег». Адрес становится ключом сопоставления, остальные поля сливаются по правилу приоритета — свежее значение перекрывает старое, конфликты пишутся в лог с источником. Дубли не удаляются молча: слияние фиксируется, чтобы атрибуты не потерялись при следующей синхронизации.
Что происходит с формой, если внешний сервис недоступен?
Форма не роняет запрос в пустоту и не отдаёт пользователю ошибку. Данные пишутся в локальную таблицу подписок и ставятся в очередь на отправку; повторные попытки идут с нарастающей паузой, а состояние контакта синхронизируется, когда сервис отвечает. Пользователь видит подтверждение сразу, а подписка доезжает до внешнего сервиса без его участия.
Как подтверждается повторная подписка после отписки?
Статус контакта ведём отдельным полем, а не удалением записи, — поэтому история отписок и повторных подписок сохраняется. Повторная подписка снимает отметку отказа, но не воскрешает старые сегменты: контакт попадает только в те рассылки, где он подписан сейчас, и проходит подтверждение по письму.
Как хранится согласие на обработку данных?
Согласие фиксируем у себя: время, текст версии, источник формы и страницу, с которой пришёл запрос. Отметка в сервисе рассылок этого не заменяет — она живёт там и исчезает вместе с контактом. Доказательство остаётся на нашей стороне и выгружается по запросу.
Обсудим задачу: что нужно для оценки и плана работ
Оценка интеграции зависит не от объёма рассылок, а от того, сколько точек на сайте порождают события и насколько предсказуемо текущее состояние базы контактов. Ниже — вводные по проекту, которых достаточно, чтобы посчитать объём работ и вернуться с планом внедрения. Если чего-то нет под рукой, начнём с того, что есть, остальное уточним по ходу разбора.
- Точки подписки: формы в футере и на посадочных страницах, всплывающее окно, шаг регистрации, оформление заказа — и что именно фиксируется как согласие.
- Сценарии триггеров: какое событие запускает письмо, через сколько минут после него, что происходит при повторном срабатывании и как сценарий останавливается.
- Доступы: аккаунт Unisender с правами на создание сценариев и ключ API, админка сайта, зона домена для настройки подписи писем.
- Платформа сайта и её ограничения: как отдаются события, есть ли очередь для отложенных отправок, как сайт переживает пиковую нагрузку.
- Состояние базы: поля контактов, теги и сегменты, дубликаты, история подписок и отписок, доля нерабочих адресов.
- Внешние системы: CRM, склад, платежи — что из них служит источником истины, а что только дополняет сегменты.
- Требования к хранению персональных данных и сроку, на который берётся согласие на рассылку.
Этого набора хватает для оценки работ и подготовки к старту. Спорные места разберём на коротком созвоне, остальное уточним в переписке. Опишите задачу — вернёмся с оценкой сроков и планом внедрения по этапам.
