CDP architecture for a telecom operator: where it lives and who owns it

Why an operator needs CDP as a separate layer

In most operators customer data is distributed: billing knows tariffs and payments, CRM knows contacts, network knows behaviour, the app knows digital engagement. Each system is optimised for its own task and is not designed for a real-time profile.

CDP is the layer that gathers events from these systems into a unified customer profile with low-latency access for downstream channels (campaign, app, contact centre, NBA engine).

Without CDP, each team builds its own mini-profile from the sources available to it. After 18-24 months the operator ends up with 5-7 inconsistent “profiles” and 5-7 inconsistent decisions on the same customer.

What it consists of structurally

Ingestion layer. Streaming load of events from billing (payment, activation), CRM (case, promise to resolve), network (location, data session start/end), app (open, in-app action). Batch load of reference data (tariff, product, segment).

Identity resolution. Linking identifiers (MSISDN, ICCID, account_id, app_user_id, passport, email). In telecom this is non-trivial due to multi-line accounts, family plans, corporate connections.

Profile store. Denormalised single profile with current state (last balance, last interaction, current segment) and rolling aggregates (data usage 7/30 days, churn risk, lifetime value).

Audience builder. The UI through which marketing or operations assembles a segment from a combination of attributes. The segment is pushed to a downstream channel via API.

Consent and policy layer. Every profile attribute is bound to customer consent. Channels receive only the data they have consent to use.

Event API. Downstream systems can subscribe to events (new segment, risk score change) and react near real-time.

Where it usually breaks

CDP is built as ETL into an additional warehouse. The result is another analytical store, not a real-time profile. Channels do not use it because data arrives with 24+ hour latency.

Identity resolution is left “for later” — as a result every channel sees its own slice of the customer, and personalisation fails.

The consent layer is not embedded in the architecture. Six months after launch, marketing receives a regulator inquiry it cannot answer with a legal basis for a specific campaign. CDP comes under threat of shutdown.

CDP reports to marketing but is consumed by everyone. There is no SLA on data quality, API uptime or latency. A year later this is not infrastructure but a headache.

Billing is unaware that CDP is subscribed to its events, and during the next schema migration CDP silently breaks.

Who should own it

CDP is not a marketing product, even though marketing is its primary user. This is data infrastructure. Owner — CDO or Head of Data, not CMO.

In the operating model there should be:

• Product owner CDP (data engineering)
• Data steward for each source domain (billing, CRM, network, app)
• Consent steward (legal/compliance)
• Channel integration leads (marketing, contact centre, app)

Without this role structure CDP becomes a pet project of one team.

Connection to other layers

CDP does not make decisions — it feeds the decisioning engine (NBA, campaign, churn). Decisioning can be a separate component or embedded in channels.

CDP does not do segmentation in the “marketing logic” sense — it provides data for segmentation. Segment logic lives in the audience builder and in decisioning.

CDP does not do analytics — it feeds the analytical platform (DWH/lakehouse). Analytics is built on top of CDP events or directly from source systems, depending on latency requirements.

How SamaraliSoft engages

CDP Blueprint — 8-12 weeks. Map of source systems, identity resolution design, target operating model, governance framework, consent layer design, build/buy choice, realistic 12-18 month roadmap. Then — implementation as parallel workstreams.

Related

• /en/insights/telecom-cdp/ — CDP in telecom as a discipline
• /en/architecture/telecom-event-bus-architecture/ — event-driven core
• /en/architecture/telecom-consent-architecture/ — consent layer
• /en/solutions/telecom-cvm-platform/ — CVM as CDP consumer