Data Cloud (Data 360) for Marketing

Salesforce Data Cloud for Marketing, and Whether You Need It

Salesforce Data Cloud — renamed Data 360 in October 2025 — ingests data from across the business, resolves identity into unified profiles, computes insights on them, and activates segments into Marketing Cloud and elsewhere. Twopir Consulting implements it, and tells you when the problem you are describing is a contact model problem that does not need a platform program to solve.

  • 12+ Years of CRM and marketing platform delivery
  • 15+ Certified platform partnerships
  • 40+ Certified Salesforce, HubSpot and AI specialists
Data 360 Pipeline
THE PIPELINE, IN ORDER Ingestion CRM, web, app, commerce, warehouse Stage 01 Harmonization Different sources, one model Stage 02 Identity resolution Records become people Stage 03 Calculated insights Value, recency, propensity Stage 04 Activation Into Marketing Cloud and elsewhere Stage 05 TWOPIR DATA 360 PRACTICE Use Cases First Named before any source is connected Testable Identity Rules you can prove, not rules you hope Consumed Activation Segments something actually uses 2πr WHAT THAT PRODUCES One audience definition every team shares Instead of three teams rebuilding the same segment Segments the business trusts enough to act on Because the identity rules were proven, not assumed
Qualification

Does This Problem Actually Need Data 360?

Data 360 is the most oversold item in the Salesforce marketing estate, and a good share of the problems it gets proposed for are contact model problems that a properly designed Marketing Cloud org already solves. Here is the honest version.

Common requirements and whether Data 360 is the right answer
The problemDoes Data 360 solve itWhat we would do
"We cannot segment on CRM fields in Marketing Cloud."No — that is an integration problem.Fix the synchronized data sources and the contact model. See integration. Buying a platform to avoid designing a data model is an expensive detour.
"The same customer exists three times in Marketing Cloud."Possibly not — check the contact model first.If the duplication originates in how records were loaded or synchronized, it is a data and contact model fix. Data 360 helps when the duplication spans systems, not tables.
"We cannot tell that a web visitor is an existing customer."Yes — this is core Data 360.Identity resolution across anonymous web behavior, app activity and known CRM records is exactly what the product is for.
"Marketing, sales and service each define 'active customer' differently."Yes.Calculated insights computed once, over unified profiles, and consumed by all three. This is the strongest business case the product has.
"We want to activate warehouse data into journeys."Sometimes.If it is one dataset on a schedule, an automation and a data extension is simpler and cheaper. Data 360 earns its place when the warehouse is one of several sources needing resolution.
"We need a single customer view."Ask what it is for first.This phrase covers everything from a better contact model to a multi-year platform program. We scope it against named use cases rather than against the phrase, because the two answers differ by an order of magnitude.

Capabilities verified against Salesforce documentation Last reviewed 23 September 2026

The Work

What Implementing Data 360 Actually Involves

Four bodies of work. The third is where the value is created and the fourth is where it is realized, which means a program that stops after ingestion has spent the budget and delivered nothing anyone can use.

Stage 01 & 02

Ingestion and harmonization

Connecting the sources and mapping them into a shared model. Mechanically the most straightforward part and the part most likely to consume the whole budget if nobody has decided which sources actually matter.

  • Source connection: CRM, web, app, commerce, warehouse, files
  • Marketing Cloud Engagement connected as a source — see integration
  • Mapping into the shared data model
  • Refresh cadence per source, matched to how fast it changes
  • Only the sources a named use case requires, not everything available
  • Volume and cost modelled before connection rather than after
Stage 03

Identity resolution — where the value is

Turning records into people. The rules decide who is treated as the same person, and getting them wrong is worse than not resolving at all: over-matching merges two customers, under-matching leaves them separate and undermines confidence in every segment built afterwards.

  • Match rulesets designed against your actual data, not a template
  • Testing: precision and recall measured on known cases
  • Over-match and under-match tolerance decided by the business
  • Anonymous-to-known reconciliation across sessions
  • How resolution changes when a customer updates their details
  • A documented, reviewable ruleset rather than a black box
Stage 04

Calculated insights

Computing the things everyone keeps recomputing differently — lifetime value, recency, engagement recency, propensity, category affinity. Defined once over unified profiles, and consumed rather than rebuilt by each team.

  • The metrics three teams currently calculate three ways
  • Definitions agreed before implementation, not after the argument
  • Refresh frequency matched to how the insight is used
  • Available to marketing, sales and service alike
  • Feeding reporting as well as segmentation
  • Documented so a number can be explained when it is questioned
Stage 05

Activation into Marketing Cloud

Segments and insights leaving Data 360 and arriving where they are used. The stage that justifies the program, and the one most often postponed until after the budget has gone.

  • Marketing Cloud Engagement configured as an activation target
  • Segments landing where journeys can consume them
  • Activation cadence matched to how quickly the audience changes
  • Insight attributes available for personalization, not just targeting
  • Consent state respected in activation, every time
  • At least one use case live before the next source is connected
Prerequisites

Four Things Data 360 Needs From Your Organization

Data 360 programs stall for organizational reasons far more often than technical ones. The platform works; what is usually missing is an agreement about what it is for and who owns the answers it produces.

These four are worth establishing before the first source is connected, because each one becomes considerably harder to settle once several teams are depending on the output.

If the requirement turns out to be narrower than this, that is a good outcome — the Marketing Cloud practice page covers what a well-designed contact model already gives you.

Named use cases, not a single customer view

"A single customer view" is an ambition rather than a scope, and it cannot be delivered or verified. Two or three named use cases — this segment, activated into this journey, to produce this outcome — can be built, measured and used to justify the next increment. Programs scoped on the phrase rather than the use cases are the ones that stall after ingestion.

A decision about who owns identity

Identity resolution rules are a business policy expressed as configuration. Whether two records are the same person affects marketing, sales, service and sometimes legal, so the rules need an owner with the standing to decide across those teams. Left to whoever configures the platform, they become a technical default that nobody agreed to and everybody inherits.

Someone who will consume the output

A unified profile nothing activates is an expensive database. Before connecting sources, it is worth naming what will use the result on day one — a journey, a sales view, a service screen — and confirming that the team owning it has capacity to adopt it. Activation postponed is value postponed indefinitely.

Realistic expectations about data quality

Data 360 resolves identity; it does not repair data. Inconsistent formats, missing consent, stale records and duplicates within a single source are still inconsistent, missing, stale and duplicated after ingestion. Profiling the sources first is what turns that from a surprise into a plan.

12+
Years delivering CRM and marketing platform transformation
15+
Certified platform partnerships
500+
Clients served across global markets
98%
Client retention rate
Failure Modes

Four Ways a Data Program Spends the Budget Without Delivering

These are not hypothetical failure modes. They are the shape of the majority of stalled customer data platform programs, across vendors — the product changes and the pattern does not.

All four are avoided by the same discipline: one use case live, end to end, before the second source is connected.

Ingestion as the whole project — Six months connecting every available source because connection is measurable and feels like progress. The budget is spent, the profiles exist, and nothing activates — so nobody outside the data team has seen any value.

Identity rules nobody validated — A ruleset configured to a sensible-looking default and never tested against known cases. Over-matching merges distinct customers, which is the failure that reaches a customer; under-matching leaves the duplication the program existed to remove.

Insights nobody agreed to — Lifetime value calculated one way in Data 360, another way in the finance report, a third way in the sales dashboard. Three numbers, three owners, and a meeting that never resolves — which discredits the platform rather than the definitions.

Activation as a phase two that never arrives — The program delivers unified profiles and the activation work is scheduled for the next budget cycle. By then attention has moved, the sponsor has changed, and the profiles are a cost line with no consumer.

Readiness

Five Questions Before Connecting Anything

If these have clear answers, a Data 360 program is likely to deliver. If more than two do not, the first engagement should be defining them rather than connecting sources — which is a much smaller piece of work.

Can you name two or three specific use cases, each with a segment, a destination and an outcome — rather than "a single customer view"?
Who decides whether two records are the same person, and does that person have standing across marketing, sales and service?
What will consume the first unified segment on the day it exists, and does that team have capacity to adopt it?
Have the source systems been profiled, so the data quality you will inherit is a finding rather than an assumption?
Is the problem you are describing actually an identity problem, or a contact model problem that a properly designed Marketing Cloud org would solve for far less?
Common Questions

Questions About Data Cloud and Data 360

Yes. Salesforce renamed Data Cloud to Data 360 in October 2025. The name changed; the functionality did not.

Most people still search and speak about Data Cloud, and a great deal of documentation and internal material still uses it. We use whichever term you use, and we would not read anything into the rename beyond Salesforce aligning its product naming.

Frequently not. A well-designed contact model with a properly configured CRM integration solves a large share of what Data 360 gets proposed for, at a fraction of the cost and the timeline.

Data 360 earns its place when identity genuinely has to be resolved across systems — anonymous web behavior tied to known CRM customers, app activity joined to commerce history — or when marketing, sales and service need to share one definition of an audience. If the problem is that marketing cannot segment on CRM fields, that is an integration problem.

Contact Builder models contacts inside Marketing Cloud, for marketing. Data 360 unifies data across the business and serves sales, service and commerce as well — and it resolves identity across sources rather than relating tables within one platform.

They coexist. Data 360 resolves who the customer is and activates segments; Marketing Cloud still needs a contact model for the records it sends to. Data 360 does not remove the need to design that model, and expecting it to is a common and costly assumption.

It decides which records across your sources represent the same person, and merges them into a unified profile. The rules are configurable — which fields must match, how closely, with what precedence — and they encode a business policy rather than a technical preference.

The part that needs attention is testing. Over-matching merges two distinct customers, which is the failure that reaches a customer; under-matching leaves the duplication the program was bought to remove. Both are measurable against known cases, and both should be measured before the ruleset goes live.

It depends almost entirely on scope discipline. A program scoped on two named use cases — a segment, a destination, an outcome — can deliver something activated and useful in a few months. A program scoped as "a single customer view" tends not to finish at all, because it has no definition of finished.

The sequence we recommend is one use case live end to end, including activation, before the second source is connected. It is slower on paper and it is the only shape that reliably produces value before the budget cycle turns over.

No, and this is worth being direct about. Data 360 resolves identity across sources. It does not clean records, standardize formats, fill in missing consent or remove duplicates that exist within a single source.

Those remain your problem after ingestion, and they will be more visible because everything is now in one place. Profiling the sources first turns that from an unwelcome discovery into a plan — which is why we do it before connecting anything.

Next Step

Name the Use Case Before Connecting a Source

Tell us what you want to be able to do that you cannot do today, and where the data for it currently lives. That conversation usually establishes within the hour whether this is a Data 360 problem or a contact model problem.

Serving: US | Canada | UK | UAE | Australia | New Zealand

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.
  • Identify revenue leaks across CRM, integrations, and GTM
  • Design and optimize complex systems (CRM to Custom Apps)
  • Apply practical AI to improve operations and pipeline conversion
  • Eliminate silos and build a unified revenue system
  • Assess GTM performance and key bottlenecks
  • Align teams with clear processes and ownership
  • Define a scalable RevOps model
  • Improve forecasting and reporting
  • Review your HubSpot/Salesforce setup for scale