Архитектура

CDP-архитектура для телеком-оператора: где она живёт и кому принадлежит

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

Обсудить задачу

Зачем оператору CDP отдельным слоем

В большинстве операторов клиентские данные распределены: биллинг знает тарифы и платежи, CRM знает обращения, network знает поведение, app знает digital-engagement. Каждая система оптимизирована под свою задачу и не предназначена для real-time профиля.

CDP — слой, который собирает события из этих систем в единый клиентский профиль с low-latency доступом для downstream-каналов (campaign, app, contact center, NBA-движок).

Без CDP каждая команда строит свой mini-профиль из доступных ей источников. Через 18-24 месяца оператор имеет 5-7 несогласованных «профилей» и 5-7 несогласованных decisions по одному и тому же клиенту.

Структурно из чего состоит

Ingestion layer. Стримовая загрузка событий из биллинга (платёж, активация), CRM (обращение, обещание решения), network (location, data session start/end), app (открытие, in-app action). Batch-загрузка справочников (тариф, продукт, сегмент).

Identity resolution. Связывание идентификаторов (MSISDN, ICCID, account_id, app_user_id, паспорт, email). В телекоме нетривиально из-за multi-line аккаунтов, family-планов, корпоративных подключений.

Profile store. Денормализованный single profile с актуальным состоянием (last balance, last interaction, current segment) и rolling-агрегатами (data usage 7/30 дней, churn risk, lifetime value).

Audience builder. UI, через который маркетинг или operations собирает сегмент по комбинации признаков. Сегмент пушится в downstream-канал через API.

Consent and policy layer. Каждый признак профиля имеет привязку к согласию клиента. Каналы получают только те данные, на использование которых есть consent.

Event API. Downstream-системы могут подписаться на события (новый сегмент, изменение risk score) и реагировать near real-time.

Где обычно ломается

CDP строится как ETL в дополнительный warehouse. Получается ещё один analytical store, не real-time профиль. Каналы не используют, потому что данные приходят с задержкой 24+ часа.

Identity resolution делается «потом» — в результате каждый канал видит свой кусок клиента, и personalization не работает.

Consent layer не встроен в архитектуру. Через 6 месяцев после запуска маркетинг получает претензию от регулятора, что не может доказать legal basis для конкретной кампании. CDP под угрозой остановки.

CDP подчинён маркетингу, но потребляется всеми. Нет SLA на качество данных, на uptime API, на latency. Через год это не infrastructure, а headache.

Билингу не в курсе, что CDP подписан на его события, и при следующей миграции схемы CDP молча ломается.

Кто должен владеть

CDP — не маркетинговый продукт, хотя маркетинг — его primary user. Это data infrastructure. Owner — CDO или Head of Data, не CMO.

В operating model должны быть:

Product owner CDP (data engineering)
Data steward на каждый source-домен (биллинг, CRM, network, app)
Consent steward (legal/compliance)
Channel integration leads (marketing, contact center, app)

Без этой ролевой структуры CDP превращается в пет-проект одной команды.

Связь с другими слоями

CDP не делает decisions — он питает decisioning engine (NBA, campaign, churn). Decisioning может быть отдельным компонентом или встроен в каналы.

CDP не делает segmentation в смысле «маркетинговая логика» — он provides данные для segmentation. Логика сегментов живёт в audience builder и в decisioning.

CDP не делает analytics — он питает analytical platform (DWH/lakehouse). Analytics строится поверх CDP-событий или из source-систем напрямую, в зависимости от latency требований.

Как SamaraliSoft подключается

CDP Blueprint — 8-12 недель. Карта source-систем, дизайн identity resolution, target operating model, governance framework, дизайн consent layer, choice between build/buy, реалистичный roadmap на 12-18 месяцев. Дальше — implementation в формате параллельных потоков.