Стоп-лист (suppression list) в B2B-аутриче: как составить и поддерживать

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

Что такое suppression list и чем он отличается от обычного фильтра базы

Suppression list — список email-адресов и доменов, на которые компания обязуется не отправлять письма ни при каких обстоятельствах, независимо от того, в какую кампанию или сегмент они потенциально попадают. Это отличает его от обычной фильтрации по ICP: ICP решает, кому имеет смысл писать, суппрессия — кому писать категорически нельзя, даже если формально контакт подходит под все критерии целевой аудитории.

В холодном B2B-аутриче suppression list особенно важен, потому что здесь нет истории подписки, которая защищала бы от повторного контакта — единственная защита от того, чтобы снова написать человеку, который явно отказался, это именно suppression list, применяемый на уровне технической инфраструктуры рассылки, а не памяти конкретного менеджера.

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

Какие записи должны попадать в стоп-лист

Есть четыре категории, которые обязательно должны исключаться из активной рассылки, и логика включения для каждой немного отличается.

Явный отказ — человек прямо попросил больше не писать, ответив на письмо или через ссылку отписки. Это самая однозначная категория: адрес должен попасть в suppression list немедленно и бессрочно. Жалоба на спам — получатель пометил письмо как спам через интерфейс своего почтового клиента; такой сигнал доходит до отправителя через отчёты почтовых провайдеров и тоже требует немедленного и бессрочного исключения. Регуляторный отказ — например, компания попросила прекратить любую коммуникацию по юридическим основаниям. Hard bounce — почтовый ящик не существует или домен недоступен; здесь суппрессия скорее техническая, чем связанная с волей человека, но повторные попытки отправки только вредят репутации домена.

• Явный отказ через ссылку отписки или ответ на письмо
• Жалоба на спам, зафиксированная почтовым провайдером
• Регуляторный или юридический запрос на прекращение коммуникации
• Hard bounce — адрес или домен не существует
• Ручное добавление менеджером по итогам переговоров (например, компания прямо попросила не писать вне рамок текущей сделки)

На каком уровне применять суппрессию — email, домен или человек

Простейший уровень — конкретный email-адрес: если контакт отписался, его личный ящик исключается из рассылки. Но этого не всегда достаточно: если человек отказался от переписки, а через полгода сменил место работы, теоретически можно снова написать ему на новый корпоративный адрес — здесь возникает этический вопрос, а не только технический.

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

Как технически встроить суппрессию в процесс рассылки

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

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

Если компания использует несколько инструментов для отправки писем одновременно — например, отдельно для холодного аутрича и отдельно для существующих клиентов, — suppression list должен синхронизироваться между этими инструментами автоматически, через API или регулярную выгрузку, а не поддерживаться вручную в каждом инструменте по отдельности.

• Централизованная таблица суппрессии, общая для всех кампаний компании
• Автоматическая сверка при формировании списка получателей перед каждой отправкой
• Логирование причины и даты добавления в суппрессию для истории и аудита
• Регулярная проверка hard bounce после каждой волны рассылки с автоматическим добавлением в список

Частые ошибки при ведении suppression list

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

• Suppression list хранится в разных местах для разных кампаний, из-за чего появляются пробелы
• Ручная сверка перед отправкой вместо автоматической проверки на уровне системы
• Суппрессия по email без учёта того, что человек мог сменить работу и вернуться под новым адресом
• Установка срока истечения для явного отказа — отказ должен действовать бессрочно, если человек сам не попросил обратного
• Отсутствие суппрессии на уровне домена при повторяющихся жалобах от нескольких контактов одной компании

Suppression list и требования законодательства

Ведение suppression list напрямую связано с требованиями ФЗ-152 о персональных данных: если человек отозвал согласие на обработку своих данных для целей рассылки, компания обязана прекратить обработку в этих целях, и suppression list — практический механизм, который это обеспечивает на уровне технической системы, а не только формальной политики на бумаге.

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

Практический момент, который часто упускают: suppression list — это ещё и запись о самом факте отзыва согласия, а не только технический фильтр для рассылки. Если контакт впоследствии обратится с вопросом о том, обрабатываются ли его данные, зафиксированная дата и канал отказа станут основанием для быстрого и корректного ответа, а не поводом поднимать историю переписки вручную.

Вопросы и ответы