Одна из самых понятных идей при внедрении CDP звучит так: если платформа должна собирать клиентские данные, значит, нужно передать в неё всё, что у компании есть. CRM, сайт, приложение, кассы, программу лояльности, рекламные кабинеты, коллтрекинг, обращения в поддержку, историю рассылок — чем больше источников, тем полнее профиль клиента.
На практике такой подход легко превращает старт проекта в бесконечную интеграцию. Команда месяцами собирает данные «на будущее», пытается привести к единому виду десятки полей и событий, а первые полезные сценарии всё откладываются.
CDP действительно ценна тем, что объединяет данные из разных систем. Но на старте важнее не максимальный объём информации, а другой вопрос: «Какие данные нужны, чтобы решить первые конкретные задачи бизнеса?»
Начинать лучше не с источников, а со сценариев
Список доступных систем сам по себе мало что говорит о приоритетах. Можно подключить десять источников и при этом не получить данных, необходимых для одного важного маркетингового сценария.
Допустим, компания хочет возвращать клиентов, которые перестали покупать. Для такого сценария ей в первую очередь нужны идентификатор клиента, история заказов, дата последней покупки, возможно, категории и сумма покупок. Если всё это уже есть в CRM и системе заказов, подключение рекламного кабинета или истории звонков в первый этап ничего принципиально не добавит.
Другой сценарий — работа с брошенным просмотром товара. Здесь уже недостаточно истории транзакций: понадобятся события сайта или приложения, идентификация пользователя, карточки просмотренных товаров и время последних действий. Поэтому полезнее идти от вопроса «что мы хотим сделать с этими данными?», а не от вопроса «что ещё можно загрузить в CDP?»
Базовый профиль клиента нужен почти всегда
Несмотря на различия между бизнесами, есть набор данных, без которого большинству CDP-проектов трудно обойтись.
В первую очередь это идентификаторы: внутренний ID клиента, email, телефон, номер карты лояльности или другие признаки, по которым компания связывает действия одного человека между системами. Именно они позволяют собрать разрозненные записи в единый профиль.
К ним обычно добавляются базовые атрибуты, если они действительно используются в маркетинге: имя, город, язык, дата рождения, статус программы лояльности, дата регистрации. При этом само наличие поля ещё не делает его обязательным.
Если маркетинг не использует пол клиента ни в сегментации, ни в персонализации, нет необходимости превращать его очистку и заполнение в отдельный проект только потому, что «так принято хранить профиль».
CDP не становится полезнее от количества заполненных колонок. Полезность появляется тогда, когда данные влияют на решение или сценарий.
История покупок обычно даёт больше, чем длинная анкета
Для бизнеса с повторными продажами транзакционные данные часто становятся одним из самых ценных источников на старте. Важно понимать не только факт покупки, но и её контекст: дату, сумму, состав заказа, категорию товаров, статус заказа, скидку, канал покупки. Уже из этого можно строить сегменты по давности и частоте покупок, оценивать ценность клиентов, выделять интерес к категориям и запускать множество базовых CRM-сценариев.
При этом длинный набор анкетных характеристик может оказаться менее полезным. Компания может знать возраст, должность и семейное положение клиента, но не видеть, когда он покупал в последний раз и что именно выбрал.
В CRM-маркетинге поведение часто информативнее декларативных характеристик. Клиент может однажды указать интерес к одной категории, а следующие два года покупать совершенно другую. Поэтому на старте имеет смысл отдавать приоритет данным, которые показывают, что клиент реально делает, а не просто описывают его в профиле.
Поведение до покупки нужно не каждому проекту сразу
Просмотры страниц, поиск, клики по категориям, добавление в избранное, корзина, использование фильтров — всё это делает профиль клиента богаче. Такие данные позволяют реагировать не только после покупки, но и раньше, когда интерес ещё формируется.
Но подключать весь поток веб-событий в первый день нужно не всегда.
Если первые задачи CDP связаны с повторными продажами, реактивацией или сегментацией действующих клиентов, компании может быть достаточно качественной истории заказов. Сбор десятков событий сайта усложнит внедрение, но не обязательно ускорит получение результата.
И наоборот, для бизнеса с длинным циклом выбора транзакций может быть слишком мало. Например, клиент может неделями изучать предложения до первого обращения, и именно поведенческие данные дают маркетингу понимание его интересов. Ценность источника зависит не от того, насколько он «продвинутый», а от того, насколько он нужен конкретному сценарию.
Не каждое событие стоит передавать в CDP
Когда начинается настройка событий сайта или приложения, появляется соблазн фиксировать всё. Открытие страницы, движение по меню, нажатие на каждую кнопку, прокрутку, закрытие баннера, изменение фильтра — технически собрать можно очень многое. Но чем больше событий, тем сложнее поддерживать их качество и понимать, что они означают.
Хороший вопрос для каждого события: «Какое решение мы сможем принять благодаря этой информации?»
Просмотр карточки товара может быть полезен для определения интереса. Добавление в корзину — для триггерного сценария. Отправка формы — для фиксации более сильного намерения. А случайный клик по второстепенному элементу интерфейса может годами лежать в системе и не использоваться ни в одном сегменте, отчёте или сценарии.
События лучше проектировать как часть маркетинговой модели данных, а не как архив всей активности пользователя.
Для маркетинга важен не только факт, но и время события
Данные без временного контекста быстро теряют смысл. Сам по себе факт, что клиент интересовался смартфонами, мало помогает маркетингу. Если это было два часа назад, интерес может быть очень актуальным. Если два года назад — скорее всего, уже нет.
Поэтому для покупок, просмотров, обращений, переходов между сегментами и других важных событий нужна дата и время. Именно временная составляющая позволяет отличить активный интерес от исторического следа.
Это особенно важно для динамической сегментации. Условия вроде «просматривал категорию в последние семь дней» или «не покупал 90 дней» невозможно построить, если система хранит только сам факт действия. CDP должна понимать не только что произошло, но и когда это произошло.
Статусы не менее важны, чем сами действия
История заказа без его статуса может создавать неправильные выводы. Оформленный заказ ещё не означает завершённую покупку: его могли отменить, вернуть или не оплатить.
Если маркетинг считает все созданные заказы успешными, клиент может попасть в неверный сегмент. Система решит, что он недавно купил товар, хотя заказ был отменён, и перестанет показывать ему актуальные предложения.
То же самое касается лидов, обращений, подписок и других сущностей. Важно передавать не только появление события, но и его дальнейшее состояние, если оно влияет на маркетинговые решения.
В некоторых сценариях именно изменение статуса является главным триггером.
История коммуникаций нужна, чтобы маркетинг не разговаривал вслепую
Если CDP знает всё о покупках клиента, но ничего не знает о собственных сообщениях компании, картина остаётся неполной. Полезно понимать, какие письма, push-уведомления или SMS уже отправлялись, когда это происходило и как человек на них реагировал. Эти данные нужны не только для аналитики отдельных кампаний, но и для контроля общей коммуникации.
Без истории контактов сложно ограничивать маркетинговое давление. Один сценарий может не знать, что клиент только что получил сообщение из другого. Не обязательно переносить в CDP каждую техническую деталь доставки. Но информация, которая влияет на частоту, приоритеты и выбор канала, обычно имеет практическую ценность.
Согласия и ограничения — тоже данные
Маркетинговый профиль — это не только интересы и покупки. В нём должны учитываться и ограничения на коммуникацию. Есть ли согласие на определённый канал, отписался ли клиент от email, разрешены ли push-уведомления, можно ли использовать данные для конкретного типа коммуникации — всё это напрямую влияет на то, что система вправе и должна делать.
Если эти данные существуют отдельно и не доходят до CDP, автоматизация может выбрать правильного клиента, правильный оффер и правильный момент, но неправильный канал. Поэтому информация о согласиях, подписках и отказах должна рассматриваться не как административное приложение к профилю, а как часть логики маркетинга.
Источник данных сам по себе тоже полезно сохранять
Если один и тот же атрибут приходит из нескольких систем, возникает вопрос доверия. Например, телефон клиента есть в CRM, программе лояльности и интернет-магазине, но значения не совпадают. Или дата рождения была указана в анкете десять лет назад, а позже пользователь изменил её в личном кабинете.
Чтобы решать такие конфликты, важно понимать происхождение данных и время их обновления. Тогда можно установить правила: какой источник считается основным, какое значение свежее и что делать при расхождении. Без этого «единый профиль» рискует превратиться просто в склад противоречащих друг другу полей.
CDP должна не только собирать данные, но и помогать определить, каким из них доверять.
Не все исторические данные одинаково нужны
При первом переносе часто возникает желание загрузить в CDP всю историю компании. Если CRM существует десять лет, значит, логично взять все десять лет. Но старые данные могут быть бесполезны или даже мешать.
Телефоны меняются, email перестают существовать, структура каталога перестраивается, статусы заказов меняют смысл, а события сайта пятилетней давности могли вообще собираться по другой схеме.
Иногда достаточно последних двух-трёх лет транзакционной истории. В другом бизнесе важны пять лет из-за редкого цикла покупок. Для отдельных данных может быть достаточно нескольких месяцев. Глубина истории должна зависеть от поведения клиентов и задач аналитики, а не от максимального периода, который технически можно выгрузить.
Качество важнее количества
CDP не исправляет данные автоматически только потому, что они оказались в одной системе. Если в источниках много дублей, телефоны записаны в разных форматах, одна система передаёт отменённые заказы как покупки, а события сайта периодически исчезают, объединение лишь сделает эти проблемы заметнее.
Поэтому перед подключением источника полезно проверить хотя бы базовые вещи: насколько стабильно приходят данные, заполнены ли критичные поля, одинаково ли трактуются статусы, есть ли идентификаторы и понятны ли форматы. Не обязательно доводить всю базу до идеального состояния до старта. Но важно знать, где находятся ограничения, чтобы не строить на ненадёжных данных автоматические решения.
Небольшой, но качественный набор данных обычно полезнее огромного массива, которому никто не доверяет.
Минимальный набор определяется первой задачей
Универсального списка «обязательных данных для CDP» не существует. Для интернет-магазина, банка, сервиса подписки, застройщика и B2B-компании он будет разным. Но принцип можно сделать довольно простым.
Для каждого первого сценария стоит определить:
- кого нужно найти;
- по каким данным система поймёт, что клиент подходит;
- какое событие запускает или останавливает сценарий;
- какие атрибуты нужны для персонализации;
- какой идентификатор связывает клиента между системами;
- в какой канал должна уйти коммуникация;
- какие данные потребуются, чтобы измерить результат.
После этого становится гораздо понятнее, какие источники действительно нужно подключить на первом этапе. Если сценарий можно запустить с данными из трёх систем, нет необходимости ждать подключения остальных семи.
CDP не должна начинаться с идеи «соберём всё»
Чем больше данных хранит компания, тем выше соблазн считать их самостоятельной ценностью. Но сами по себе миллионы событий, сотни атрибутов и десятки интеграций ещё не делают маркетинг лучше. Ценность появляется, когда данные позволяют точнее определить клиента, понять его состояние, выбрать действие и оценить результат.
Поэтому хороший старт CDP-проекта часто выглядит довольно скромно: несколько надёжных источников, понятные идентификаторы, история ключевых действий и первые сценарии, ради которых всё это собирается.
Остальные данные можно добавлять по мере появления задач. Такой подход не ограничивает развитие платформы — наоборот, он позволяет быстрее понять, какие данные действительно работают, а какие компания собирала просто потому, что могла.