Лимит сообщений клиенту: скользящее окно и общий счётчик кампаний

Определите, какие сообщения конкурируют за лимит

Этот разбор касается нескольких самостоятельных коммерческих сообщений. У них разные основания и содержание; ни одно не является техническим повтором другого. Защита от повторной отправки одного события остаётся отдельным процессом, описанным в руководстве по актуальности уведомлений.

Владелец коммуникаций определяет область ограничения: организацию или подразделение, канал, контактную точку и виды сообщений. Затем выбирает время наблюдения и событие, которое занимает лимит. Без этих определений число «два» не задаёт проверяемое правило.

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

Календарный день и последние 24 часа дают разные ответы

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

Microsoft Customer Insights — Journeys документирует rolling-окна 24 часа, семь и 30 дней. Счётчик относится к contact point: email-адресу, телефону для text или entity ID для push; настройки создаются в области business unit. Microsoft: frequency capping.

При настройке своей системы не называйте 30 дней календарным месяцем. Укажите точность времени и правило на самой границе окна. Если два отчёта используют разные определения, одинаковый заголовок «месячный лимит» не делает их взаимозаменяемыми.

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

Учебный пример: четыре новых кандидата

Все записи синтетические. Рассматриваются один точный email-адрес, один канал и одна область business unit. Собственная политика допускает не более двух коммерческих отправок за предшествующие 24 часа. Настройка действует до всех событий примера. Проверки предпочтений и актуальности пройдены отдельно; после допуска отправка подтверждается.

Исходная история содержит два разных письма: M1 отправлено 9 октября 2026 года в 09:00 UTC, M2 — в 20:00 UTC. Далее появляются четыре самостоятельных кандидата из разных кампаний. Подавленный кандидат не заменяется повтором под новым именем.

M3 подготовлено 10 октября в 00:10. За предыдущие 24 часа в истории остаются M1 и M2: две отправки. Новое письмо подавляется. Наступление нового календарного дня не изменило этот результат.

M4 появляется 10 октября в 09:01. Письмо M1 старше 24 часов и вышло из окна. В нём остаётся только M2. Есть одно свободное место: M4 допускается и отправляется. После подтверждения в окне снова две отправки, M2 и M4.

M5 появляется в 10:00 того же дня. Обе эти записи всё ещё находятся внутри последних 24 часов. M5 подавляется. Отсутствие доставленного M3 не даёт дополнительного места: M3 вообще не было отправлено и не занимало счётчик.

M6 появляется в 20:01. Теперь M2 также старше 24 часов. В окне остаётся M4, поэтому M6 допускается и отправляется. По четырём новым кандидатам получились два допуска и два подавления. Вместе с исходной историей отправлены четыре письма за весь рассмотренный промежуток.

Это не четыре письма внутри одних 24 часов. После каждой подтверждённой отправки в соответствующем скользящем окне их не больше двух. Основные проверки отстоят от точной границы на минуту; случай ровно через 24 часа нужно испытать отдельно по принятой точности.

Объедините историю разных кампаний

Если каждая кампания получает собственную квоту «два письма этому адресу», две кампании смогут отправить четыре. Это другая политика. Для общего ограничения решение должно учитывать всю относящуюся к его области историю, а не только сообщения текущего сценария.

Две CRM-карточки с одним и тем же точным email-адресом также не создают два независимых счётчика contact point. Однако такой контроль не доказывает, что карточки принадлежат одному человеку, и не разрешает объединять клиентские истории.

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

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

Подавление не является обещанием отправить позже

В описанном Microsoft-процессе достигнутая квота блокирует сообщение, а участник продолжает journey. Это не автоматическое ожидание освобождения места для того же письма. Microsoft: поведение после достижения cap.

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

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

Проверьте состав счётчика и момент включения

В Journeys учитываются отправленные commercial messages; transactional исключены. Сообщения, отправленные до включения соответствующего cap, не входят в его счётчик. Пустое значение не устанавливает ограничение, а нулевое не поддерживается. Это конкретные правила продукта, которые важно сохранить при сопоставлении настроек. Microsoft: состав и настройка лимита.

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

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

Данные и приёмочный чек-лист

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

1. В 00:10 новый день не обнуляет две вчерашние отправки.
2. В 09:01 выходит только M1, и M4 занимает освободившееся место.
3. В 10:00 M5 подавляется; в 20:01 M6 допускается.
4. Разные кампании используют общую историю выбранной области.
5. Подавление не увеличивает отправки и не обещает автоматическую отсрочку.
6. Две карточки с одним contact point не удваивают квоту.
7. Конкурентные кандидаты не превышают согласованный итоговый предел.
8. Включение cap, пустое значение и точная граница окна испытаны отдельно.

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

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

Два письма в сутки — оптимальная частота?

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

После полуночи можно отправлять снова?

При скользящих 24 часах решение зависит от предыдущих отправок. Новая дата не означает новое свободное окно.

Подавленное письмо уйдёт, когда освободится место?

Не обязательно. В приведённом Microsoft-поведении оно пропускается, а journey продолжается. Отсрочка требует отдельно подтверждённого процесса.

Источник

• Microsoft Customer Insights — Journeys: Set up frequency capping.

Проверено 9 октября 2026 года. Лимит и последовательность M1–M6 являются учебными.