Data 360 or a data warehouse? They are not competing for the same job

Ask a data team where customer data lives and the answer often contains two places in the same sentence: the warehouse, and Data 360. Then someone asks which one the organisation should consolidate onto, and the conversation stops being useful.

Data 360, formerly Data Cloud, gets compared to a warehouse because both hold customer data at scale and both use the word unification. That is where the similarity ends. They are built for different jobs, and the reason most organisations we work with run both is that neither is good at the other's.

#The two jobs

A warehouse exists to answer questions. Arbitrary ones, asked of history, most of which nobody has thought of yet. That requirement drives everything about how it is built: columnar storage, cheap retention, a query engine that will happily scan three years of transactions because an analyst had an idea on a Tuesday. Its success measure is that a question nobody anticipated can be answered without an engineering project.

Data 360 exists to act. Resolve a person across systems into a profile the platform recognises, then make that profile usable inside an operational system so something happens: a segment reaches a channel, a service agent sees the order that is late, a rep opens an account and the churn signal is already on the record. Its success measure is that the right thing happens to the right person while it still matters.

Analysis against activation. Almost every argument about these two products resolves once that distinction is on the table.

#The comparison

The last row is the one worth arguing about, because both failures are common and neither announces itself.

#Failure one: analytics on the activation platform

This is the tidier-sounding mistake. Everything is already in Data 360, the profiles are unified, so why maintain a second platform.

It goes wrong in three ways. The workload shape is different: activation queries are narrow and repetitive, analytics queries are wide and unpredictable, and a platform tuned for the first will not price or perform like one tuned for the second. The retention economics are different: a warehouse keeps years of history cheaply because that is what it is for. And the skills are different, because the analysts who are fluent in your warehouse and its modelling conventions do not become fluent in a new platform because an architecture diagram said so.

The symptom is recognisable. Reporting gets slower after the migration, a shadow extract appears so someone can finish their quarter, and within two quarters there is an unmanaged copy of the data nobody planned for.

#Failure two: real-time personalisation from last night's batch

The opposite error is subtler and more damaging, because it produces something that works in the demo.

A nightly warehouse build is entirely adequate for a monthly campaign. It is quietly wrong for anything where the customer is present. The abandoned basket recovered eighteen hours later has already been bought elsewhere. The churn-risk flag that arrives after the cancellation is a reporting artefact. Worst of all is the segment that is correct at build time and wrong at send time: the customer who complained this morning receives the upsell that was calculated last night, and nobody finds out until the complaint escalates.

Freshness is not a preference here. It is a functional requirement of the use case, and it is the requirement a warehouse-driven activation architecture cannot meet without slowly becoming an operational system itself.

The misdiagnosis is what makes this expensive. Campaign performance drops, and the review blames the creative, the audience definition or the channel, because those are the things the marketing team can see. The actual cause is that the audience was accurate at two in the morning and the send went at eleven. Nobody looks at the pipeline, because the pipeline reported success.

#What activation actually requires

It is worth being specific about what you are buying, because "we could build that" is a reasonable instinct and an incomplete one.

Identity resolution as a live service. Harmonize brings data from different systems into a common shape, and Identity Resolution matches the records that describe the same person. A warehouse can run a matching pass on a schedule. What is harder is maintaining that resolution continuously, so a profile is correct at the moment something acts on it rather than at the moment the job last ran. The mechanics are set out in the Salesforce how it works material.

Consent and permissioning at the point of use. Not as a filter in the query that builds the segment, but attached to the profile, so every downstream action inherits it. This is the part teams underestimate, and it is the part a regulator asks about.

Reach. Delivery into operational objects and channels, rather than an export. A file dropped for a marketing platform to collect is an integration you now own, and it will be the thing that breaks on a public holiday.

Those three are the surrounding machinery. Moving the data is the easy half.

#Zero Copy and the duplicate-copy tax

Running both platforms used to carry a real penalty: the same customer data stored twice, a pipeline to keep the copies aligned, and a recurring argument about which number was right when the two disagreed.

Zero Copy is the mechanism that reduced that. It lets Data 360 work against data that remains in the warehouse rather than requiring it to be duplicated first, and Salesforce publishes a Zero Copy partner network that includes warehouse vendors. Check your own platform against that list rather than assuming, because the pattern only helps where the connection genuinely exists.

Two caveats we would state in any design review. Zero Copy removes the copy, not the modelling: the data still has to be shaped into something the platform can harmonise and resolve, and that work is the majority of a Data 360 implementation regardless of where the bytes physically sit. And it does not change latency physics. Data reached in place is exactly as fresh as the warehouse that holds it, so a nightly-loaded table is still nightly, whether or not it was copied.

#Where the line sits in practice

The placement that holds up is less about the data than about who consumes the output.

If the consumer is a person asking a question, the workload belongs in the warehouse. Attribution, cohort retention, lifetime value modelling, anything a finance team will reconcile: history, flexibility, cheap scanning.

If the consumer is a system taking an action, the workload belongs in Data 360. Segments that trigger sends, profile attributes an agent reads mid-conversation, signals that fire automation.

One consequence of that test surprises people: reporting on activation is still a warehouse workload. The question of how a segment performed, how it overlapped with last quarter's, and what it did to margin is a question a person is asking about history, so it belongs where questions get answered. The activation platform emits the events; the warehouse is where they are interrogated. Building that reporting inside the activation layer is how organisations end up with two half-complete analytics estates and no agreement on which one is right.

The genuinely contested middle is scoring. A propensity model is trained in the warehouse, where the history and the tooling are, and its output has to be activated, which is the other platform's job. The pattern that works is to train where the history is and land only the score against the resolved profile. What goes wrong is insisting on both in one place: training on an activation platform is expensive, and holding scores only in the warehouse means they are never present when something wants to act on them.

#What to settle before you build

Two decisions, made explicitly rather than discovered.

First, the system of record for each entity, and the direction data flows. Bidirectional sync between a warehouse and an activation platform is where reconciliation arguments come from, and the fix is deciding once which side wins for each object. That is the same discipline we set out in pick the integration pattern first.

Second, per use case, the freshness the business actually needs, agreed with the people who own the outcome and written down. Most teams discover their real answer during an incident. The list is short, it takes an afternoon, and it is what tells you which platform each workload belongs to before anyone has built anything.

Once those are settled, the implementation sequence matters more than the platform debate, and we covered that separately in Data 360 implementation best practices.

The question was never which platform wins. It is which workload sits where, and whether the two stay reconciled when they disagree.