CRM vs CDP vs DWH: архитектура Customer 360 и кто является SSOT

Недавно я сидел на встрече с директором по маркетингу одной крупной казахстанской компании. Он жаловался: «У нас три системы знают про клиента, и все три показывают разное. CRM говорит, что клиент купил товар на 500 тысяч тенге. CDP утверждает, что он потратил миллион. А хранилище данных вообще считает его новым — хотя он с нами уже три года».

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

Когда бизнес растёт, данные о клиентах начинают жить своей жизнью в разных системах. Маркетинг ведёт одну базу, продажи — другую, поддержка — третью. В какой-то момент вы понимаете, что у вас нет единого понимания, кто ваш клиент, что он покупал и чего хочет. И тогда возникает вопрос: как собрать всё воедино?

Об этом и поговорим. Разберёмся, чем отличаются CRM, CDP и DWH, когда какая система нужна, и как построить Customer 360 — единый профиль клиента, которому можно доверять.

CRM, CDP, DWH: три буквы — три разных мира

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

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

Давайте разберём каждую систему подробнее, потому что дьявол — в деталях.

CRM: операционный центр работы с клиентами

CRM — это про действия. Менеджер открыл карточку клиента, увидел историю общения, запланировал звонок, перевёл сделку на следующий этап. Это инструмент для ежедневной операционной работы.

В хорошей CRM хранятся контакты, компании, сделки, задачи, история переписки, записи звонков. Система помогает не забыть про клиента, вовремя связаться, зафиксировать договорённости. Это рабочее место продавца, как текстовый редактор для писателя или IDE для программиста.

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

CDP: центр идентификации клиента

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

Представьте: человек зашёл на сайт с телефона (cookie_123), потом с ноутбука (cookie_456), зарегистрировался по email ivan@mail.ru, а в CRM он записан как «Иван Петров» с телефоном +7 777 123 45 67. CDP умеет понять, что это один и тот же человек, и объединить все его данные.

Этот процесс называется identity resolution — и это главная суперсила CDP. Система собирает события из разных источников (сайт, приложение, email, реклама, CRM) и строит полный портрет клиента: что смотрел, что покупал, на что реагировал.

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

DWH: архив и аналитический мозг

Data Warehouse — это хранилище данных для аналитики. Сюда сливается информация из всех систем компании: CRM, 1С, ERP, сайт, колл-центр. Данные структурируются, очищаются и хранятся для построения отчётов и анализа трендов.

В отличие от CRM и CDP, DWH оптимизировано для чтения, а не для записи. Его задача — быстро отвечать на аналитические запросы: «Сколько мы заработали в прошлом квартале по сегментам?», «Какой средний цикл сделки по отраслям?», «Как изменился LTV клиентов за три года?».

DWH — это память компании. Здесь хранится история, которую CRM может удалить при миграции, а CDP — потерять при смене платформы. Но DWH не умеет идентифицировать клиентов (это делает CDP) и не поддерживает операционные процессы (это CRM).

Проблема «трёх правд»: почему данные расходятся

Вернёмся к истории с директором по маркетингу. Почему три системы показывают разные суммы покупок одного клиента? Давайте разберём анатомию этого хаоса.

Расхождения данных — это не баг отдельной системы. Это системная проблема, которая возникает, когда в компании нет договорённости о том, где хранится «золотая запись» (Golden Record) клиента и как она синхронизируется между системами.

И вот тут мы подходим к главному вопросу: что такое Customer 360 и как его построить.

Customer 360: единый профиль клиента

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

На словах всё просто. На деле — это одна из самых сложных задач в корпоративных данных. Данные о клиенте разбросаны повсюду: в CRM — контакты и сделки, на сайте — поведение, в 1С — платежи, в колл-центре — записи звонков, в email-платформе — история рассылок, в поддержке — тикеты.

Customer 360 — это не база данных. Это результат работы архитектуры, которая:

• Собирает данные из всех источников
• Идентифицирует одного клиента среди дубликатов
• Разрешает конфликты (какому источнику верить)
• Формирует «золотую запись» — эталонный профиль
• Раздаёт эти данные обратно в системы, которым они нужны

Подробнее о качестве данных и создании единого источника правды мы писали в статье Качество данных в CRM: как построить единый источник правды (SSOT).

Кто должен быть SSOT: три архитектурных подхода

SSOT — Single Source of Truth — это система, которая хранит «золотую запись». Главный вопрос: кто берёт на себя эту роль? Есть три основных подхода, и выбор зависит от специфики вашего бизнеса.

Практическая архитектура: как это работает вместе

Теория — это хорошо, но давайте посмотрим, как выглядит реальная архитектура Customer 360 для типичной казахстанской компании среднего размера. Возьмём пример: оптовая компания с офлайн-продажами, интернет-магазином и партнёрской сетью.

Обратите внимание на ключевые принципы:

• Один мастер для каждой сущности. Контакты и компании — в CRM. Финансы — в 1С. Аналитика — в DWH. Нет двух систем, которые считают себя «хозяевами» одних данных.
• Чёткое направление потока. Источники пишут в CRM. CRM раздаёт данные потребителям. Не наоборот.
• DWH для чтения, не для записи. Хранилище собирает данные отовсюду, но не является источником правды для операционных систем.

О том, как правильно настроить интеграции между системами, читайте в статье о наблюдаемости LLM-системы — принципы логирования и трассировки применимы к любым интеграциям данных.

Golden Record: как создать «золотую запись» клиента

Golden Record — это не просто «все данные в одном месте». Это эталонный профиль, где каждое поле имеет проверенное, согласованное значение. Если у клиента три телефона в разных системах — Golden Record знает, какой из них актуальный.

Создание Golden Record — это процесс из трёх шагов: идентификация, слияние и обогащение.

Важно понимать: Golden Record — это не статичная запись. Она постоянно обновляется при поступлении новых данных. Клиент сменил телефон? Golden Record обновился. Пришла новая оплата из 1С? Пересчитался LTV.

Про MDM (Master Data Management) и правила создания Golden Record мы расскажем подробнее в следующей статье этого кластера — о MDM в CRM.

Реальный пример: как мы строили Customer 360 для торговой компании

Расскажу историю из практики. К нам обратилась торговая компания с филиалами в Алматы, Астане и Шымкенте. Проблема классическая: три офиса, три отдельных CRM, одна 1С. Клиент мог числиться во всех трёх системах как три разных контрагента.

Что мы сделали:

1. Выбрали CRM как SSOT. Для B2B с активными продажами это логичный выбор. Менеджеры — главные создатели и потребители данных о клиентах.
2. Настроили дедупликацию. Правила: совпадение ИНН/БИН ИЛИ (email + город) ИЛИ (телефон, нормализованный). Нашли 3800 дубликатов, слили в 8200 уникальных записей.
3. Интегрировали 1С. Двусторонняя синхронизация: контрагенты, счета, оплаты, отгрузки. CRM стала знать финансовую историю клиента.
4. Построили расчётные поля. LTV (сумма оплат за всё время), дата последней покупки, средний чек, RFM-сегмент. Всё считается автоматически на данных из CRM + 1С.
5. Настроили DWH для отчётности. Данные из CRM и 1С льются в ClickHouse. Там строятся дашборды для CEO и аналитические срезы.

Результат: компания впервые увидела полную картину по клиентам. Оказалось, что 20% клиентов приносят 80% выручки (классика Парето), но эти клиенты были «размазаны» по филиалам и никто не видел их общий вклад. После объединения данных запустили программу лояльности для топ-сегмента — выручка выросла на 15% за квартал.

Пять ошибок при построении Customer 360

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

О том, как находить и устранять узкие места в процессах, читайте в статье Операционная эффективность: как найти bottlenecks в процессах продаж и сервиса.

С чего начать: практический план

Если вы дочитали до сюда и думаете «окей, это всё красиво, но с чего начать?» — вот конкретный план действий.

Заключение: Customer 360 — это процесс, а не проект

Вернёмся к началу статьи. Директор по маркетингу жаловался, что три системы показывают разные данные о клиенте. Теперь вы знаете: это не баг систем, это отсутствие архитектуры данных.

CRM, CDP и DWH — не конкуренты. Это инструменты для разных задач. CRM — для операционной работы с клиентами. CDP — для идентификации и персонализации. DWH — для аналитики и истории. Вопрос не «что выбрать», а «как заставить их работать вместе».

Customer 360 — это не продукт, который можно купить. Это результат архитектурных решений, процессов и дисциплины. Единый профиль клиента появляется, когда:

• Есть один источник правды для каждой сущности (SSOT)
• Данные идентифицируются и очищаются от дубликатов
• Интеграции работают по чётким правилам
• Качество данных постоянно мониторится
• Есть владелец данных, который за всё это отвечает

Начните с малого: проведите аудит, выберите SSOT, почистите дубликаты. Это уже даст видимый результат. А дальше — итерация за итерацией — вы построите систему, которой можно доверять.

Потому что единственное, что хуже отсутствия данных о клиенте — это три разных версии «правды» о нём в трёх разных системах.

Часто задаваемые вопросы

Читайте также