Интеллектуальное управление частотой коммуникаций с клиентами: дневные, недельные и месячные лимиты, тихие часы и контроль скорости отправки на уровне организации и канала.
Каждый маркетолог знает: больше сообщений не означает больше продаж. Исследования показывают, что 69% потребителей отписываются от бренда из-за слишком частых коммуникаций. В омниканальной среде проблема усугубляется: клиент может получить email утром, push днём, SMS вечером и Telegram-сообщение ночью -- всё от одного бренда за один день.
Без централизованного контроля частоты каждый канал и каждая кампания работают изолированно. Маркетолог запускает промо-рассылку, не зная, что клиент уже получил сегодня автоматическое уведомление из flow и транзакционное письмо. Результат -- раздражение клиента, рост отписок и жалоб на спам, снижение deliverability. По данным Return Path, бренды, превышающие оптимальную частоту на 30%, теряют до 50% engagement.
Отдельная проблема -- ночные отправки. Маркетологи планируют кампании из своего часового пояса, забывая, что клиенты в Владивостоке получат сообщение в 3 часа ночи. Это не только раздражает, но и снижает open rate в 4-5 раз по сравнению с дневной доставкой.
FrequencyService -- централизованный сервис управления частотой, построенный на Redis для мгновенной проверки и записи.
Частотные лимиты на клиента настраиваются на трёх уровнях. Дневной лимит (daily): максимальное количество сообщений клиенту за 24 часа, по умолчанию 3. Недельный лимит (weekly): максимум за 7 дней, по умолчанию 10. Месячный лимит (monthly): максимум за 30 дней, по умолчанию 30. Метод check_frequency принимает customer_id и возвращает булево значение -- можно ли отправить ещё одно сообщение.
Счётчики хранятся в Redis с автоматическим TTL: дневной ключ живёт 24 часа, недельный -- 7 дней, месячный -- 30 дней. Это обеспечивает мгновенную проверку (менее 1 мс) без нагрузки на PostgreSQL.
Тихие часы (Quiet Hours) предотвращают отправку в неудобное время. Метод is_quiet_time проверяет текущее время в часовом поясе клиента (поле timezone в профиле CDP). По умолчанию тихие часы -- с 22:00 до 8:00 по локальному времени клиента. Если сообщение попадает в тихие часы, отправка откладывается до окончания тихого периода.
Эта функция интегрирована с TimezoneDeliveryService: при планировании кампании система группирует получателей по часовым поясам и учитывает тихие часы, назначая отправку через Celery с параметром eta на ближайшее допустимое время.
Rate limiting на уровне организации контролирует скорость отправки. Метод check_rate_limit проверяет, не превышен ли лимит отправок в минуту для конкретной организации и канала. Это защищает от превышения лимитов провайдеров (Unisender -- 50/с, Telegram -- 30/с, SMS.ru -- 100/с, WhatsApp -- 80/с, Push -- 100/с) и предотвращает блокировку аккаунтов.
Метод record_send вызывается после каждой успешной отправки и инкрементирует все счётчики (дневной, недельный, месячный) в Redis одной атомарной операцией.
Интеграция с кампаниями и flows: задача execute_campaign в Celery проверяет check_frequency перед каждой отправкой. Если лимит достигнут -- клиент пропускается, но не удаляется из очереди. FlowExecutor аналогично проверяет частоту перед шагами отправки в flow.
Защита от усталости клиента: научно обоснованные лимиты на дневном, недельном и месячном уровнях предотвращают чрезмерные коммуникации. Снижение частоты отписок на 40-60% -- типичный результат после внедрения frequency capping.
Кросс-канальный учёт: FrequencyService считает все сообщения всех каналов в единых счётчиках. Email, SMS, Telegram, WhatsApp и Push -- все учитываются в общем лимите на клиента. Ни один канал не может "перегрузить" клиента в обход лимитов.
Мгновенная проверка через Redis: проверка частоты занимает менее 1 миллисекунды. При массовой рассылке на 100 000 получателей overhead составляет менее 100 секунд совокупно. Redis TTL автоматически обнуляет счётчики без cron-задач.
Тихие часы с учётом таймзоны: система знает часовой пояс каждого клиента (поле timezone в CDP) и не отправляет сообщения ночью по локальному времени. Это увеличивает open rate на 25-35% и демонстрирует уважение к клиенту.
Приоритизация сообщений: когда лимит клиента почти исчерпан, важные сообщения (транзакционные, triggered) имеют приоритет над массовыми рассылками. Маркетолог не беспокоится о блокировке критичных уведомлений.
Большинство email-платформ (Mailchimp, Unisender, SendPulse) не имеют встроенного frequency capping -- они позволяют отправить неограниченное количество сообщений одному клиенту за день. Trigly контролирует частоту на уровне платформы.
Mindbox предлагает frequency capping, но только для email-канала. Trigly контролирует все 6 каналов в едином счётчике. Exponea имеет продвинутый контроль частоты, но стоит от $50,000 в год. Trigly предоставляет сопоставимую функциональность по цене SaaS. Тихие часы с учётом часового пояса клиента -- функция, отсутствующая у 90% конкурентов на российском рынке.
E-commerce с частыми акциями: Интернет-магазин электроники проводит 3-4 акции в неделю. Без frequency capping активные клиенты получали до 15 сообщений в неделю. После настройки лимитов (3/день, 8/неделя, 25/месяц) отписки снизились с 2.1% до 0.4% за месяц, а open rate вырос с 12% до 19%. Тихие часы (22:00-9:00) устранили жалобы на ночные push-уведомления.
Финансовые услуги: Банк отправляет транзакционные уведомления, маркетинговые предложения и напоминания о платежах. Frequency capping настроен с приоритетами: транзакционные сообщения не учитываются в лимитах, маркетинговые ограничены 2/день и 5/неделя. Тихие часы -- с 21:00 до 9:00. Результат: NPS вырос на 8 пунктов, жалобы в ЦБ снизились на 60%.
Мультибрендовая компания: Холдинг с 5 брендами использует единый Trigly для всех коммуникаций. Общий месячный лимит 20 сообщений на клиента распределяется между брендами. Rate limiting защищает от одновременного запуска кампаний всеми брендами, предотвращая перегрузку SMTP-серверов и SMS-шлюзов.
FrequencyService интегрирован со всеми модулями отправки Trigly: execute_campaign проверяет лимиты перед каждым сообщением, FlowExecutor -- перед каждым шагом отправки в flow, TriggerEngine -- перед каждым триггерным сообщением. Redis хранит счётчики с автоматическим TTL. TimezoneDeliveryService использует quiet hours при планировании отправки. Все пропущенные из-за лимитов отправки логируются для аналитики. REST API позволяет настраивать лимиты через 290 эндпоинтов платформы.
Что происходит с сообщением, когда лимит достигнут? Сообщение не отправляется и не теряется. В кампании клиент помечается как suppressed (подавленный) и учитывается в метрике total_suppressed. В flow клиент переходит к следующему шагу без отправки. Маркетолог видит статистику подавленных сообщений в аналитике.
Можно ли исключить транзакционные сообщения из лимитов? Да, транзакционные кампании (campaign_type=TRIGGERED с соответствующим флагом) могут быть настроены для обхода частотных лимитов. Это гарантирует доставку критичных уведомлений (подтверждение заказа, сброс пароля) вне зависимости от маркетинговых лимитов.
Сбрасываются ли счётчики при перезагрузке Redis? Да, Redis-счётчики не персистируются между перезагрузками. После перезагрузки Redis все счётчики обнуляются. На практике это означает, что клиенты могут получить несколько дополнительных сообщений в день перезагрузки, но лимиты восстановятся в течение 24 часов.
Начните с консервативных лимитов. Установите 2-3 сообщения в день, 7-8 в неделю, 20-25 в месяц. Лучше начать строже и ослабить лимиты на основе данных, чем потерять подписчиков из-за избыточных коммуникаций.
Настройте тихие часы для каждого региона. Стандартные тихие часы 22:00-8:00 подходят для большинства бизнесов, но для B2B может быть оптимальнее 20:00-9:00, а для развлекательных сервисов — 1:00-7:00.
Разделите транзакционные и маркетинговые лимиты. Транзакционные сообщения (подтверждение заказа, сброс пароля) не должны блокироваться маркетинговыми лимитами. Настройте исключения для критичных типов кампаний.
Анализируйте suppressed-метрики. Если более 20% аудитории регулярно подавляется frequency capping, это сигнал о чрезмерном количестве кампаний. Сократите количество рассылок или расширьте лимиты на основе данных об отписках.
Отсутствие frequency capping при омниканальности. Без общих лимитов клиент может получить email, push, Telegram и SMS в один день. Каждый канал в отдельности отправляет разумное количество, но суммарно — перегрузка.
Одинаковые лимиты для всех сегментов. VIP-клиенты могут терпеть больше сообщений, чем новые подписчики. Рассмотрите разные лимиты для разных сегментов через настройку Flow Builder conditions.
Байесовское A/B тестирование с Monte Carlo симуляцией. Автовыбор победителя, калькулятор выборки, мультивариантные тесты.
Генерация email subject lines, тела писем, SMS, push-текстов с помощью AI. GPT-4 и Claude, оптимизированные для маркетинга на русском языке.
Полноценная REST API платформа с 290 эндпоинтами, JWT-аутентификацией, Redis rate limiting, SDK для фронтенда и публичными эндпоинтами для трекинга и интеграций.
Визуальный конструктор автоматических цепочек: email, SMS, Telegram, WhatsApp, push. DAG-executor, условия, ожидание, smart send.
Бесплатная интеграция. Все функции доступны с первого дня. Гарантия окупаемости.
Записаться на аудит