Что делает MAP
Marketing Automation Platform — система, которая исполняет маркетинговую логику: решает, какое сообщение получит конкретный контакт, в каком канале и в какой момент. Всё остальное в ней обслуживает эту задачу.
| Функциональный блок | Что внутри |
|---|---|
| Конструктор сценариев | Визуальная цепочка с ветвлениями, задержками, условиями и ожиданием события |
| Триггеры | Запуск сценария по действию или бездействию: событие на сайте, попадание в сегмент, дата, изменение атрибута |
| Оркестрация каналов | Выбор канала и порядка обращений, ограничение частоты, правила приоритета между кампаниями |
| Управление кампаниями | Календарь, аудитории, согласования, запуск и остановка, контрольные группы |
| Скоринг | Оценка контакта по действиям и атрибутам — для приоритизации и выбора ветки сценария |
| Отчётность | Метрики кампаний и сценариев: доставляемость, открытия, переходы, конверсии, вклад в выручку |
Ключевое слово здесь — сценарий. Разовая рассылка по списку — это ещё не автоматизация; MAP начинается там, где появляются цепочки, реагирующие на поведение: drip-кампании, реактивация, работа с брошенными действиями, программы по стадиям жизненного цикла клиента.
Разграничение классов систем
Самая частая путаница на пресейле — считать MAP, CDP, ESP, CRM и платформу персонализации альтернативами друг другу. Это разные слои одного стека, и почти в любом зрелом e-commerce присутствуют все пять — иногда внутри одного продукта, иногда в виде отдельных систем.
| Что хранит | Чем управляет | Где живёт контент | Типичный владелец | |
|---|---|---|---|---|
| MAP | Контакты, сегменты, состояния в сценариях, история коммуникаций | Логикой коммуникаций: кому, когда, по какому условию | Шаблоны сообщений и сценарии внутри системы | CRM-маркетолог, руководитель CRM-направления |
| CDP | Сырые события, идентификаторы, объединённые профили | Данными: сбор, разрешение личностей, сегментация, передача сегментов в другие системы | Контента нет — только данные и аудитории | Аналитик, продуктолог, data-команда |
| ESP | Адреса, статусы доставки, отписки, репутация домена | Транспортом: доставка сообщения в канал | Шаблоны писем | CRM-маркетолог, технический специалист по доставке |
| CRM | Клиенты, сделки, обращения, история отношений | Отношениями и продажами, а не рассылками | Контента для маркетинга обычно нет | Отдел продаж, клиентский сервис |
| Платформа персонализации | Поведенческий профиль, события просмотров, каталог товаров | Опытом на сайте и в приложении в момент визита | Рекомендательные блоки, баннеры, попапы, диалоги | Head of E-com, продуктолог, маркетинг сайта |
Разница между CDP и MAP формулируется одной фразой: CDP отвечает на вопрос «кто это», MAP — на вопрос «что с ним сделать». Разница между MAP и ESP — ещё проще: ESP умеет отправить, MAP решает, что и когда отправлять. Граница подвижна, потому что вендоры расширяют функциональность в обе стороны, но при проектировании стека полезно держать роли раздельно, даже если технически они реализованы в одном продукте.
Как это стыкуется в реальном стеке
Типовая схема потоков данных в e-commerce выглядит так:
Сайт / приложение
│ события: просмотры, клики, корзина, заказ
▼
CDP / слой данных ──── сегменты ────► MAP ──── сообщения ────► ESP / канал
│ │
│ профиль, аудитории │ состояние контакта, статусы кампаний
▼ ▼
Платформа персонализации CRM
│ контент, порядок товаров,
▼ рекомендательные блоки
Сайт / приложение
Направление обмена важнее, чем набор систем. На практике устойчиво работают четыре связки:
- События сайта → MAP. Действие пользователя запускает сценарий. Это классический event-based триггер: чтобы он был возможен, платформа, собирающая поведение на сайте, должна уметь отдавать события наружу.
- Сегменты MAP → сайт. Принадлежность к сегменту используется для выбора контента на сайте — человек из сегмента «оформил заказ на этой неделе» не должен видеть попап для новых клиентов.
- Профиль персонализации → контент в чужих каналах. Персональные товарные блоки формируются платформой персонализации, а доставляются той системой, которая уже работает у компании.
- Заказы CRM → MAP и CDP. Факт покупки закрывает сценарии, обновляет сегменты и обнуляет счётчики частоты.
Где возникают конфликты
| Зона | Симптом | Что делать |
|---|---|---|
| Дублирование сегментации | Один и тот же сегмент собран в CDP и в MAP, цифры расходятся | Зафиксировать источник истины по сегментам; вторая система только принимает готовые аудитории |
| Несколько трекеров событий | Разные системы показывают разное число сессий и заказов | Единый слой сбора событий, остальные системы получают данные из него |
| Конфликт частоты | Пользователь получает несколько коммуникаций подряд от разных сценариев | Общие правила частоты и приоритета на уровне оркестратора, а не внутри каждой кампании |
| Спор о владении данными | Профиль клиента расходится между CRM, CDP и MAP | Явная модель: где ведётся идентификатор, где — контактные данные, где — согласия |
| Атрибуция результата | Каждая система приписывает выручку себе, сумма превышает фактическую | Единая модель атрибуции и общие контрольные группы вместо внутренних отчётов каждой системы |
Наличие в компании MAP не отменяет необходимости в аналитике, а наличие CDP не отменяет необходимости в MAP. Признак здорового стека — не минимальное число систем, а отсутствие сущностей, которые ведутся одновременно в двух местах.
Граница с онсайт-персонализацией
Это разграничение стоит проговаривать явно, потому что именно здесь чаще всего возникают ложные ожидания при выборе поставщика.
Платформа персонализации не подменяет MAP. Она отвечает за то, что происходит с человеком в момент визита: порядок товаров в категории, состав рекомендательных блоков, контент баннеров и попапов, поведение диалогового ассистента, содержимое экранов мобильного приложения. Её горизонт — текущая сессия и накопленный поведенческий профиль.
MAP отвечает за то, что происходит между визитами — исходящие коммуникации, их последовательность и каналы. Это отдельный класс систем со своей инфраструктурой доставки и своими требованиями к согласиям.
| Вопрос | Кто отвечает |
|---|---|
| Какие товары показать в блоке на карточке | Платформа персонализации |
| В каком порядке отсортировать категорию | Платформа персонализации |
| Показывать ли попап и какой | Платформа персонализации |
| Через сколько часов после брошенной корзины напомнить и в каком канале | MAP |
| Как построить цепочку по стадиям жизненного цикла | MAP |
| Кто попадает в аудиторию сценария | CDP или MAP, в зависимости от архитектуры |
Пересечение между слоями лежит в области данных, а не функций: события с сайта питают сценарии, сегменты влияют на контент, а персонализация содержимого работает в обоих направлениях — на сайте её применяет платформа персонализации, а для внешних каналов она может отдавать готовые персональные блоки той системе, которая эти каналы обслуживает.
Чек-лист при проектировании стека
- Выписать сущности, а не системы. Профиль, идентификаторы, согласия, сегменты, события, шаблоны, правила частоты — и напротив каждой указать одну систему-владельца.
- Проверить, где обрывается поток. Самая частая дыра — события сайта, которые никуда не уходят, из-за чего сценарии строятся только на данных о заказах.
- Определить правила частоты глобально, а не внутри каждой кампании.
- Согласовать модель атрибуции до запуска, иначе отчёты систем будут суммарно приписывать себе больше выручки, чем есть.
- Заложить контрольные группы на уровне стека — единственный способ отделить эффект коммуникаций от эффекта онсайт-персонализации.
- Не покупать дублирующую функциональность ради одной недостающей функции: чаще дешевле достроить обмен данными между тем, что уже есть.