The thing Braze does not have
There is a category of product that Braze deliberately does not build, and the gap explains almost every other difference in this series.
That product is a customer data platform: a system that takes raw records from many sources, standardises them, resolves conflicting identities and exposes a governed semantic layer on top. A profile store will not do it, and neither will a segmentation engine.
Marketing Cloud Next has one. It is called Data 360, and until recently it was called Data Cloud. Braze does not have one at all, and its own documentation is unusually candid about that, describing a CDP as the upstream system that feeds Braze’s intake step rather than a component of Braze.
This article is about what that means in practice, and about the honest accounting of what you replace.
What Data 360 actually does
It is easy to describe Data 360 as “the database” and move on. That undersells it, because the interesting part is the sequence of transformations it owns.
| Capability | What it produces |
|---|---|
| Data streams | Connectors pulling from CRM, cloud storage, ingestion API and packaged sources |
| Data lake objects | Raw records, preserved in the source’s own shape |
| Data model objects | Standardised records, comparable across sources |
| Identity resolution | A Unified Individual, resolved from many records |
| Calculated insights | Metrics computed over the data, defined once |
| Data graphs | An explicit allow-list of what marketing may use |
| Segmentation | Five segment types built on the resolved individual |
| Activations | Published audience data to internal and external targets |
| Zero copy | Querying external platforms in place |
Read that table as a claim. Marketing Cloud Next is asserting that it can take messy input from a dozen systems and produce one trustworthy person record, with governance at every step.
It also asserts something about cost. Data 360 meters consumption. Features consume credits based on records processed, queried or analysed, with some internal Salesforce ingestion exempt. Data platform cost becomes a variable operating expense tied to query and processing volume, rather than a flat licence.
The honest count of what Braze needs instead
If you run Braze and you want what Data 360 provides, you do not buy one product. You assemble between one and four.
| Data 360 function | What Braze gives you | What you still need |
|---|---|---|
| Ingestion from many sources | Cloud Data Ingestion, REST, SDKs | A pipeline for sources Braze cannot read |
| Raw record preservation | Nothing | A warehouse |
| Standardised model | Your profile schema | Discipline, because nothing enforces it |
| Identity resolution | An asserted key | A CDP or warehouse identity graph |
| Calculated metrics | Query Builder, Segment Extensions | A warehouse with governed definitions |
| Data graph curation | Nothing, since everything is exposed | Access control and naming conventions |
| Segmentation | Strong, and real-time | Nothing |
| Activation to external systems | Webhooks, Audience Sync | Connector development |
| Zero copy | Connected Sources | Nothing |
The middle column is the part people underestimate. The right-hand column is the bill.
There is one line where Braze genuinely wins on simplicity. Segmentation. Braze evaluates segments in real time against the profile, with no refresh cycle and no materialised membership set. Asking “how many people were in this segment last Tuesday” is impossible in Braze, and most teams never need to ask.
The identity question, precisely
This is the divergence that matters most, so it deserves the diagram rather than the sentence.
Marketing Cloud Next resolves identity from evidence. Records match on email, phone, device identifiers or fuzzy name similarity, and reconciliation rules decide which value wins when two sources disagree.
Braze receives identity and applies a simple, documented merge rule. The profile you keep wins every conflict. The profile you merge in only fills blanks.
Three exceptions exist, and they are worth knowing. Profiles marked for deletion do not merge. Test users merge with test status preserved. Members of the Global Control Group do not merge at all, because membership derives from a random bucket number and merging would silently reshuffle experiment membership.
That last exception is a small window into a deeper truth. In Braze, identity is coupled to measurement integrity. Changing identity can corrupt your experiments.
What breaks in the real world
The most common Braze data failure is not exotic. A mobile app sends one identifier format, a web store sends another, and the same human becomes two profiles.
You then message them twice, count them twice, and cannot explain why the numbers do not reconcile.
Marketing Cloud Next is designed to catch that case. Braze is designed to trust you. Neither design is wrong, but only one of them fails loudly.
There is a second failure, quieter and specific to Marketing Cloud Next. Its data graph cannot have fields removed once saved. Choose too widely and you carry permanent query cost. Choose too narrowly and you rebuild later. Over-inclusion is not recoverable, which makes the initial modelling decision unusually consequential.
Both sides meter, in opposite directions
Cost architecture is worth understanding before you commit, because it shapes what you build.
Marketing Cloud Next charges for reading and computing. Every calculated insight run, identity resolution pass and real-time event has a price. A poorly designed graph that joins five objects on every query is expensive.
Braze charges for writing and sending. Every attribute write counted against the legacy data-point metric, and every message, has a price. Queries and segment evaluations are cheap.
The optimisation advice therefore inverts. On Marketing Cloud Next you minimise queries and joins. On Braze you minimise writes and sends.
When each architecture is right
If you have multiple source systems, no shared identifier, and a compliance team that expects a governed audit trail of how a customer record was assembled, Marketing Cloud Next is the architecture you are describing.
If you already have a resolved customer key from a CDP or a warehouse, and your competitive advantage is speed of engagement, Braze is the better fit and the missing data platform is not a gap at all.
The mistake is buying Braze expecting it to become a CDP, or buying Marketing Cloud Next expecting the data work to disappear. The data work never disappears. It only moves.
A quick check for understanding
Your organisation has a CRM, an ecommerce platform and a loyalty app, each with its own customer identifier and no shared key. Before you can send a single personalised email on either platform, which component must exist, and whose job is it to build it?
Part three looks at the plumbing itself, in data streams and data kits.
