Когда бизнесу достаточно ESP и пока не нужна CDP

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

В обсуждении обычно фигурируют два класса решений. ESP (Email Service Provider) — сервис для подготовки и отправки email-рассылок. Он может хранить контакты, делить получателей на группы и запускать автоматические цепочки писем. CDP (Customer Data Platform) — платформа клиентских данных: она собирает сведения из разных источников, объединяет записи об одном клиенте в профиль — связанную запись с его контактами и историей — и делает эти данные доступными другим системам. Именно постоянную объединённую базу и доступность данных за пределами платформы выделяет в определении CDP Institute. [1]

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

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

Сначала найдите ограничение действующего процесса

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

Если ESP поддерживает нужную цепочку, но магазин передаёт покупки раз в неделю, проблема находится в обмене данными. Замена ESP на CDP без изменения обмена сохранит ту же задержку. Если же покупки хранятся в пяти системах под разными идентификаторами, сначала потребуется способ сопоставлять записи об одном человеке.

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

Проверьте достаточность ESP на реальных сценариях

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

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

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

В каких случаях можно отложить CDP

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

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

Однако «у нас всё работает на скриптах» тоже требует проверки. Кто восстановит обмен, если автор скрипта недоступен? Есть ли журнал ошибок, документация и актуальная копия настроек? Система, которая выполняет задачу только при постоянном ручном участии одного человека, имеет стоимость и ограничение, даже если отдельной лицензии нет.

Какие признаки говорят в пользу общего слоя данных

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

Здесь возможны разные решения. Помимо готовой CDP, компания может использовать аналитическое хранилище — общую систему хранения данных из разных источников — с подготовленными таблицами о клиентах и сервисом передачи результатов в каналы. Например, документация сервиса Hightouch описывает связку источника, подготовленного набора данных и синхронизации — передачи изменений в целевую систему. [2] Это один из вариантов устройства обмена, а не доказательство его преимущества для любого бизнеса.

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

Условный расчёт для небольшого ретейлера

У магазина 180 тысяч доступных для коммуникации профилей, одна кассовая система и шесть работающих email-сценариев. Есть две проблемы: офлайн-покупки приходят с задержкой, а сегменты готовятся вручную. Все суммы далее условные, без НДС, на один год. Одинаковые для вариантов расходы на отправки исключены из сравнения.

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

Чтобы покрыть разницу при вкладе дополнительного заказа 700 рублей, CDP должна обеспечить примерно 2 029 дополнительных заказов за год по сравнению с вариантом доработки. Вклад здесь — выручка заказа после скидок и возвратов за вычетом согласованных переменных расходов. Такие расходы меняются с числом и составом заказов: например, себестоимость товара, комиссия за оплату и затраты на комплектацию. Это порог окупаемости, а не прогноз результата и не основание приписывать платформе все заказы из рассылок.

Зафиксируйте решение вместе с условиями пересмотра

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

Не устанавливайте универсальный порог вроде «после 100 тысяч клиентов нужна CDP». Для выбора важнее устройство процессов и цена ограничений. Хорошее решение позволяет выполнять утверждённые задачи, объясняет будущие расходы и сохраняет возможность перейти к более сложной архитектуре, когда появится подтверждённая потребность.

Источники

[1] CDP Institute. What is a Customer Data Platform (CDP)? Описание требований к CDP.

[2] Hightouch. Data activation concepts. Техническая документация.