Article
    by Prasoon Pathak, Adobe Technical Product Manager

    Avoiding the customer data platform trap

    Composable architecture, built around data connection and independence, helps organizations avoid the customer data platform (CDP) trap. Structural issues like unconnected key data sources, messy data segments, and retrofitted governance commonly stall CDP investments. But identifying roadblock patterns leads to understanding and fixes. Let’s look at how composable architecture, built into Adobe Real-Time CDP, integrates capabilities to avoid problems, its results in field experience, and the steps to take if you’re facing a CDP project stall.

    Service

    Adobe

    What composable architecture actually changes (and what it does not)

    Every platform vendor now claims composability. The term "composable CDP" has been used loosely enough that it has started to lose meaning. It is worth being precise.

    Composability, in the architectural sense that matters, means the platform does not require data to be physically centralized in order to activate it. It can federate queries to data at rest in the systems that already own it: your Snowflake environment, your Databricks lakehouse, BigQuery, Redshift, Azure Synapse. It can then compose audiences and profiles from that data without a full replication pipeline. The data does not move; the query moves to the data.

    This is not a marginal technical improvement. Composable, warehouse-native CDP vendors grew headcount nearly 8% in the second half of 2025, roughly six times the industry average, because enterprises are recognizing that the argument about whether customer data belongs in the CDP or in the warehouse is essentially settled. The warehouse won. The real question now is which activation layer composes best on the data infrastructure you already run.

    Adobe Real-Time CDP has moved deliberately in this direction. Here are the capabilities most relevant to the problems organizations face.

    Group visibility iconFederated Audience Composition:
    the architectural shift that matters most 

    Federated Audience Composition, generally available in Adobe RTCDP and Adobe Journey Optimizer, allows audience definitions to query data that remains in the enterprise warehouse, without ingesting it into Adobe Experience Platform. A marketer can build a segment that joins equipment age and service history from Snowflake with engagement recency from AEP, without either dataset needing to live in the same place.

    For manufacturers, this is the answer to the installed base problem. Equipment telemetry, service records, and warranty data can stay in the systems that own and govern them, subject to the access controls, retention policies, and data quality standards that already exist there, while still being used to define and activate audiences in real time. No replication project, governance exposure from copying sensitive operational data into a marketing environment, or staleness problem created by batch ingestion delays.

    One important nuance: Federated Audience Composition is a zero-copy query mechanism. It does not bring data into AEP profile store; it builds audience membership lists from warehouse queries and makes those lists available for activation. This means federated data does not enrich the real-time profile for streaming use cases. For that, you still need ingestion. Knowing which use cases need real-time profile richness versus which need audience composition at activation time is one of the more important architectural decisions in an RTCDP implementation.

    Streaming segmentation: closing the latency gap

    Adobe RTCDP supports streaming segment evaluation, segments that update as events arrive, rather than on a nightly batch cycle. When a customer triggers a service escalation, completes a product registration, or crosses a usage threshold, that event can immediately shift their segment membership and trigger a suppression, a follow-up, or a contextual content change.

    This matters most in high-stakes B2B interactions where the cost of wrong timing is measured in relationship damage, not just click-through rates. Suppressing an upsell campaign the moment a key account opens a priority-one support ticket is not a nice-to-have. It is basic commercial hygiene that batch segmentation makes structurally impossible.

    The caveat: streaming segmentation has limits. Segments that reference historical aggregates, or that depend on data not yet in the streaming pipeline, cannot be evaluated in real time regardless of the platform. Streaming is a capability, not a default state; it requires deliberate segment design and pipeline architecture.

    B2B Edition: finally account-level profiles that behave like accounts

    Adobe RTCDP B2B Edition introduces account-level profiles alongside person-level profiles, with explicit schema classes for accounts, opportunities, buying groups, and the relationships between them. Adobe has also been rolling out entity resolution improvements for B2B, using deterministic ID matching to reduce duplication and improve accuracy in how people and accounts are linked.

    What this resolves, in practice: the procurement lead who appears across six systems can now be recognized as a single person, linked to a single account, with the account carrying its own signals (total installed base, contract stage, aggregate support severity) separately from the individual contact's behavioral profile. Over-stitching becomes structurally less likely because the identity resolution logic is operating at the right level of granularity.

    This is still not a "set it and forget it" capability. Identity resolution requires ongoing monitoring, especially in environments with high contact turnover or frequent organizational changes. But the architecture at least makes it possible to get it right, which person-only identity graphs did not.

    Database iconData Collaboration:
    the answer to the distributor blind spot

    Adobe RTCDP Data Collaboration allows two parties, a manufacturer and a distributor, for example, to define and activate shared audiences based on overlapping data, without either party exposing raw customer records to the other. Distributors can identify their customers who are eligible for an upgrade; the manufacturer can co-activate against that audience without ever seeing the underlying distributor data.

    This is the cleanest answer to the channel partner data problem that we have seen from any enterprise CDP vendor. It is commercially viable in a way that "send us your customer file" is not. And it is legally structured in a way that "we will just build a joint dataset" often is not.

    Traditional CDP vs. Adobe RTCDP:
    where the architecture diverges

    Traditional CDP approach

    Adobe RTCDP composable approach

    Data must be ingested and replicated into the CDP to be used for activation

    Federated Audience Composition queries warehouse data in place — no replication, no profile bloat, no governance exposure

    Segments are evaluated on nightly batch cycles, creating 24-48 hour latency between signal and action

    Streaming segmentation evaluates segment membership as events arrive — suppressing and triggering fire within minutes

    Person-centric identity graphs struggle with B2B multi-contact, multi-site account structures

    B2B Edition introduces account-level schemas and deterministic entity resolution for accounts, opportunities, and buying groups

    Channel partner data sharing requires raw data transfer, which is commercially and legally difficult to negotiate with distributors

    Data Collaboration (Clean Room model) enables shared audience activation without exposing raw data on either side

    AI/ML pipelines are built separately from the data governance layer; compliance review happens post-deployment

    Data usage labels and consent policies enforced at the activation layer; governance is structural, not a retrofit

    Identity resolution treated as a one-time configuration task at deployment

    Ongoing entity resolution with monitoring tools; identity hygiene is an operational discipline, not a checkbox

    What we have seen work,
    and what we have seen break

    Theory is useful, and field experience is theory put to the test. These are the patterns we’ve seen in our RTCDP engagements with manufacturing and high-tech organizations.

    01 The installed base activation that changed the renewal conversation
    02 When identity resolution goes wrong, and how it went right
    03 The governance retrofit that cost six months

    A global industrial equipment manufacturer had two datasets that had never talked to each other: a Snowflake environment with complete installed base records (every machine, every site, every service contract, every maintenance event) and Adobe RTCDP with three years of digital engagement data. Marketing was running renewal campaigns against the entire eligible base; sales was calling accounts cold.

    Using Federated Audience Composition, the team built a segment that joined installed base age and maintenance frequency from Snowflake with digital engagement signals from RTCDP, without touching the Snowflake environment's data governance controls. The query ran at audience-definition time, not as a batch import.

    The resulting audience: accounts with equipment in years four or five of a five-year warranty cycle, more than two service events in the past twelve months, and a documented content engagement pattern suggesting active alternatives research.

    The renewal campaign targeting that audience outperformed the blanket renewal outreach by a significant margin. Not because the team had better messaging, but because they were reaching the right accounts at the right moment with the right commercial context. The data had always existed, but the architecture to join it had not.

    A high-tech hardware manufacturer discovered, during a data quality audit, that several thousand profiles in their RTCDP instance had become implausibly large, some carrying over a hundred associated email addresses. Investigation traced it to a shared device used for product demonstrations at trade shows. Every sales rep who logged into the demo unit had their session associated with the same ECID, and over time that ECID had been stitched into dozens of unrelated profiles.

    The resolution required a structured cleanup: isolating the problematic identity namespace, running a profile snapshot to benchmark the scope of the issue, removing the offending identity mappings, and then waiting. Identity unstitching in AEP takes time, typically one to two days for the profile store to reflect the changes. (This is documented behavior, not a bug, but it catches teams off guard the first time they encounter it.)

    The lesson was not just about demo devices. It surfaced a broader gap: the team had no ongoing identity hygiene process. Identity resolution had been treated as a deployment task rather than an operational discipline. They now run monthly audits against profile size distributions and identity graph density, simple queries in AEP Query Service, as an early warning system.

    An enterprise software company had built a next-best-action model that genuinely worked. In testing, it was predictive. It passed the data science review. Then it went to the legal and compliance team.

    The question they could not answer: for any given personalization decision driven by the model, which data points contributed to the output? Had the individuals whose data was used consented to AI-powered profiling for commercial purposes, specifically? What was the override mechanism for someone who objected?

    None of these could be answered from the way the pipeline had been built. The model consumed data from multiple sources without data lineage annotation. Consent states had been captured at collection time but were not being checked at activation time. There was no suppression mechanism for individuals who had withdrawn consent.

    The rework took six months and involved rebuilding the activation pipeline inside AEP's data governance framework: data usage labels applied at dataset level, marketing action policies enforced at activation, consent-based profile filtering at query time. If they had built with governance from the start, the compliance team's review would have taken two weeks.

    This story repeats. The organizations that treat governance as a prerequisite rather than a retrofit are consistently the ones that get AI personalization into production.

    Governance iconGovernance is not a layer you add later

    The organizations that treat data governance as a phase-two activity, something to sort out after the platform is running, consistently regret it. This is not a philosophical position; it is a practical observation from watching the pattern repeat.

    The reason governance cannot be retrofitted is structural. Governance in AEP is not a wrapper around data that already exists in the platform. It is a property of how data is ingested, labeled, and queried. A dataset that entered the platform without usage labels cannot be retroactively governed without reprocessing it. Consent states that were captured at collection time and stored as attributes cannot be applied dynamically at activation time without a different architecture.

    Data usage labels: the annotation that propagates

    AEP's data governance framework allows every dataset and field to be annotated with usage labels at ingestion time, designations like "restricted to first-party channels," "requires explicit consent for AI profiling," or "contains personally sensitive information." These labels are not decorative. They propagate through every downstream profile, segment, and audience that incorporates the labeled data.

    When an activation is configured, for a campaign, a segment sync to a paid media platform, or a journey trigger, the platform checks whether the data in that audience is permitted for the intended action under the defined marketing action policies. Violations surface before activation, not after. This is the difference between a governance framework and a governance audit.



    Consent at activation time, not collection time

    GDPR requires that consent withdrawals take effect without undue delay. Practically, this means a platform that filters profiles based on the consent state at the time the data was collected is not compliant — if someone withdrew consent last Tuesday, their data should not be powering a campaign that runs Thursday.

    Adobe RTCDP's consent management integration filters profile data at query time based on current consent state. This is a critical distinction. It requires that consent management platform outputs are being piped into AEP in near real time and that the activation queries are structured to honor those consent flags. Neither of these is default behavior; both require deliberate implementation choices.

    The EU AI Act: input for personalization

    The EU AI Act, phasing in from February 2025, does not ban AI-powered personalization in commercial contexts. But it introduces transparency and documentation obligations for AI systems used in profiling and behavioral targeting that most enterprise platforms were not built to satisfy.

    In practical terms: organizations deploying AI-driven next-best-action or predictive segmentation through Adobe RTCDP need to be able to tell an individual, in general terms, when and how AI influenced a commercial decision about them. They need a technical mechanism, not just a privacy policy statement, for individuals to opt out of AI-driven personalization. And they need enough data lineage documentation to demonstrate, to a regulator, which data inputs fed which AI outputs.

    AEP's data lineage tools and governance framework provide the technical foundation for each of these. But the implementation has to be intentional. The platform does not configure itself for AI Act compliance.

    Where to start, if you are already in the trap

    If you’re reading this, you are not at the beginning of your CDP journey. Your organization may have already made the investment, already run the integration project, already noticed the gap between what was promised and what is delivered. The question is not whether to buy Adobe RTCDP; you already have it, or something like it. The question is how to close the gap without throwing away two years of work.

    The answer is almost never a rip-and-replace. It is a structured audit followed by targeted architectural corrections.

    1. Start with the activation gap, not the data gap

    The instinct when a CDP is underperforming is to add more data, connect another source, ingest another system. Resist this. More data on top of a broken architecture makes the architecture harder to fix, not easier.

    Instead, map the gap between the decisions your commercial teams are trying to make, and the data those decisions actually require. For manufacturers, this almost always surfaces the installed base problem. For high-tech, it surfaces the product adoption and entitlement data gap. These are the missing signals that matter, and once identified, Federated Audience Composition becomes the obvious right answer.

    2. Audit identity resolution before adding data sources

    Before connecting another system, run a query against your profile distribution. Look for profiles with more than ten associated identities, or profiles that are implausibly large. These are the symptoms of identity resolution problems. Adding new data sources to a platform with unchecked identity resolution issues amplifies those issues.

    In RTCDP, Query Service gives you direct SQL access to profile snapshot data. A simple query on identity count distribution takes minutes and tells you whether you have a problem worth addressing before you go further.

    3. Make governance annotation the gate for every new data source

    Before the next dataset goes into AEP, define the data usage labels that apply to it and the marketing action policies that govern its use. Build this as an operational requirement: no dataset enters the platform without a governance annotation review. Apply the same requirement to federated datasets accessed through Federated Audience Composition; label the connection at the point of federation, not at the point of activation.

    4. Pick one streaming use case and instrument it properly

    Streaming segmentation is not worth enabling across your entire segment library. Find the one commercial use case where latency has the highest cost, a churn signal, a service escalation flag, a contract renewal trigger, and rebuild that segment for streaming evaluation. Instrument it: measure the latency between event ingestion and segment membership update and then measure the downstream commercial difference.

    That one instrumented use case builds the business case for broader streaming adoption and surfaces any pipeline constraints before they become production problems at scale.

    Implement with architecture that adapts

    71% of B2B buyers say they expect personalized interactions and become frustrated when they do not get them. 75% say they would switch suppliers for a better experience. The commercial stakes of getting this right are real. In manufacturing and high-tech, where sales cycles are long and account relationships are everything, the cost of wrong timing, wrong context, or a data governance failure is measured in lost contracts, not simply lost clicks.

    Large data teams and more connectors in the CDP haven’t guaranteed success. The organizations getting it right are the ones that took seriously the structural problems (identity resolution in a B2B context, operational data as a first-class commercial signal, channel partner dynamics, governance as a foundation rather than a feature) and designed their RTCDP implementation around those realities rather than around the default configuration.

    Adobe Real-Time CDP, in its composable form, has the right architecture for these problems. Federated Audience Composition solves the data centralization trap. Streaming segmentation solves the latency problem. B2B Edition solves the identity resolution challenge. Data Collaboration solves the channel partner blind spot. The governance framework, when implemented properly, solves the AI readiness problem.

    The capabilities are there. Realizing them is a matter of designing implementation around the actual commercial and data realities of the organization.


    Avoid CDP trap with an organization-adapted implementation, not a bigger one.

    Get in touch