A warehouse full of customer records doesn't tell you who owns identity quality, which profile fields are current or whether an audience reaches its destination correctly. CDP architecture needs to answer those questions.
A useful customer data platform architecture identifies the jobs in the workflow, where each runs and who operates it. Packaged, composable and lakehouse-connected designs distribute those responsibilities differently. The labels alone don't establish deployment location, data movement or performance.
Key Takeaways
Map ingestion, identity resolution, profile modeling, audience evaluation and delivery as distinct responsibilities.
Packaged and composable architectures change how much integration and operation your team owns.
A lakehouse connection describes a relationship with your data platform; verify processing location separately.
Identity quality, profile freshness and destination usability need separate acceptance checks.
Place access controls, monitoring and change management across the full workflow.
Start with the jobs your architecture must perform
Identify the source systems and the business decision the first workflow must support. A retention audience may need customer records, purchase history, channel eligibility and a destination capable of using the output.
Then assign an owner to each transformation. Who normalizes identifiers? Who resolves relationships among records? Who calculates purchase recency? Who verifies the receiving system?
Treat these as logical responsibilities before deciding which product owns each one. Our build-versus-buy framework helps make that division explicit.
Packaged architecture: one platform owns more of the workflow
In a packaged pattern, a platform supplies several connected capabilities, such as ingestion, customer profiles, segmentation and destination delivery. The appeal is a more integrated operating experience.
Your team still has work to do. Source meanings, permitted use, business definitions, destination credentials and acceptance criteria don't disappear because the capabilities share an interface.
Evaluate the package using one complete workflow. Confirm which capabilities are included, which require additional configuration and where the platform hands responsibility to another system.
Composable architecture: your team connects the components
A composable pattern assembles capabilities around existing infrastructure, often using a warehouse or lakehouse as a central data store. Different components may perform identity resolution, transformations, audience management and delivery.
The practical question is who maintains the connections between them. A change in a source identifier can affect matching, profile calculations and downstream audiences across several components.
Document the dependency order, failure handling and release process. Flexibility helps when your team can operate the resulting system; a diagram with fewer boxes doesn't necessarily mean less work.
Lakehouse-connected architecture: share data and assign processing
A platform can connect to a warehouse or lakehouse through a documented sharing or access mechanism. Inspect the exact mechanism rather than treating lakehouse-native, warehouse-native and zero-copy as interchangeable terms.
For example, Amperity Bridge for Snowflake documents bidirectional access using Snowflake secure data sharing and configurable schemas or tables. That connection does not, by itself, prove where every processing step runs.
Ask which account owns each dataset, which service performs identity resolution and which results become available downstream. Review supported regions, access requirements and refresh behavior in the relevant technical documentation.
The table below summarizes how these illustrative patterns commonly divide the same jobs. Confirm the actual division for any product or design you evaluate.
Job | Packaged | Composable | Lakehouse-connected |
|---|---|---|---|
Customer data storage | The platform loads source data into its own environment | Your warehouse or lakehouse often acts as the central store | Data stays in your warehouse or lakehouse and is shared through a documented mechanism |
Ingestion and transformation | Configured within the platform | Your team or separate tools | Depends on the sharing mechanism and the service assigned to each step |
Identity resolution and profiles | A platform capability your team configures and reviews | A separate component your team selects and connects | Performed by an assigned service; verify where each step runs |
Audiences and delivery | Platform segmentation and destination connectors | Separate audience and activation tools | The platform or separate tools, using shared or returned results |
What your team operates | Source definitions, permitted use, business rules, credentials and acceptance checks | Connections between components, dependency order, failure handling and releases | Shared datasets, access, refresh behavior and the split of responsibilities between accounts |
Treat identity and profile logic as separate responsibilities
Identity resolution establishes relationships among records. Profile modeling decides which attributes and histories a consuming workflow uses. A grouping can be plausible while an aggregate or eligibility field is wrong.
Our explanation of identity resolution techniques provides the matching context. Test the resulting profiles against known examples and source totals.
In Amperity, the customer-data setup guide covers semantics, validations, Stitch and database construction. Use the documented steps to identify configuration and review work rather than assuming an import produces a finished business model.
Keep governance and observability across the whole path
An architecture should show how teams control access, manage credentials, trace source records and review changes. Include receiving systems in that boundary: delivery can succeed while the destination still rejects identifiers or delays processing.
Record the freshness requirement for each decision and the checks that show whether it was met. Separate event arrival from profile calculation, audience evaluation and destination use.
The cost of poor customer data quality includes the repeated investigation and reconciliation work that diagrams often leave out. Give that work an owner and a way to detect regressions.
Choose by ownership and acceptance tests
Compare architectures using the same source set, business definition, destination and failure scenarios. Ask each team or vendor to identify the work it supplies and the work your organization retains.
Choose the design you can explain and operate. Explore our customer profile capabilities alongside the technical documentation, then test one workflow from source records to a usable destination result.
