CDM Architecture Overview

While CDM is implemented using a core three-layer architecture (LDZ, RDV, and 360), Release 26.1 introduces several supporting components that extend processing and analytical capabilities without changing the foundational architecture:

• Aggregate Layer: Pre-computed analytical metrics used by Customer 360, Campaign 360, and Flowchart 360.
• Audience Resolution Layer: Standardizes campaign participation across customer-, account-, and device-level audiences into a unified customer identifier.
• ML Integration Framework: Provides controlled feature publication, model scoring integration, and Customer 360 enrichment through cdm_publish_db and cdm_ingest_db.
• Pipeline Orchestration Framework: Coordinates end-to-end execution through Grandmaster DAG, Master DAG, and generated execution DAGs.

These components operate alongside the core architecture and provide scalability, analytical optimization, and AI enablement capabilities.

Layer 1 – Landing Zone (LDZ)

What Is LDZ?

The Landing Zone (LDZ) is the initial ingestion layer where data first enters CDM from source systems. Data is stored exactly as received, with minimal or no transformation.

Why it’s important

• Preserves original source data and business keys
• Enables reconciliation and reprocessing
• Isolates downstream layers from source-system changes

What users will see

• Source-style table and column names
• Multiple records for the same entity when updates occur

Example

If a CRM system sends:

CUST_ID	F_NAME	L_NAME
C12345	Raj	Sharma

The same data is stored in LDZ without standardization.

User guidance: LDZ is intended for data capture and reference only, not analytics.

Layer 2 – Raw Data Vault (RDV)

What Is RDV?

The Raw Data Vault (RDV) is the canonical integration layer and the system of record for CDM. Here, data from multiple sources is standardized into common business entities.

Why it’s important

• Creates a single, consistent representation of customers, accounts, products, and campaigns
• Preserves full historical changes
• Supports auditability and lineage

What users will see

• Canonical entities (Party, Account, Product, Campaign, etc.)
• Time-aware data reflecting changes over time

Example

If a customer’s name changes:

• The old value is retained
• A new version is added with a timestamp

User guidance: RDV is not designed for direct consumption.

Layer 3 – 360 Layer

What Is the 360 Layer?

The 360 Layer provides business-ready, denormalized views built from canonical data. Examples include Customer 360 ,Campaign 360 and Flowchart 360 – flowchart-level execution insights including audience reach, channel-level engagement, and performance metrics per execution.

Why it’s important

• Hides integration complexity
• Supports analytics, segmentation, APIs, and AI
• Simplifies access to canonical data

What users will see

• Pre-calculated metrics
• Business-friendly naming
• One row per business entity

Example – Customer 360

Customer ID	Full Name	Total Accounts
C12345	Raj Sharma	3

User guidance: All reporting and analytics should use 360 views.

The Metadata Model orchestrates the full CDM system across all 360 views — Customer 360, Campaign 360, and Flowchart 360 — controlling the following key areas:

Integration and Mappings

Metadata maintains all mappings from source systems through Landing Zone, Raw Data Vault, and into all 360 Views.

What this means for users:Canonical structures remain stable even when source systems change or new sources are added.

ETL Automation (Metadata-Driven Processing)

Generic ETL engines read metadata definitions to automatically generate LDZ ingestion processes, RDV transformation logic, data quality and lineage processes, and orchestration workflows.

What this means for users: New data sources or attributes can be onboarded faster and more consistently, without redesigning existing Customer 360, Campaign 360, or Flowchart 360 views.

Data Quality Enforcement

Data quality rules are defined once in metadata and applied consistently across all layers (LDZ → RDV → 360). Examples include mandatory customer identifiers, valid value ranges, and consent and compliance checks.

What this means for users: Customer 360 ,Campaign 360 and Flowchart 360 data is more reliable and trustworthy.

End-to-End Lineage

Metadata captures every column, every transformation, and every dependency — enabling complete traceability from source systems through LDZ and RDV into all 360 views.

What this means for users: Supports audit, compliance, and root-cause analysis when questions arise about data origin or correctness.

WHY – Problems CDM Solves

Fragmented customer view across systems

Inconsistent customer identities

Channel-specific silos for campaigns and interactions

WHAT – CDM Provides

Through the Metadata Model, CDM delivers:

Canonical business entities such as Party, Account, Product, Campaign, and Response

Customer 360: A unified, behavior-rich, consent- and risk-aware customer profile

Campaign 360: Standardized campaign performance metrics, audience context.

Flowchart 360: Flowchart-level execution insights.

HOW – How CDM Achieves This

Canonicalization across products: Different source systems map into the same canonical structures.

End-to-end stitched journeys: Customer journeys are constructed using customer and event data across channels.

What this means for users: Customer and campaign insights are built on a consistent, reliable foundation— regardless of where the data originated.

The Aggregate Layer is a pre-computed analytics layer within Unica 360 that generates commonly used Customer 360 and Campaign 360 metrics in advance.

Benefits:

• Faster analytical query performance
• Reduced dependency on snapshot-level processing
• Support for rolling-window metrics (7-day, 30-day, and 90-day)
• Improved scalability for large-volume deployments

The Aggregate Layer is transparent to business users and does not change how Customer 360 or Campaign 360 are consumed.