Сложнее становится позже. Клиентов становится больше, каналов — тоже, а маркетинговых сценариев накапливаются десятки. Один человек может одновременно попасть в несколько сегментов, получить два разных предложения в течение часа и ещё одно сообщение в другом канале. При этом каждая система будет считать, что действует совершенно независимо от остальных.
В какой-то момент проблема перестаёт быть задачей отправки сообщений. Нужно уже не столько научиться быстро отправлять, сколько научиться принимать решение: нужно ли вообще сейчас обращаться к этому человеку, каким способом это сделать и что именно ему показать.
Именно с этой задачи мы исходили, когда проектировали коммуникационный модуль внутри собственной CDP.
Почему отдельный сервис рассылок начинает мешать
У классической рассылки достаточно понятная схема: сформировали список адресатов, подготовили письмо, отправили.
Для небольшой базы этого достаточно. Но при росте аудитории вокруг одного сообщения появляется множество дополнительных условий.
- Есть ли у клиента согласие на соответствующие коммуникации?
- Получал ли он недавно похожее сообщение?
- Не находится ли он в стоп-листе?
- Подходит ли ему выбранный канал?
- Не было ли уже успешного контакта через другой канал?
- Не пересекается ли новая кампания с другой активной кампанией?
- Можно ли сейчас безопасно увеличивать объём отправки?
Если ответы на эти вопросы находятся в разных системах, коммуникация быстро превращается в набор исключений и ручных проверок.
Поэтому мы рассматриваем отправку не как самостоятельный сервис, а как один из процессов внутри CDP. Источником решения становится единый профиль клиента, а сама отправка — последним этапом длинной цепочки.
Сначала клиент, потом сообщение
Ключевое изменение в такой архитектуре довольно простое: мы перестаём мыслить списками email-адресов и идентификаторов чатов.
В центре находится профиль клиента. В нём могут быть собраны сведения о покупках, действиях на сайте, сегментах, обращениях в поддержку, предыдущих коммуникациях, подписках и согласиях.
Это позволяет смотреть на кампанию с другой стороны.
Допустим, пользователь несколько минут назад получил push-уведомление и перешёл по нему на сайт. Отправлять ему вслед ещё одно письмо только потому, что он формально подходит под сегмент, уже не обязательно.
Или другой сценарий: основной канал недоступен, поэтому система может выбрать альтернативный способ коммуникации — если это разрешено настройками клиента и правилами конкретного сценария.
Так появляется омниканальность без необходимости вручную синхронизировать несколько независимых рассылок.
Коммуникация должна учитывать согласия
Для системы коммуникаций недостаточно знать, какие контакты есть у клиента. Нужно понимать, что именно компания вправе ему отправлять.
В России работа с персональными данными регулируется, в частности, Федеральным законом № 152-ФЗ. Для рекламных коммуникаций законодательство устанавливает отдельные требования к предварительному согласию и прекращению обработки по требованию субъекта. Поэтому информацию о согласиях нельзя оставлять только на уровне интерфейса маркетинговой платформы — она должна участвовать непосредственно в принятии решения об отправке.
В практической реализации это означает, что перед постановкой сообщения в очередь система проверяет:
- наличие необходимого согласия;
- канал, на который распространяется разрешение;
- статус подписки;
- глобальные и локальные исключения;
- ограничения частоты;
- возможность повторной отправки конкретного сообщения.
Причём важно сохранять не только факт исключения пользователя, но и причину. Иначе спустя месяц будет трудно ответить на простой вопрос: почему из кампании исчезли несколько тысяч человек?
Между сегментом и API нужен ещё один слой
Одна из распространённых ошибок — считать, что после формирования аудитории можно сразу обращаться к API канала.
В реальной системе между этими событиями должен находиться планировщик.
Упрощённо процесс можно представить так:
- формируется аудитория;
- проверяется право на коммуникацию;
- отбирается подходящий канал;
- создаётся сообщение;
- формируется очередь;
- определяется скорость отправки;
- запрос передаётся конкретному каналу;
- результат возвращается в систему коммуникаций.
Каждый этап лучше держать отдельно. Тогда изменение одного канала не заставляет переписывать всю систему, а временная проблема с API не останавливает обработку кампании целиком.
Массовая отправка — это очередь, а не цикл
На небольшом объёме легко написать код, который перебирает получателей и последовательно вызывает API. Проблемы начинаются тогда, когда получателей становится много.
У внешних платформ существуют ограничения по частоте запросов и собственные механизмы защиты от злоупотреблений. Telegram, например, возвращает информацию о необходимости подождать при превышении flood control, а Bot API использует HTTP 429 для ряда ситуаций с превышением ограничений.
Поэтому отправка должна быть управляемой.
Вместо команды «отправить всё» система формирует очередь и постепенно её обрабатывает. Для разных каналов можно задать собственные ограничения, а скорость менять в зависимости от ответов внешнего API.
Если канал сообщает, что запросов слишком много, следующий шаг — не повторить тот же запрос ещё десять раз. Система должна остановиться на необходимое время и затем продолжить работу.
В Telegram для этого, в частности, предусмотрен параметр retry_after, который указывает, сколько секунд следует подождать перед повторной попыткой.
Повторные попытки должны быть осмысленными
Не всякая ошибка означает одно и то же.
Временный сетевой сбой, превышение лимита, недействительный идентификатор получателя и окончательный отказ канала — четыре разных ситуации. Отправочный сервис должен их различать.
Для этого мы разделяем ошибки на несколько классов:
- временные — запрос можно повторить;
- ограничения канала — необходимо подождать и снизить скорость;
- ошибки данных — повторная попытка ничего не изменит;
- окончательные отказы — получатель или канал больше недоступен для этого сценария.
Такой подход одновременно снижает нагрузку на внешние API и делает состояние очереди предсказуемым.
Один интерфейс для разных каналов
Email, Telegram и VK отличаются и API, и моделью доставки, и набором доступных событий. Если встроить всю специфику непосредственно в бизнес-логику CDP, система очень быстро превратится в набор условных операторов.
Мы поэтому разделяем общий процесс и конкретные адаптеры каналов.
Условно каждый адаптер отвечает за четыре вещи:
- проверку возможности отправки;
- преобразование внутреннего сообщения в формат канала;
- вызов внешнего API;
- приведение ответа к общему формату.
Например, для email это могут быть события доставки, отказа и жалобы. Для мессенджера — успешная отправка, ошибка API или недоступность чата.
Внутри CDP эти различия уже не должны иметь большого значения. Остальная система получает нормализованное событие и работает с ним одинаково.
Не всем клиентам нужно отправлять одно и то же
Ещё один важный момент — частота контактов.
Даже технически успешная коммуникация может оказаться плохой с точки зрения пользовательского опыта. Если клиент получил несколько маркетинговых сообщений за короткий промежуток времени, очередное письмо вряд ли станет полезнее только потому, что оно было правильно сформировано.
Поэтому ограничения частоты должны быть частью платформы, а не отдельной договорённостью между маркетологами.
Можно установить, например:
- максимальное количество маркетинговых сообщений за период;
- паузу между сообщениями одного типа;
- приоритет транзакционных сообщений над маркетинговыми;
- правило отмены менее важной коммуникации после успешного контакта по более приоритетному сценарию.
В результате маркетинговая кампания перестаёт существовать сама по себе. Она становится одним из событий в общей истории взаимодействия с клиентом.
Тестовый запуск лучше полной отправки
Большую кампанию необязательно сразу запускать на всей аудитории.
Для новых сценариев разумнее сначала использовать небольшую тестовую группу. На ней можно проверить доставляемость, корректность шаблона, работу ссылок, нагрузку на канал и первые пользовательские реакции.
Если результаты нормальные, объём постепенно увеличивается.
Здесь важен не сам процент первой волны, а принцип: ошибка должна быть обнаружена на небольшом количестве получателей, а не после отправки всей кампании.
Что нужно видеть после запуска
Хорошая коммуникационная система не заканчивается на кнопке «Запустить».
После старта маркетологу и разработчику необходимо понимать, что произошло с аудиторией.
- Сколько клиентов вошло в исходный сегмент?
- Сколько было исключено?
- По каким причинам произошли исключения?
- Сколько сообщений поставлено в очередь?
- Сколько реально отправлено?
- Сколько доставлено?
- Какие ошибки вернул канал?
- Где пришлось снизить скорость?
- Сколько клиентов отписалось после кампании?
Эти данные нужны не только для отчётности. Они помогают находить проблемы в самой логике коммуникаций.
Например, если из десяти тысяч потенциальных получателей семь тысяч регулярно исключаются из-за одного и того же правила, возможно, проблема находится не в кампании, а в настройках сегмента или модели согласий.
Что меняется в архитектуре CDP
В такой модели коммуникации перестают быть отдельным приложением, которое получает список контактов и что-то с ним делает.
Они становятся связующим звеном между данными о клиенте и конкретным действием.
CDP знает контекст: кто этот человек, что он уже делал, к каким сегментам относится, какие каналы ему доступны и какие ограничения действуют сейчас. Коммуникационный модуль использует этот контекст, чтобы подготовить конкретное действие.
Именно здесь появляется практический смысл CDP: данные не просто хранятся в едином профиле, а участвуют в принятии решений.
Что мы получили в итоге
Главный результат такого подхода — не возможность отправить больше сообщений в единицу времени.
Мы получили единый механизм, через который можно запускать разные сценарии коммуникации и при этом не размножать бизнес-логику для каждого нового канала.
Добавление нового канала сводится в основном к созданию адаптера. Новое ограничение можно добавить на уровне правил. Новая кампания использует уже существующие проверки согласий, частоты и истории контактов.
При этом сама отправка остаётся контролируемой: сообщения проходят через очередь, ошибки классифицируются, ограничения внешних платформ учитываются, а результат каждого шага возвращается обратно в CDP.
На текущий момент это, на наш взгляд, гораздо более практичная модель, чем набор независимых инструментов для рассылок. Email, push и мессенджеры могут оставаться разными каналами с разными техническими ограничениями. Но решение о том, кому и зачем отправлять сообщение, лучше принимать в одном месте.
flowchart TD
A["CDP"] --> B["Профиль клиента"]
B --> C["Сегмент / событие"]
C --> D["Правила коммуникации
Согласия
Частота отправки"]
D --> E["Выбор канала"]
E --> F["Формирование сообщения"]
F --> G["Очередь"]
G --> H["Управление скоростью"]
H --> I["Обработка ошибок"]
I --> J["Адаптеры каналов"]
J --> K["Email"]
J --> L["Telegram"]
J --> M["VK"]
J --> N["Push"]
J --> O["Другие каналы"]
K --> P["Delivery Events"]
L --> P
M --> P
N --> P
O --> P
P --> Q["CDP"]
Q -.-> B
classDef cdp fill:#E8F0FE,stroke:#4285F4,color:#1A1A1A
classDef logic fill:#EAF7EE,stroke:#34A853,color:#1A1A1A
classDef delivery fill:#FFF4E5,stroke:#FB8C00,color:#1A1A1A
classDef channel fill:#F3E8FD,stroke:#9C27B0,color:#1A1A1A
class A,B,Q cdp
class C,D,E,F logic
class G,H,I,J,P delivery
class K,L,M,N,O channel
В конечном счёте коммуникационная платформа нужна не для того, чтобы отправлять как можно больше сообщений. Её задача — помочь компании не отправлять лишнее, вовремя доставлять нужное и понимать, что произошло после контакта.
