Когда стоит строить CDP на основе хранилища данных

У компании уже может быть хранилище данных, в котором аналитики собирают покупки, возвраты и действия клиентов на сайте. Маркетинг при этом готовит аудитории отдельно, а новую платформу клиентских данных (CDP) предлагают купить в том числе ради объединения той же информации. Возникает разумный вопрос: можно ли использовать уже построенное хранилище и не создавать ещё одну независимую базу?

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

Подход, при котором нужные функции собирают из совместимых компонентов, называют composable CDP. В рассматриваемом варианте это хранилище, правила построения клиентского профиля, инструменты выбора аудитории, передачи данных и коммуникаций. Клиентский профиль здесь — связанная запись о человеке: его контакты, покупки и другие сведения, необходимые для конкретной задачи.

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

Что меняется для маркетолога

BI (Business Intelligence) — инструменты анализа данных и подготовки отчётов. При такой работе аналитик готовит отчёт, а человек изучает результат. В CRM на основе тех же данных система совершает действие: включает клиента в цепочку, исключает из акции, отправляет предложение. Ошибка в таблице теперь может затронуть клиента до того, как её заметит аналитик.

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

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

Из каких частей состоит рабочая схема

Хранилище принимает исходные данные. Поверх них создаются подготовленные таблицы — модели: например, одна строка на клиента с датой последней покупки и признаком участия в программе. Инструмент передачи данных отправляет изменения в ESP — сервис email-рассылок — или другую систему коммуникаций. Коммуникационная система применяет доступные ей ограничения и выполняет сценарий.

В документации сервиса Hightouch модель также описана как повторно используемый набор данных с уникальным первичным ключом. [1] Ключ — значение, по которому можно однозначно найти строку; например, постоянный код клиента, или ID. Синхронизация передаёт изменения этого набора в целевую систему. Так можно предметно обсудить, какая строка соответствует клиенту, какие значения меняются и куда они попадут.

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

Какие требования предъявить к моделям данных

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

Зафиксируйте определения признаков. «Последняя покупка» может означать созданный, оплаченный или доставленный заказ. Для повторного предложения обычно важен определённый статус, но конкретное правило зависит от бизнеса. Рядом с признаком полезно хранить время расчёта и версию логики, чтобы объяснить решение задним числом.

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

Почему расходы на хранилище могут вырасти

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

Например, Hightouch описывает разные варианты выполнения сравнения изменений: на своей инфраструктуре либо внутри хранилища при использовании Lightning Sync Engine — собственного механизма определения и передачи изменений. [2] Из этого следует практический вопрос к поставщику: где именно выполняются вычисления, что сохраняется вне хранилища и кто оплачивает эти операции? Ответ зависит от конфигурации.

Не переносите на весь класс продуктов тезис «данные никогда не покидают наше хранилище». Чтобы отправить письмо, контакты и необходимые признаки всё равно должны стать доступны системе отправки. Отдельно проверяются служебные журналы, промежуточные копии и сроки их хранения.

Условный пример оценки готовности

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

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

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

Сравнение затрат тоже ведётся по конкретному набору задач. В условном месячном бюджете сервис передачи данных стоит 120 тысяч рублей, дополнительные вычисления — 40 тысяч, сопровождение — 100 тысяч. Совокупные 260 тысяч нужно сравнивать с альтернативой, которая обеспечивает те же сценарии и сроки, а не только с её лицензией.

Когда такой подход будет неудобен

Если у хранилища нет стабильной клиентской модели, каждую аудиторию собирают новым запросом, а исправления ждут несколько недель, composable-подход перенесёт эти трудности в CRM. Маркетинг получит ещё один интерфейс, но сохранит зависимость от ручной подготовки данных.

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

С чего начать проверку

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

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

Источники

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

[2] Hightouch. Lightning sync engine. Техническая документация.