Запросить демо
Экспертный гайд

On-prem CDP платформа для enterprise: архитектура и выбор решения

On-prem CDP для enterprise: lean-архитектура, модели развёртывания от 1 до 5 узлов, RBAC, аудит, 152-ФЗ. Расчёт TCO и критерии выбора платформы в Москве.

Категория
Экспертный гайд
Время чтения
13 минут
Опубликовано
Автор
stackfort

Enterprise-компании с клиентской базой от 50 тысяч записей сталкиваются с задачей, которую облачные сервисы решают лишь частично: собрать все данные о клиентах в единый контур, контролировать доступ, соответствовать 152-ФЗ и при этом не зависеть от внешнего вендора. On-prem CDP — платформа, которая разворачивается внутри инфраструктуры компании и закрывает эти требования архитектурно, а не организационно. В этом гайде — архитектура on-prem CDP, критерии выбора, модели развёртывания и расчёт совокупной стоимости владения. Подробнее о сравнении с SaaS — в отдельном разделе.

Что такое CDP и почему on-prem имеет значение

Customer Data Platform — класс систем, который объединяет данные о клиентах из разрозненных источников в единый управляемый профиль. В отличие от CRM, которая фиксирует историю взаимодействий с менеджером, CDP агрегирует поведенческие события, транзакции, атрибуты из веб-аналитики, мобильного приложения, контакт-центра, биллинга и внутренних учётных систем. Результат — одна «версия правды» о каждом клиенте.

Большинство CDP-платформ на рынке работают в облаке. Однако для enterprise-компаний в России это создаёт три архитектурных ограничения:

  • Контроль над данными. Клиентские данные покидают периметр компании. Согласование с ИБ затягивается на месяцы, а иногда блокируется навсегда.
  • Регуляторные риски. 152-ФЗ требует хранения персональных данных российских граждан на территории РФ. SaaS-вендор с серверами за рубежом не проходит compliance-проверку. Подробнее — в разделе 152-ФЗ и клиентские данные.
  • Vendor lock-in. Зависимость от чужой дорожной карты, ценовой политики и API. Миграция клиентских данных из облачного CDP — проект на полгода и больше.

On-prem CDP устраняет эти ограничения на уровне архитектуры. Платформа разворачивается на серверах заказчика — в собственном ЦОД или на выделенных мощностях в российском дата-центре. Данные не покидают контур. Обновления контролирует ИТ-команда, а не внешний вендор.

При этом важно различать два подхода к on-prem. Первый — облачный продукт, адаптированный для установки на сервер заказчика. Такие решения часто тянут за собой тяжёлую distributed-архитектуру, рассчитанную на мультитенантность, и требуют 10-15 узлов для старта. Второй подход — платформа, изначально спроектированная для изолированных сред. В этом случае baseline-инсталляция занимает 1-3 узла, а архитектура линейно масштабируется модулями.

Требования enterprise к on-prem CDP платформе

CIO и CTO крупных компаний оценивают CDP не по маркетинговым обещаниям, а по соответствию корпоративным стандартам. Ниже — чек-лист требований, который мы рекомендуем использовать при предварительной оценке платформы.

Информационная безопасность

ТребованиеЧто проверятьКрасный флаг
Шифрование данных at restПоддержка AES-256 или ГОСТ для хранимых данныхТолько TLS in transit, без шифрования на диске
RBAC (ролевой доступ)Гранулярность: до уровня сегмента, поля, операцииТолько «админ / пользователь» без детализации
Audit trailЛогирование всех действий с привязкой к пользователю и IPНет журнала аудита или нет экспорта в SIEM
Интеграция с IdPLDAP, Active Directory, SAML 2.0, OIDCТолько внутренняя аутентификация
Сетевая изоляцияРабота без доступа в интернет (air-gap)Обязательный «телефон домой» к облаку вендора

Compliance и регуляторика

Для российских enterprise-компаний ключевой регуляторный акт — 152-ФЗ «О персональных данных». On-prem CDP должна обеспечивать:

  • Хранение данных на территории РФ — архитектурная гарантия, а не конфигурация
  • Управление согласиями (consent management) — фиксация, отзыв, журналирование
  • Право на удаление (right to be forgotten) — гарантированное удаление из всех хранилищ, включая бэкапы
  • Разграничение доступа к персональным данным по ролям и отделам

Помимо 152-ФЗ, компании финансового сектора учитывают требования ЦБ РФ к защите информации, а ритейл — отраслевые стандарты PCI DSS при хранении данных, связанных с платёжными операциями.

Интеграции

Enterprise-ландшафт — это десятки систем: ERP, биллинг, контакт-центр, веб-аналитика, мобильное приложение, программа лояльности. On-prem CDP должна предоставлять:

  • REST API — для двусторонней интеграции с внутренними системами
  • Webhook engine — для реактивной модели (событие → действие)
  • Import/export — пакетная загрузка и выгрузка данных (CSV, Excel, API)
  • Событийная шина — для потоковой обработки клиентских событий в реальном времени

Критичный момент: интеграционный слой должен работать внутри контура. Если CDP требует облачный коннектор для связи с внутренней CRM — это нарушает принцип on-prem.

Архитектура lean on-prem CDP

Традиционный подход к enterprise CDP предполагает distributed martech-кластер: отдельные сервисы для ingestion, processing, storage, analytics, каждый со своим стеком и требованиями к инфраструктуре. Для старта такой системы нужны 10-15 серверов и команда из 5-8 DevOps-инженеров.

Lean-подход — принципиально иной. Архитектура строится на минимальном количестве компонентов, каждый из которых закрывает максимум функций.

Принципы lean-архитектуры on-prem CDP

ПринципЧто это значитРезультат
Монолитный бэкендОдин бинарь: API, оркестрация, workers, RBAC, auditПроще деплой, меньше точек отказа
Единая основная БДОдно хранилище для профилей, событий, сегментов, конфигурацииНет синхронизации между хранилищами
Полнотекстовый поиск без отдельного движкаВстроенный поиск на уровне БД, без выделенного поискового кластераМинус 2-3 узла из инфраструктуры
Опциональные модулиКеш, событийная шина, аналитика — подключаются по мере ростаСтарт на 1 узле, масштабирование без переделки

Слои архитектуры

Lean on-prem CDP состоит из четырёх архитектурных слоёв:

  1. Presentation layer. Единая веб-админка для работы с профилями, сегментами, сценариями, ролями и аудитом. Интерфейс доступен через браузер, без установки клиентского ПО.
  2. Application layer. Ядро платформы: публичный API, движок правил и оркестрации, обработчики фоновых задач, модуль RBAC и аудита, интеграционный слой с webhook engine.
  3. Data layer. Основное хранилище — реляционная СУБД: профили, карточки клиентов, события, сегменты, сценарии, consent-записи, аудит-лог, конфигурация. Полнотекстовый поиск и триграмный поиск — на уровне СУБД.
  4. Infrastructure layer. Контейнеризация для упрощения деплоя. На уровне Minimum — оркестрация контейнеров без кластера. На уровне HA — легковесный оркестратор.

Такая архитектура позволяет запустить production-инсталляцию на одном физическом сервере с 8 vCPU и 32 ГБ RAM. Для enterprise с клиентской базой 150-700 тысяч записей рекомендуется конфигурация из 3 узлов — с разделением application и data слоёв.

Ключевые возможности on-prem CDP платформы

Функциональность enterprise CDP выходит за рамки «склеивания профилей». Ниже — набор возможностей, который мы считаем обязательным для on-prem платформы корпоративного уровня.

Единый профиль клиента

Центральная задача CDP — entity resolution: склеивание записей из разных источников в один профиль. Клиент, который позвонил в контакт-центр, оставил заявку на сайте и совершил покупку через мобильное приложение, должен иметь одну карточку с полной историей. Подробнее — в разделе Единый профиль клиента.

Сегментация

Сегменты строятся по трём типам критериев:

  • Атрибутивные — по полям профиля (город, отрасль, тариф, LTV)
  • Поведенческие — по событиям (совершил покупку за последние 30 дней, открыл 3+ писем)
  • Вычисляемые — по агрегированным метрикам (RFM-сегменты, скоринг вовлечённости)

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

Триггерные сценарии и коммуникации

On-prem CDP должна поддерживать автоматические сценарии: «если клиент попал в сегмент X → выполнить действие Y». Действия: отправить webhook, создать задачу, изменить атрибут, отправить уведомление через интеграцию. Подробнее — в разделе Триггерные сценарии и коммуникации.

RBAC и управление доступом

Уровень доступаЧто контролируетПример
РольНабор разрешений (просмотр, редактирование, удаление)«Аналитик» — только чтение профилей и сегментов
ОбъектДоступ к конкретным сущностям«CRM-менеджер Москва» — только клиенты региона
ПолеВидимость отдельных атрибутовМаскирование телефона и email для операторов
ДействиеРазрешение на конкретную операциюЭкспорт данных — только для руководителей

Гранулярный RBAC — не опция, а требование. Для компании с 50+ пользователями CDP без детального управления доступом не пройдёт согласование ИБ.

Аудит и журналирование

Каждое действие в системе фиксируется: кто, когда, что изменил, с какого IP-адреса. Аудит-лог — неизменяемый, с возможностью экспорта в корпоративный SIEM. Это требование как 152-ФЗ, так и внутренних политик безопасности enterprise-компаний.

Workspace / multi-tenant

Для холдинговых структур и компаний с несколькими бизнес-юнитами важна поддержка workspace-модели: изолированные пространства с собственными ролями, данными и настройками внутри одной инсталляции.

Модели развёртывания on-prem CDP: от пилота до HA

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

ПараметрMinimum (1 узел)Recommended (3 узла)HA (5 узлов)
Ресурсы8 vCPU, 32 ГБ RAM, 500 ГБ NVMe20 vCPU, 64 ГБ RAM, 1,5 ТБ SSD36 vCPU, 112 ГБ RAM, ~3 ТБ SSD
Клиентская база50-150 тыс. профилей150-700 тыс. профилей700 тыс.+ профилей
Пользователи3-1510-5050+
ОркестрацияКонтейнеры без кластераКонтейнеры без кластераЛегковесный оркестратор
Резервирование БДБэкап по расписаниюБэкап + опциональная репликаPrimary + Standby
Опциональные модулиКеш, событийная шина, мониторингВсё из Recommended + аналитический модуль
СценарийПилот, первый productionProduction для среднего enterpriseEnterprise production с резервированием

Когда какой профиль выбрать

Minimum — для пилотного проекта или первого production-запуска. Подходит компаниям с клиентской базой до 150 тысяч записей и командой CRM из 3-15 человек. Инсталляция занимает 1 рабочий день. Это не «демо-версия» — полнофункциональная платформа с RBAC, аудитом и интеграциями.

Recommended — основной профиль для среднего enterprise. 3 узла позволяют разделить application и data слои, подключить кеш для ускорения поиска и событийную шину для потоковой обработки. Масштабирование до 700 тысяч профилей без изменения архитектуры.

HA — для enterprise-production с требованием высокой доступности. 5 узлов: два application-сервера, основной и резервный серверы БД, инфраструктурный узел. Отказ одного узла не останавливает работу системы. Опционально — аналитический модуль для тяжёлых отчётов и ad-hoc запросов.

Путь масштабирования

Переход между профилями — модульный, без переноса данных и смены платформы:

  1. Minimum → Recommended: добавление 2 узлов, подключение кеша и событийной шины
  2. Recommended → HA: добавление 2 узлов (резервный application + инфраструктурный), включение репликации БД
  3. На любом этапе: подключение аналитического модуля как отдельного узла

Критерии выбора on-prem CDP платформы

При оценке on-prem CDP мы рекомендуем использовать матрицу из 8 критериев. Каждый критерий оценивается по шкале 1-5. Минимальный порог для enterprise — средний балл 3.5 и ни одного критерия с оценкой 1.

#КритерийЧто оцениватьВес
1Архитектурная простотаКоличество обязательных компонентов для старта, минимальные требования к инфраструктуре15%
2БезопасностьRBAC, audit trail, шифрование, интеграция с IdP, air-gap20%
3МасштабируемостьЛинейное масштабирование модулями, без переделки архитектуры15%
4ИнтеграцииREST API, webhooks, import/export, событийная шина, количество готовых коннекторов15%
5TCO на 3-5 летЛицензия + внедрение + сопровождение, зависимость от объёма данных / MAU15%
6Vendor lock-inОткрытые форматы данных, стандартные протоколы, возможность миграции10%
7Поддержка и SLAВремя реакции, глубина экспертизы, наличие premium-уровня 24/75%
8Соответствие регуляторике152-ФЗ, реестр отечественного ПО, отраслевые стандарты5%

Чек-лист для пилотного тестирования

Перед принятием решения мы рекомендуем провести пилот на реальных данных. Минимальная программа пилота — 2-4 недели:

  1. Развёртывание — сколько времени занимает установка? Нужна ли команда вендора или справится внутренняя ИТ-служба?
  2. Импорт данных — загрузить 10-50 тысяч реальных профилей. Оценить скорость импорта и качество entity resolution.
  3. Сегментация — создать 5-10 сегментов по реальным бизнес-критериям. Проверить скорость пересчёта.
  4. Интеграция — подключить 1-2 внутренние системы через API. Оценить сложность и документацию.
  5. Безопасность — настроить RBAC для 3 ролей. Проверить аудит-лог. Провести базовый pentest.
  6. Производительность — нагрузочное тестирование: 100 одновременных пользователей, 1000 событий/сек.

По итогам пилота заполняется матрица оценки. Если средний балл ниже 3.5 — платформа не подходит для enterprise-уровня.

TCO: on-prem лицензия vs SaaS-подписка

Совокупная стоимость владения (Total Cost of Ownership) — главный аргумент при выборе между on-prem и SaaS. Распространённое заблуждение: «on-prem дороже». В действительности это зависит от горизонта планирования и размера клиентской базы.

Структура стоимости on-prem CDP

КомпонентТип платежаДиапазон (рынок 2025-2026)
Лицензия на платформуРазовыйот 900 тыс. до 3,6 млн ₽
Внедрение и настройкаРазовыйот 1,2 до 7 млн ₽
Серверная инфраструктураРазовый или арендаот 200 тыс. до 1,5 млн ₽
Сопровождение и поддержкаЕжемесячныйот 60 до 320 тыс. ₽/мес

Структура стоимости SaaS CDP

КомпонентТип платежаДиапазон
Подписка (per MAU)Ежемесячныйот 0,5 до 5 ₽/MAU/мес
ВнедрениеРазовыйот 500 тыс. до 3 млн ₽
Дополнительные модулиЕжемесячныйот 50 до 300 тыс. ₽/мес

Сравнение TCO на 3 года (пример: 300 тыс. MAU)

ПоказательOn-prem (Recommended)SaaS
Год 1 (старт + лицензия/подписка)~6,7 млн ₽~5,3 млн ₽
Год 2 (сопровождение/подписка)~1,4 млн ₽~3,6 млн ₽
Год 3 (сопровождение/подписка)~1,4 млн ₽~4,3 млн ₽
Итого за 3 года~9,5 млн ₽~13,2 млн ₽
Экономия on-prem~28% за 3 года

Ключевое отличие: стоимость on-prem фиксирована и не зависит от роста клиентской базы. SaaS-подписка растёт пропорционально MAU — при удвоении базы стоимость удваивается. Поэтому для enterprise с базой 300 тыс.+ клиентов on-prem окупается уже на втором году.

Когда SaaS всё-таки выгоднее

SaaS-модель предпочтительнее в двух случаях: клиентская база менее 50 тысяч записей (стоимость лицензии не окупится) или нет внутренней ИТ-команды для эксплуатации on-prem (нужен минимум 1 инженер на частичной загрузке). Для компаний с базой 50-150 тысяч — зона паритета, решение зависит от требований ИБ и compliance.

FAQ об on-prem CDP

Сколько стоит внедрение on-prem CDP в Москве?

Совокупный бюджет старта зависит от профиля мощности. Для конфигурации Minimum (1 узел, до 150 тыс. клиентов) — от 2,1 млн рублей (лицензия + внедрение) плюс от 60 тыс. рублей ежемесячно за сопровождение. Для Recommended (3 узла, до 700 тыс. клиентов) — от 4,3 млн рублей на старте и от 120 тыс. рублей ежемесячно. Цена фиксируется в договоре и не зависит от объёма клиентской базы, в отличие от SaaS-подписки per MAU.

Какие серверные ресурсы нужны для on-prem CDP?

Минимальная конфигурация — 1 сервер: 8 vCPU, 32 ГБ RAM, 500 ГБ NVMe SSD. Этого достаточно для production-инсталляции с базой до 150 тысяч клиентов и 3-15 пользователями. Для enterprise с базой 150-700 тысяч рекомендуется 3 узла общей мощностью 20 vCPU, 64 ГБ RAM. Для HA с полным резервированием — 5 узлов, 36 vCPU, 112 ГБ RAM.

Чем on-prem CDP отличается от облачной CDP?

On-prem CDP разворачивается на серверах заказчика — данные не покидают контур компании. Облачная CDP хранит данные на серверах вендора. Для enterprise это означает три отличия: полный контроль над безопасностью и доступом, архитектурное соответствие 152-ФЗ без дополнительных согласований, фиксированная стоимость без зависимости от MAU. Подробное сравнение — в разделе On-prem vs SaaS CDP.

Сколько времени занимает внедрение on-prem CDP?

Пилотная инсталляция на профиле Minimum — от 1 рабочего дня до развёртывания и от 2-4 недель на импорт данных, настройку интеграций и обучение команды. Полноценное внедрение на профиле Recommended с интеграцией 3-5 внутренних систем — от 2 до 4 месяцев. Срок зависит от количества источников данных и сложности сценариев сегментации.

Нужна ли отдельная ИТ-команда для эксплуатации on-prem CDP?

Для профиля Minimum достаточно одного инженера на частичной загрузке — обновления, бэкапы, мониторинг. Для Recommended — 1-2 инженера. Для HA — выделенная команда из 2-3 человек. Вендор предоставляет сопровождение: мониторинг, обновления, консультации. При этом вся экспертиза остаётся внутри компании — в отличие от SaaS, где обслуживание полностью на стороне вендора.

Как on-prem CDP обеспечивает соответствие 152-ФЗ?

Архитектурно: данные хранятся на серверах заказчика на территории РФ, доступ контролируется через RBAC, все действия фиксируются в аудит-логе, реализовано управление согласиями и право на удаление. Это не конфигурация — это свойство архитектуры. Облачная CDP требует дополнительных мер: DPA-соглашение с вендором, аудит дата-центров, оценка трансграничной передачи. Подробнее — в разделе 152-ФЗ и клиентские данные.

Можно ли мигрировать с SaaS CDP на on-prem?

Да, но миграция — отдельный проект. Типичный срок: 3-6 месяцев. Этапы: аудит текущих данных, маппинг схемы, экспорт профилей и событий, валидация entity resolution, параллельная работа двух систем, переключение интеграций. Главный риск — потеря связей между профилями при экспорте. Мы рекомендуем начинать с пилота на новом сегменте, а не с полной миграции. Подробнее — в разделе Независимость от вендора.

Следующий шаг — архитектурная консультация

Выбор on-prem CDP начинается с оценки текущего ландшафта: источники данных, объём клиентской базы, требования ИБ, интеграционные сценарии. Мы проводим архитектурные консультации для enterprise-компаний в Москве — разбираем конкретный кейс, подбираем профиль мощности и рассчитываем TCO на 3-5 лет. Запишитесь на 30-минутный Zoom-звонок, чтобы обсудить вашу задачу с архитектором платформы.