CDP — Customer Data Platform, платформа клиентских данных. Она состоит из шести слоев — сбор событий, хранилище, разрешение личности, витрина сегментов и атрибутов, активация в каналы, аналитика и контроль качества.
Схема движения данных по слоям:
- •Сбор — слой сбора событий: сайт, приложение, реклама, касса, CRM.
- •Объединение — разрешение личности склеивает события в один профиль.
- •Хранение — хранилище держит очищенные профили.
- •Анализ — витрина сегментов и атрибутов плюс аналитика и контроль качества.
- •Активация — сегменты уходят в рассылки, рекламу, кассу и на сайт.
Типовой стек под эти слои — очередь событий, колоночная база, сервис идентификации и API активации. Команда из четырех ролей собирает такую платформу за 3–5 месяцев при бюджете от 600 000 ₽.
Сбор событий и хранилище клиентских данных
Первый слой пишет сырые события: просмотры товаров, добавления в корзину, заказы, возвраты, обращения в поддержку, офлайн-покупки на кассе. По смыслу данные делятся на три типа — транзакционные, поведенческие и демографические.
Сколько хранить события и на какой СУБД строить хранилище, в источниках не сказано: ни сроков хранения, ни конкретных баз там нет. Это решают под свою нагрузку и требования к данным, а не по готовому шаблону.
Для первого сценария подключают 2–3 приоритетных источника, а не все сразу: такой запуск проще проверить и быстрее довести до результата.
Если данные только складываются и выгружаются в отчеты, это хранилище, а не CDP. Платформа же доводит данные до сегмента и дальше — до действия в канале.
Хранилище или платформа
Допустим, база покупателей копится годами, и менеджер время от времени выгружает ее для отчета в Excel. Это хранилище: профили объединены и лежат, но никуда не уходят сами. У платформы та же база работает иначе — сегмент собирается по условию и сам уходит в рассылку, без ручной выгрузки.
Условие для обоих вариантов одно: данные чистят до загрузки. Без этого дальше ехать некуда — дубли и ошибки из источников превратятся в неверные сегменты на каждом следующем слое.
Что сделать сейчас: выписать свои источники данных и отметить три, с которых стоит начать.
Как склеивается единый профиль клиента
Слой разрешения личности сверяет события по общим признакам — телефону, email, номеру карты лояльности — и решает, что это один человек. Пользователь зашел на сайт с телефона, а заказ оформил с ноутбука: платформа находит совпадающий email и собирает оба визита в одну карточку. Очищенную запись без дублей называют золотой — это и есть единый профиль клиента.
В профиле обычно лежат:
- •купленные товары
- •возвраты и их частота
- •источник перехода
- •доля повторных покупок
- •время целевых действий
Допустим, телефон клиента на кассе не совпадает с тем, что указан в личном кабинете сайта. Тогда платформа держала бы два разных профиля: сегмент по повторным покупкам его бы не увидел, и промокод бы не пришел. Если бы касса собирала еще и email, профили склеились бы по нему, и клиент попал бы в сегмент постоянных покупателей.
Правило простое: если у события нет общего идентификатора с другими, оно так и останется отдельным человеком в системе, а не частью существующего профиля.
Первый шаг перед подключением новых источников — проверить, какие идентификаторы уже есть в CRM и на кассе. Без общего ключа склейка не начнется.
CDP, CRM, DMP и BI
Эти системы не заменяют друг друга: у каждой своя задача, и CDP чаще работает рядом с ними, чем вместо них.
Витрина сегментов и расчетных атрибутов
Сегментация — не деление клиентов по возрасту или городу. Витрина берет поля из единого профиля и считает по ним расчетные атрибуты: RFM, LTV, склонность к бренду или категории.
Сегмент собирают по цепочке: цель, признак в профиле, сам сегмент, сценарий использования. Пример: клиент заказывал один бренд несколько раз — признак в профиле фиксирует повтор, сегмент собирает таких клиентов, сценарий отправляет им промокод на этот бренд.
Retail Rocket заявляет высокую скорость сегментации у своего продукта, но это слова вендора о себе, а не общий норматив рынка.
Если сегмент не привязан к сценарию, он бесполезен: база разбита на группы, но действие с ними никто не запускает. Проверить сегмент просто — спросить, какое письмо, звонок или предложение уйдет этой группе завтра. Нет ответа — сегмент собран зря.
Что сделать сейчас: сформулировать 2–3 сегмента под свои задачи и к каждому привязать конкретный сценарий.
Активация в рассылки, рекламу, кассу и сайт
Активация отдает сегменты туда, где с клиентом что-то происходит. Обмен идет в реальном времени и требует интеграции с корпоративными системами. Каждый канал ждет от платформы свое:
- •рассылки и push — адрес или токен и поле, под которое собрано письмо, например любимый бренд;
- •рекламные кабинеты — телефон и email, чтобы исключить из показа тех, кто товар уже купил;
- •касса и программа лояльности — номер карты, по которому на кассе срабатывает бонус;
- •сайт — ID профиля и склонность к категории для персональной подборки.
Допустим, касса принимает сегменты только ручной загрузкой файла: тогда промокод дойдет до клиента, когда акция уже закончится.
Если канал не принимает сегменты автоматически, нужна интеграция — ее закладывают в проект сразу, а не достраивают потом. Чем CDP отличается от DMP, показано в сравнительной таблице выше.
Полезно заранее составить список каналов, куда должны уходить сегменты: по нему и считают объем интеграций.
Аналитика и контроль качества данных
Gartner относит к минимальному набору возможностей CDP сбор данных, управление объектами клиентских данных, активацию и аналитическую отчетность. Это минимальный набор по Gartner, и на него удобно опираться, когда сравниваете платформы.
Мониторинг держит на виду четыре вещи: дубли карточек, пустые обязательные поля, отвалившиеся источники и расхождение цифр между отчетами CDP и CRM. Расхождение — сигнал проверить источник, а не сегмент: если отчеты не сходятся, сначала чинят данные на входе, а уже потом смотрят логику сегментации.
Без качественных данных и выстроенных процессов вокруг платформы получается дорогое хранилище: цифры копятся, а решения на них никто не строит.
Проверка на сегодня: найти в базе дубли по телефону и посчитать их долю от всех карточек. Один человек в нескольких записях — это разорванная история покупок и лишние письма; чем выше доля, тем раньше стоит заняться склейкой.
ФЗ-152 и доступы
ФЗ-152, права доступа и аудит действий пользователей — не отдельная тема, а строки в критериях выбора платформы: без них сравнение вендоров неполное.
Для работы с запросами клиента платформа должна уметь три вещи: выгрузить его данные, исправить их и удалить по обращению. Это рабочий минимум контроля, а не дополнительная опция.
Проверить это можно на демо: попросить вендора показать в интерфейсе экспорт, исправление и удаление данных клиента, а заодно журнал, где видно, кто из сотрудников и когда открывал профиль.
Стек, команда и бюджет разработки
Технически платформа собирается из четырех компонентов: очередь событий принимает поток данных, колоночная база хранит профили, сервис идентификации склеивает записи в один профиль, API активации отдает сегменты в каналы. Команда из четырех ролей закрывает такую сборку за 3–5 месяцев при бюджете от 600 000 ₽ — это редакционная оценка, а не готовая смета под любой проект.
Внешние ориентиры: Retail Rocket пишет, что на интеграцию нужны около трех разработчиков и менеджер проекта. По данным BizProfi, готовая платформа обходится в 100–120 тыс. руб. в месяц или от 1,4 млн руб. в год — это регулярная строка бюджета.
Путь строится так: цели и KPI, затем аудит и чистка источников, интеграции, настройка профиля и сегментов, обучение сотрудников и назначение ответственных, ограниченный запуск на 10–20% профилей и только после проверки — полный запуск. Ограниченный запуск показывает ошибки склейки на части базы, а не на всех клиентах. Если KPI не записаны до старта, проект лучше не запускать: без метрики некому будет сказать, сработала платформа или нет.
Поэтому начать стоит с того, чтобы записать 2–3 KPI первого сценария.
Своя разработка или готовая
Готовая платформа — это подписка, демо или пробный период до подписания договора. Сборка из внутренних систем дает полный контроль над данными, но может растянуться на 6–24 месяца.
Признаки, что CDP действительно нужна:
- •источников данных много, и они разрознены;
- •есть и онлайн, и офлайн-продажи;
- •повторные покупки важны для бизнеса;
- •источники качественные или их готовы привести в порядок;
- •процессы выстроены: понятно, кто отвечает за сегменты;
- •окупаемость посчитана до выбора платформы;
- •есть люди, которые будут заниматься платформой.
Если большая часть пунктов не про вас, сначала наведите порядок в данных.
Ошибки внедрения
Типовые ошибки и что с ними делать:
Спроектируем архитектуру под ваш объем данных и покажем смету по слоям: разработка платформы — от 600 000 ₽, 3–5 месяцев.
Источники
