Как проверять условия перед массовой отправкой

Массовая кампания рассчитана утром на 300 тысяч клиентов и отправляется несколько часов. За это время кто-то покупает, кто-то отписывается, у кого-то заканчивается действие предложения. Если система использует только утренний список, часть сообщений к моменту отправки уже теряет основание.

Снимок аудитории — состав получателей на определённый момент. Очередь отправки — задания, которые ещё предстоит передать в канал. Проверка перед отправкой заново оценивает критичные условия непосредственно перед этим действием.

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

Разделите причины отбора и обязательные запреты

Не каждое поле сегмента требуется пересчитывать перед каждым письмом. Интерес к категории может оставаться допустимым в течение кампании. Актуальный отказ от сообщений или истечение предложения имеют другой вес.

Составьте список критичных проверок: действующий контакт, разрешённость сообщения, новая покупка для конкретной механики, частотное ограничение, доступность предложения и аварийная остановка. Для каждого условия определите источник и допустимую давность.

Если клиент купил другой товар, это не всегда причина отменять всё сообщение. Условие остановки должно соответствовать сценарию: та же корзина, конкретная категория или любая покупка по принятому правилу.

Определите ближайшую управляемую точку

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

Попросите показать журнал с временем проверки и временем принятия сообщения каналом. Если поставщик не умеет обновлять уже сформированную очередь, возможно, придётся отправлять меньшими партиями или использовать внешнюю проверку. Цена такого решения — нагрузка, задержка и дополнительная эксплуатация.

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

Подготовьте компактное состояние для решения

Проверять полный заказ через медленный API — программный интерфейс обмена данными — на каждого из 300 тысяч получателей может оказаться дорого. Альтернатива — подготовленный набор актуальных признаков: запрет отправки, последняя подходящая покупка, версия контакта и срок действия предложения.

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

Защитите само действие от повтора

Два обработчика могут одновременно проверить одного клиента и оба решить, что отправка разрешена. Поэтому проверка счётчика и резервирование права на действие должны быть согласованы технически. Обычная последовательность «прочитал — отправил — записал» оставляет промежуток для гонки.

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

AWS описывает использование заданного клиентом ключа операции для безопасного повтора API-запроса. Для CRM подобный ключ полезен при передаче одного сообщения, но его действие ограничено конкретным интерфейсом и сроком хранения. Он не заменяет весь механизм частотных ограничений.

Условный пример утренней акции

В 09:00 собрана аудитория, в 11:20 клиент совершил подходящую покупку, в 11:22 состояние стало доступно системе проверки. Его сообщение подходит к отправке в 11:30. Повторная проверка исключает клиента и сохраняет причину.

Если запись покупки стала доступна только в 11:35, проверка в 11:30 её не увидит. В отчёте нужно различать пропущенный известный запрет и неизвестное на тот момент изменение. Для второго случая улучшение связано с задержкой данных или обращением к более свежему источнику.

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

Опишите срок действия разрешения на отправку

Если проверка создаёт временное резервирование, у него должны быть ID операции, срок действия и состояния завершения. После истечения срока нельзя безусловно передавать давно подготовленное сообщение: критичные условия могли измениться.

При ошибке до передачи резервирование можно освободить по принятому правилу. При неизвестном результате передачи сначала требуется сверка: провайдер мог принять сообщение, хотя ответ не дошёл. Иначе освобождённый лимит позволит повторить действие.

Для общей частоты email и SMS ключ и хранилище ограничений должны учитывать оба канала в согласованной области. Два независимых локальных счётчика не обеспечат общий предел. Такой механизм лучше проверить одновременными запросами, поскольку последовательный ручной тест не воспроизводит гонку.

Сохраните объяснение решения

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

Причины отказа должны различаться: уже купил, отписался, истёк оффер, данные недоступны, сработал общий лимит. Иначе маркетолог увидит только уменьшение объёма и не сможет понять, где полезное исключение, а где технический сбой.

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

Источники

Amazon Web Services. Making retries safe with idempotent APIs. Amazon Builders’ Library. Раздел Reducing client complexity with idempotent API design. Проверено 22.09.2026.