The DXP Catalyst Update - July 13, 2026

If your organization is preparing a DXP RFP and has not yet resolved how customer data will be structured, you are sequencing the work backward. The CDP conversation has shifted over the past two years. What was once a question of which vendor to select has become a broader question about where customer data should live and how that choice connects to the digital technology ecosystem you are buying into. Warehouse-native and zero-copy CDP approaches have moved out of niche data engineering territory, and they surface more and more often in the selections we advise on. The harder question sits one level down, in whether a given platform reads customer data where it already lives or quietly replicates it into a store of its own. Organizations that defer this conversation discover, too late, that their DXP selection has already answered it for them.

LEADERSHIP GUIDANCE

In the evaluations we run, customer data tends to enter the DXP conversation as a feature comparison. Teams ask which platforms offer native CDP capabilities, built-in audience segmentation, or unified customer profiles. Those are reasonable questions, but they arrive too late in the process. By the time a shortlist has been assembled and vendors are presenting, the data assumptions baked into each platform's native capabilities have already narrowed the organization's real options, whether or not anyone in the room recognizes it.

The consequence is predictable. An organization selects a DXP on the strength of its content management or personalization engine, then discovers that its native data layer either duplicates a warehouse investment already in place or conflicts with the warehouse-native approach the team intended to build. Both outcomes are recoverable. Both are expensive to recover from, and both are avoidable.

When “Which CDP” Becomes the Wrong First Question

For most of the past decade, the CDP market was primarily a vendor selection question. Organizations asked which system would ingest behavioral data, unify customer profiles, and push segments to activation channels. The assumption underneath was relatively stable: the CDP was a dedicated system of record, sitting alongside and often disconnected from the enterprise data warehouse.

That assumption no longer holds as a default. Warehouse-native CDP approaches, offered by vendors including Hightouch, Census, and GrowthLoop, treat the data warehouse itself as the authoritative source and layer activation capabilities on top of it. Zero-copy approaches take this further, allowing platforms to query customer data where it already lives in the warehouse without moving it into a separate store. These approaches are showing up more often in the selections we advise on, and less as data engineering edge cases than they did even a year ago.

For IT and marketing executives, the implication is direct. Which CDP vendor to select now follows a prior decision about where customer data should live and what role the DXP plays in accessing and acting on it. Those are structural questions, and they belong earlier in the process than most evaluation teams place them.

How DXP Selection Locks In Your Data Architecture

A DXP tends to carry an implicit position on customer data, even when that position is never stated in an RFP response. Nearly every DXP now ships some customer data capability, whether profile unification, real-time segmentation, or built-in audience activation, so the presence of those features tells you little. What varies, and what an RFP response rarely makes explicit, is how deep that layer runs and whether it expects to be the system of record. In certain configurations those capabilities are useful. In others, they create direct overlap with warehouse investments the organization has already made or intends to make.

The conflict is not theoretical. An organization building toward a warehouse-native model has limited use for a DXP that replicates customer profiles into a store of its own. Those duplicated features become redundant infrastructure. Governance grows complicated when the same customer attribute exists in two systems with different update schedules and different owners. The activation logic that marketing believes is running from the DXP may not reflect the most current data sitting in the warehouse. A DXP whose own customer data layer reads the warehouse in place, rather than copying from it, avoids most of that, which is the whole of the difference and the reason the fourth model below turns on behavior rather than on branding.

An organization without a warehouse-native data strategy may instead find real value in a DXP that carries strong customer data capabilities of its own. Neither configuration is inherently better than the other. What we want to underline is timing: this determination should be made before the RFP is written, rather than discovered after the contract is signed.

Four CDP Models and What Each One Demands from a DXP

Four CDP models now dominate enterprise evaluation, and each carries a distinct set of requirements for DXP selection. The models describe one thing: where the system of record for customer data lives. The lines between them are not rigid, and where a given vendor falls can shift with packaging and use case, but the models are a useful way to sort what a DXP needs to do in each case. Conflating them during an evaluation produces a requirements list that no single platform can cleanly satisfy.

In the packaged CDP model, a dedicated product, of the kind Salesforce Data Cloud, Segment, or mParticle is often used for, owns the customer data. The CDP ingests, unifies, and segments. The DXP consumes audience definitions from it and personalizes against them. Here the DXP's data capabilities should be evaluated for how cleanly they receive and act on external audience inputs, rather than for whether they can replace the CDP. A strong customer data layer inside the DXP adds little in this configuration and can introduce governance conflict.

In the warehouse-native model, the enterprise data warehouse, running on Snowflake, Databricks, BigQuery, or a comparable system, holds that role instead. Activation tools push audiences from the warehouse to downstream channels, the DXP among them. Warehouse-native CDP tooling, such as Hightouch, often sits in this layer, activating directly against the warehouse rather than copying data out of it. Here the DXP needs to accept audience inputs from outside its own stack and support zero-copy or near-real-time queries against the warehouse. Its own customer data features are again largely beside the point.

In the hybrid model, a common configuration among large enterprises, the organization has accumulated both warehouse infrastructure and legacy CDP or marketing automation investments. Here the DXP needs a data layer that can work with multiple upstream systems without requiring full consolidation before going live. This is where the absence of a clear data position creates the most friction during evaluation.

The fourth model is the one most likely to be misread. In the DXP-native model, the DXP's own CDP is the system of record, and the vendors that pitch this hardest, Adobe, Sitecore, Optimizely, and others, present it as the shortest path to unified profiles and integrated personalization. That case can be sound, but the label tells you nothing on its own. What separates a sound version from a costly one is how the DXP's CDP relates to the warehouse, which is where the read-versus-replicate test does its work: when the DXP personalizes, does it read customer data where it already lives, or copy that data into its CDP first?

Three answers show up, and they are not equivalent. The strongest is true zero-copy, where the DXP's CDP queries the existing warehouse in place; since many organizations already run a warehouse, this gives integrated personalization without giving up the warehouse as the single source of truth. The middle answer copies the customer data from the warehouse into the DXP's CDP, which works but ends single-source-of-truth the moment a second copy exists. The weakest is dressed up as openness: the DXP advertises connectors to external CDPs, but the connector only ingests pre-built segments into its own CDP, and that CDP stays mandatory for the personalization that counts. All three answer a feature checklist identically, which is why the test belongs before the RFP, not after.

The Evaluation Sequence That Protects Your Options

Before any DXP RFP is issued, the organization needs to answer two questions internally. First, where does customer data currently live, and where should it live as a strategic target? The current state and the target state are often different, and it is the target that should drive DXP requirements. An organization three years into a warehouse consolidation effort has a different set of DXP requirements than one still dependent on a legacy CRM as its primary data source, even when both are serving similar content and personalization needs today.

Second, who owns the customer data decision? In many of the organizations we work with, the data engineering team has formed a strong view about the warehouse while the marketing team has independently evaluated CDP vendors. When those conversations run in parallel tracks and converge only during DXP selection, conflicting requirements emerge that no platform vendor can resolve on your behalf.

For each vendor under evaluation, the RFP should ask directly how the platform's data capabilities interact with an external CDP or data warehouse, and it should press for the behavior beneath the answer. When you personalize, does the platform read profile data where it resides or replicate it into a store of its own first? Can it act on audience definitions maintained outside its own stack without that data being copied internally? If it advertises a connector to our CDP, does that connector query our data live, or does it ingest segments into your layer and run personalization from there? What does real-time personalization require in terms of where profile data must reside? These questions expose the assumptions that standard vendor presentations rarely volunteer, and they are the ones the read-versus-replicate test is built to surface.

Final Thoughts

The most useful reframe here is to treat customer data as infrastructure rather than as a feature set. Feature sets get evaluated during platform selection, while infrastructure decisions quietly constrain which feature sets are even viable.

The practical starting point is simpler than it looks. Before any DXP RFP goes out, the organization should be able to answer, at least in draft form, where the system of record for customer data will live and who is accountable for that decision. That answer does not require the CDP selection to be final. It requires enough clarity to know which of the four models the organization is building toward, and, if that model is DXP-native, the discipline to hold each vendor to the read-versus-replicate test rather than the capabilities sheet. That clarity changes every question you will ask a DXP vendor, and it changes which answers you should trust.