Move the query, not the data: federated audiences in Adobe Experience Platform

Your best audience data sits in a warehouse your Customer Data Platform (CDP) has never been allowed to touch. Federated Audience Composition (FAC) changes that.

Service

Adobe

Product telemetry, billing history, dealer entitlements, churn scores: they sit in Snowflake or Databricks, modeled by data teams and cleared by security and compliance after years of review. The problem is that your CDP could never reach them without copying that data out of the warehouse and into its own profile store. Federated Audience Composition works differently. It's worth understanding exactly how, because that's what determines whether it fits your architecture.

The ingestion tax

Until recently, Real-Time CDP had one answer for every dataset: ingest it. If a signal was going to shape an audience, it first had to be piped into the platform, mapped to XDM, and persisted in the profile store. Each new use case meant a new pipeline. Each pipeline meant duplicate storage, another sync to monitor, and a second governance review for data that had already passed one.

For some datasets, that review ends the conversation. Credit attributes, health information, plant-level records: security teams keep these in the warehouse for good reasons, and no marketing use case outranks those reasons. So the signal that best predicts churn or qualifies a buyer stays where it is, and the profile never sees it. The audience you actually want becomes the audience you cannot build.

We call this the ingestion tax, and every Real-Time CDP customer used to pay it on every dataset.

What Federated Audience Composition does

Federated Audience Composition is Adobe's add-on module for Real-Time CDP and Journey Optimizer that builds and enriches audiences directly against your enterprise data warehouse. Adobe's supported list currently includes Snowflake, Databricks, Google BigQuery, Amazon Redshift, Azure Synapse, Microsoft Fabric, and Vertica.

The mechanics matter, so here they are. When you connect a warehouse, Experience Platform stores metadata only: a virtual schema describing the remote tables you choose to expose. Nothing is replicated. When someone builds an audience in the composition canvas, FAC compiles that definition into SQL and pushes the query down to your warehouse engine, where it executes on your compute, against your live tables. What travels back is the result set: the qualifying identities and whichever attributes you chose to return. The underlying rows never leave.

That one design decision enables three patterns:

Build from the warehouse alone. Create a new audience directly from warehouse data, no existing platform audience needed.
Enrich without persisting. Take an existing platform audience, such as web visitors from the last seven days, and layer on warehouse attributes like a pre-qualification flag, without writing them into the profile store.
Enrich the profile itself. Where a use case needs the data downstream, write selected warehouse attributes directly into the profile.

A few operational details technical teams should plan for: FAC reaches your warehouse over allow-listed IPs, you govern access through a dedicated product profile and permission set, compositions run on schedules you define, and Adobe meters data egress volume against your license. None of this is exotic, but all of it belongs in the architecture review before the first connection goes live.

Why FAC matters more than it first appears

The obvious win is skipping pipelines. Adobe's own published material on Federated Audience Composition shows audience build-out dropping from weeks to about a day once a warehouse connection is live. In our experience, the slow part was never the audience logic; it was the ingestion project standing in front of it.

The deeper win is governance. Whatever controls your security team built around the warehouse (row-level access, masking, residency, audit) keep doing their job, because the data never moves. Consent and identity stay governed in one place instead of two. For regulated datasets, this is not a convenience. It is the difference between a use case existing and not existing.

And there is an architectural win that compounds over time: your warehouse remains the system of record, and Experience Platform becomes what it should have been all along - the engagement engine on top of it. Teams stop maintaining two versions of the truth. When the churn model in Databricks improves, tomorrow's audience improves with it. No re-ingestion, no backfill.

Composable versus real-time: the trade-offs nobody puts on the slide

But we also need to blunt here, because this is where composable-CDP marketing gets ahead of composable-CDP reality.

Federation is a batch. A federated composition executes on a schedule, so a federated audience is only as fresh as its last run. Adobe is explicit about the downstream consequences: in Journey Optimizer, audiences built through FAC cannot trigger Audience Qualification activities, precisely because of their batch nature, and preview and proof are not supported for them. If your use case is cart abandonment, in-session personalization, or reacting to an event within seconds, federation is the wrong tool. Those cases still require streaming ingestion and edge segmentation on data that lives in the profile.

The reverse is equally true. Ingesting everything means paying the ingestion tax on datasets that change quarterly and that legal never wanted copied in the first place. A warehouse-only stack cannot deliver in-the-moment experiences; a fully ingested stack cannot hold your most sensitive signals. Anyone selling you one pattern for every dataset is selling you their architecture, not yours.

The real question is per dataset, per use case: does this decision need to happen at event speed, or is yesterday's data the right data? Real-Time CDP now supports the full spectrum, from full ingestion to full federation, and the value sits in drawing that line deliberately.

How we get federation to actually perform

Every composability engagement we run starts with that line-drawing exercise. For each dataset feeding a use case, we ask what the activation requires. Behavioral events that must trigger journeys in the moment get ingested and streamed. Slowly changing, sensitive, or heavy historical data gets federated. Then we do the work that determines whether federation performs: reconciling warehouse keys with profile identities so a federated audience and a streamed event resolve to the same customer, checking merge policies, and tuning the warehouse-side data model, because pushed-down SQL is only as fast as the tables it lands on.

In high-tech, the pattern we build most often federates product usage and billing signals, including churn scores computed where the data scientists already work, onto profiles that web and product events update in real time. In manufacturing, we federate dealer, distributor, and plant data so the profile finally extends past the loading dock, while commerce and service events stream in alongside it.

We stay through the second and third use case, because that is where a warehouse connection becomes a working system.

New use case

A dataset Evaluated separately

What does activation require? Decided per dataset

Ingest and stream Needs to trigger instantly

Federate Slow-changing, sensitive, or heavy

Match identities

Check merge rules

Tune the warehouse

A performing federation

The profile finally reaches the data

For years, the honest answer to "can our CDP use that dataset?" was "yes, if you copy it." Federated Audience Composition replaces that with a better question: does this data need to move at all? Increasingly, it does not. The query travels instead.

If you already run Real-Time CDP or Journey Optimizer, this is an extension of what you own, not a migration away from it. The scoping decision, ingest or federate, dataset by dataset, is where the value is won or lost, and it is exactly the decision we help clients make. If your best audiences are still trapped in the warehouse, let's talk about which one to free first.