Ingest with an explicit contract
Define an event ID, source timestamp, customer identifier and permitted fields. Test a duplicate, a late event and a failed delivery. Agree who owns schema changes and how failed events are replayed.
Product · Private CDP · AI Operational Layer
A customer data platform (CDP) brings customer records and events together. PrivyCDP runs on infrastructure your team controls. Explore how data enters the system, how records connect and how approved actions reach your tools.
Single-tenant · Customer-owned environment
Identity Graph
Event Stream
Decision Engine
AI Agent Layer
Connectors
Audit & Governance
Section 01 · Architecture Layers
The data flow has three parts: collect events, apply rules and send approved actions. Each part runs in your environment. Your team plans capacity and checks the logs.
Ingestion Layer
First-party event, batch, identity, and consent intake under customer-owned credentials
Event Collector
SDK · HTTP · Kafka
Batch Loader
Warehouse · Lakehouse
Identity Ingest
Deterministic · probabilistic
Consent Ingest
Policy · residency
Decision Layer
Identity resolution · real-time decisioning · AI agent operations · segmentation
Identity Graph
First-party resolution
Decision Engine
Real-time rules + ML
AI Agent Layer
Private LLM · MCP
Segmentation
Streaming + batch
Activation Layer
Journey orchestration · open activation interface · MCP-ready connectors · immutable audit
Journey Runtime
Workflow orchestrator
Activation Gateway
Reverse-ETL · Webhook
Connector Bus
MCP-ready interface
Audit Ledger
Hash-chained, immutable
Section 02 · Core Capabilities
Review four parts of the product. For each one, test what data it uses, who can change it and what gets logged.
Connect customer records from your own data stores and event streams. Keep the work in the environment you control.
Group records and apply rules to incoming events or batches. Review rule versions and audit records in your own systems.
Build steps that send approved actions to your existing tools. Check each connector against the release you plan to use.
Use AI to help review groups, workflows, unusual events and reports. Set limits on data access and require review of the results.
Section 03 · Integration Interface
Nine integration categories cover the operational interface area of an enterprise customer data platform. Every connector runs under customer-owned credentials, inside the customer environment.
Warehouses
Snowflake, BigQuery, Redshift, Azure Synapse — bidirectional sync under customer-owned credentials.
Lakehouses
Databricks, Iceberg, Delta — federated queries against the customer's existing lakehouse layer.
Identity Resolution
Deterministic and probabilistic graph stitching across systems, retained inside the customer boundary.
Event Streams
Kafka, Kinesis, Pub/Sub, Event Hubs — high-volume ingest with no metered per-event billing.
Activation Channels
Email, SMS, push, in-app, programmatic — customer-controlled credentials, no shared activation tax.
Reverse ETL
Push curated profiles and decisions to downstream systems of action — CRM, support, billing, ad platforms.
AI Models
Bring-your-own-model interface for private LLMs, embeddings, and scoring models inside the customer VPC.
Vector Stores
Pluggable vector backends for embeddings, retrieval, and feature stores — customer-owned persistence.
Audit & Logging
Immutable, hash-chained ledger plus structured logs into the customer SIEM and observability stack.
Section 04 · Open & MCP-Ready
PrivyCDP exposes open APIs, webhooks, and an MCP-ready interface for agent connectivity. Customer logic — segmentation rules, decision policies, journey graphs, and activation contracts — remains controlled, versioned, and auditable inside the customer environment. There is no shared decisioning plane, no opaque vendor model, and no forced public endpoint.
The AI operational layer is positioned as agent-assisted operations for the customer's own teams — not as autonomous marketing. Every AI-assisted action is recorded in the customer's immutable audit ledger alongside the human or system actor that authorized it.
Planning your evaluation
Use this proposed acceptance workflow to validate the published architecture against the integrations you actually need.
Define an event ID, source timestamp, customer identifier and permitted fields. Test a duplicate, a late event and a failed delivery. Agree who owns schema changes and how failed events are replayed.
Document which identifiers may join profiles and which systems are authoritative. Test an identifier change and an opt-out together; verify that a merge preserves the intended suppression rules.
Choose a real destination and confirm the connector, authentication method, rate limits, retry policy and delivery receipt. External email, SMS and advertising destinations create egress even when the CDP is privately hosted.
A private CDP needs an operating owner for infrastructure, access, backups and releases. If your team needs a fully managed service, price that scope explicitly. Category-level integration support is not proof of a ready-made connector for every named product.
Related engineering context: MailOps and activation delivery evidence. Use it with the page-specific evaluation questions above.
Discuss your deployment with engineers.
Bring your data flow, operating owners and evaluation questions.
Published: · Updated:
Editorial dates describe content changes. Confirm current sources before making legal, security or purchasing decisions.