CRM-аналитика
Клиент отписался, но снова попал в выгрузку: как устроить единый запрет рассылок
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Клиент нажал «Отписаться», исчез из сегмента, а через неделю снова получил акцию. Маркетолог видит запрет в сервисе рассылок, аналитик — активный контакт в хранилище, интегратор — успешно завершённый импорт. Каждый участок работает по своим правилам, но обещание клиенту нарушено.
Причина часто в том, что отписку считают свойством одной записи. В действительности это решение человека с определённой областью действия: больше не получать рекламу бренда, отказаться от конкретной темы или отключить один канал. Такое решение должно переживать перемещение данных между системами.
Suppression — технический запрет на включение контакта в отправку. Он может возникнуть из-за отписки, жалобы, неработающего адреса или внутреннего ограничения. Эти причины нельзя сводить к одному безымянному флажку: правила отмены у них различаются.
Разделите разрешение, запрет и возможность доставки
В некоторых платформах глобальное состояние подписки существует отдельно от тематических групп. Например, Braze документирует несколько уровней управления email-подпиской и отдельную обработку невалидных адресов. Поэтому «контакт доступен в платформе» и «контакту разрешена эта рассылка» — разные проверки.[1]
Для своей системы опишите три независимых вопроса. Есть ли основание направить сообщение такого назначения? Есть ли действующий запрет в его области? Работает ли технический адрес доставки? Новая покупка может обновить профиль, но сама по себе не отвечает на первые два вопроса.
| Состояние | Что означает | Что не должно его отменять |
|---|---|---|
| Отказ от рекламы бренда | Рекламные сообщения бренда запрещены в указанном объёме | Импорт покупок или вход в аккаунт |
| Отказ от одной темы | Нельзя отправлять выбранную рубрику | Перезапись остальных интересов |
| Невалидный email | Адрес непригоден для доставки | Разрешение на другой канал |
| Пауза по обращению | Временно ограничены определённые сценарии | Обычное обновление профиля |
Создайте запись о решении, а не только итоговый статус
Практическая модель CRM Lab — журнал изменений разрешений и отдельное вычисляемое состояние для отправки. В журнале сохраняются идентификатор события, клиент или контакт, бренд, канал, назначение сообщения, тип решения, время поступления, источник и ссылка на подтверждение действия.
Время действия клиента и время получения события полезно хранить раздельно. Если события приходят с задержкой, более поздняя загрузка не обязательно содержит более свежее решение. Версия или порядковый номер события помогают не принимать старый импорт за новое согласие.
У итогового статуса должен быть владелец. Если сервис рассылок, сайт и контакт-центр одинаково свободно записывают «подписан», система рано или поздно восстановит нежелательную подписку. Согласуйте, какие события вправе дать разрешение и какие только обновляют контактные данные.
Проверяйте запрет в момент, когда ещё можно остановить отправку
Одной фильтрации при сборке сегмента недостаточно. Между выгрузкой и отправкой проходит время, а клиент может отписаться уже после подготовки аудитории. Проверка условий перед отправкой должна заново учитывать актуальный запрет, а очередь — поддерживать исключение ещё не переданных провайдеру сообщений.
При недоступности сервиса разрешений безопасное рабочее правило для рекламы — отложить отправку. Это выбранная архитектура отказа, а не универсальная техническая особенность CDP. CDP, то есть платформа клиентских данных, может хранить статусы, но само её наличие не гарантирует выполнение запрета во внешней системе.
Для уже принятого почтовым провайдером сообщения отзыв часто недоступен. Поэтому полезно сокращать неподконтрольный участок очереди и фиксировать момент передачи. Этот факт помогает расследовать инцидент, но не оправдывает продолжение новых отправок после отказа. Для рекламы по сетям электросвязи российский закон требует прекратить распространение по требованию адресата немедленно.[2]
Условный пример: старая выгрузка вернула подписчика
В 10:00 подготовлен файл на 40 тысяч клиентов. В 10:07 один клиент отказался от рекламных email. В 10:15 файл загрузили в новую ESP — сервис подготовки и отправки рассылок. Поле subscribed=true из файла перезаписало запрет.
Исправление состоит из трёх частей. Импорт профиля больше не имеет права выдавать согласие. Запрет поступает в новую ESP независимо от основного импорта. Перед передачей письма выполняется последняя проверка. Простое уменьшение интервала выгрузки сокращает вероятность ошибки, но не устраняет её причину.
Что происходит при объединении профилей
Если один и тот же подтверждённый клиент существует в двух профилях, объединение не должно терять его отказы. Но общий email семьи ещё не доказывает, что перед нами один человек. Сначала определяют принадлежность контакта и объём решения, затем распространяют запрет.
Для неразрешённого конфликта выберите консервативное правило: приостановить соответствующую рекламу до уточнения. Не переносите согласие одного человека другому только потому, что у них совпадает телефон или адрес. Правила объединения клиентов и правила разрешений должны проверяться совместно.
Как принять доработку
Возьмите тестовый профиль и проведите его через отписку, повторный импорт, объединение, перенос в другую платформу и восстановление из резервной копии. После каждого шага попробуйте запустить подходящую рекламную кампанию. Проверяется отказ в отправке и его объяснение в журнале, а не только цвет индикатора в интерфейсе.
Завершённая работа даёт возможность ответить: «Этому клиенту это сообщение не отправлено, потому что действует такое решение, полученное тогда-то». Если ответ приходится собирать вручную из трёх таблиц, единый запрет ещё не стал частью системы.
Источники
[1] Braze. Email subscriptions. Документация: состояния email-подписки и группы подписок. Проверено 22.09.2026.
[2] Российская Федерация. Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе», статья 18. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.